ices. Note that ESP can be
>>used to provide only integrity, without confidentiality, making it
>>comparable to AH in most contexts.)
>>
>>
>> Thanks,
>> Jingrong
>>
>> -Original Message-
>> From: spring [mailto:spring-boun...@ie
Ridiculous .. any NOS coder, coding IPv6, would have awareness of 2460, why
would you even go there .. seriously ?
The highlight was for:
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#page-4 -
you should probl read it all.
I think we've reach the limit of what the "IET
On 27/2/20 18:11, Darren Dukes (ddukes) wrote:
Mark AH is not defined for SRH. There is no specification to ignore.
Do you realize that you are using IPv6, and that AH is specified for IPv6?
Is the AD watching? -- Seriously, this is going through a very curious
and dangerous path.
For the
y 26, 2020 8:31 AM
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>
Cc: Ron Bonica mailto:rbon...@juniper.net>>;
spring@ietf.org<mailto:spring@ietf.org>; Joel M. Halpern
mailto:j...@joelhalpern.com>>
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Pablo,
On Sat,
>
> You realise that the 3 musketeers were heroes in that story?
>
Oh I do.
And I want to sincerely congratulate three of you to be very effective to
discourage touching IPv6, its dogmas and principles. If this is good for
the industry, time will tell.
To me I got even more assurance now that IP
On Thu, 27 Feb 2020 at 06:46, Robert Raszuk wrote:
>
> Hey Sander,
>
> No worries ... three IPv6 musketeers have already presented themselves well
> to this discussion. This was just one more demo of it. No need to apologize -
> at least me :)
>
You realise that the 3 musketeers were heroes in
On 26/2/20 18:20, Sander Steffann wrote:
Hi John,
So you are saying that other than the PSP issue, you support moving the
document forward?
Yes. As long as it doesn't violate existing RFCs and with that potentially
causes trouble for implementations that expect those RFCs to be followed I'
Hi John,
> So you are saying that other than the PSP issue, you support moving the
> document forward?
Yes. As long as it doesn't violate existing RFCs and with that potentially
causes trouble for implementations that expect those RFCs to be followed I'm
fine with it. It's not something I wou
On 26/2/20 18:02, john leddy.net wrote:
So you are saying that other than the PSP issue, you support moving the
document forward?
A number of us had repeatedly expressed their concerns with the
document. Please check the mailing-list archives.
I haven't argued in favor or against the docume
So you are saying that other than the PSP issue, you support moving the
document forward?
> On February 26, 2020 at 3:40 PM Fernando Gont wrote:
>
>
> On 26/2/20 17:22, john leddy.net wrote:
> > I would suggest that people read RFC 7282 - "On Consensus and Humming in
> > the IETF"...
> >
>
On 26/2/20 17:22, john leddy.net wrote:
I would suggest that people read RFC 7282 - "On Consensus and Humming in the
IETF"...
My question is: How do you reach Consensus when the complaint is about how many
milliseconds it takes to shoot down a proposal?
This document proposes a *major* chang
> Definitely the proposal. That a vendor seems to have an inappropriate amount
> of influence on the IETF process is just an additional concern.
PS: that the vendor is Cisco in this instance is not relevant. Any vendor doing
this would be equally bad. Any major vendor has played inappropriate ga
Hi John,
> I would suggest that people read RFC 7282 - "On Consensus and Humming in the
> IETF"...
>
> My question is: How do you reach Consensus when the complaint is about how
> many milliseconds it takes to shoot down a proposal?
>
> Is this about the proposal or the vendor involved?
Defin
I would suggest that people read RFC 7282 - "On Consensus and Humming in the
IETF"...
My question is: How do you reach Consensus when the complaint is about how many
milliseconds it takes to shoot down a proposal?
Is this about the proposal or the vendor involved?
>
> A number of us wonder h
On 26/2/20 16:44, Robert Raszuk wrote:
Hey Sander,
No worries ... three IPv6 musketeers have already presented themselves
well to this discussion. This was just one more demo of it. No need to
apologize - at least me :)
And while you can call someone's opinion the way you like - the fact
th
Hi Robert,
> No worries ... three IPv6 musketeers have already presented themselves well
> to this discussion. This was just one more demo of it. No need to apologize -
> at least me :)
>
> And while you can call someone's opinion the way you like - the fact that
> SRv6 builds on top of IPv6 d
Hey Sander,
No worries ... three IPv6 musketeers have already presented themselves well
to this discussion. This was just one more demo of it. No need to apologize
- at least me :)
And while you can call someone's opinion the way you like - the fact that
SRv6 builds on top of IPv6 does not make i
On Wed, Feb 26, 2020 at 6:55 PM Fernando Gont wrote:
> On 26/2/20 12:57, Dirk Steinberg wrote:
> > Hi Fernando,
> >
> > adding to my own comment and to be more specific:
> >
> > The existing RFCs are very clear in their wording that
> > the node identified in the Destination Address field of
> >
On 26/2/20 12:57, Dirk Steinberg wrote:
Hi Fernando,
adding to my own comment and to be more specific:
The existing RFCs are very clear in their wording that
the node identified in the Destination Address field of
the IPv6 header is free to do whatever it desires with
the packet it just receiv
On Wed, Feb 26, 2020, 6:26 AM Andrew Alston
wrote:
> Figured I’d add to this – as I continued to read the charter
>
>
>
> *SPRING WG should avoid modification to existing data planes that would*
>
>
>
>
>
>
>
>
> * make them incompatible with existing deployments. Where possible,
> existing contr
:rbon...@juniper.net>>
> Date: Tuesday, 17 December 2019 at 16:06
> To: "Pablo Camarillo (pcamaril)" mailto:pcama...@cisco.com>>, "Joel M. Halpern"
mailto:j...@joelhalpern.com>>,
"spring@ietf.org <mailto:spring@ietf.
; Hi Mark,
>> >
>> > Thank you for your feedback. Please see inline [PC1].
>> >
>> > Cheers, Pablo.
>> >
>> > -Original Message- From: Mark Smith
>> > Date: Wednesday, 26 February 2020 at 01:31
>> > To: "Pablo Camarillo
-Original Message- From: Mark Smith
> > Date: Wednesday, 26 February 2020 at 01:31
> > To: "Pablo Camarillo (pcamaril)" Cc: Ron Bonica
> > , "Joel M. Halpern" ,
> > "spring@ietf.org" Subject: Re: [spring] Is srv6 PSP
> >
Hi Mark
I have comment below;
Cheers!
Wang Weibin
From: spring On Behalf Of Mark Smith
Sent: Wednesday, February 26, 2020 7:45 PM
To: Robert Raszuk
Cc: Ron Bonica ; spring@ietf.org; Joel M. Halpern
; Pablo Camarillo (pcamaril)
Subject: Re: [spring] Is srv6 PSP a good idea
and no doubt
Joel M. Halpern" ,
"spring@ietf.org" Subject: Re: [spring] Is srv6 PSP
a good idea
Hi Pablo,
On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
wrote:
Hi Ron,
I guess we are making some progress here but going in some circles.
So far we have moved from “this violates RFC8200”
On 26/2/20 11:15, Andrew Alston wrote:
+1 Sander.
Furthermore – if indeed that is the contention – then – I suggest you
move the whole thing out of SPRING – I quote from the SPRING charter:
/The Source Packet Routing in NetworkinG (SPRING) Working Group is
thehome of Segment Routing (SR)
Figured I'd add to this - as I continued to read the charter
SPRING WG should avoid modification to existing data planes that would
make them incompatible with existing deployments. Where possible,
existing control and management plane protocols must be used within
existing architectures to implem
Of Sander Steffann
Sent: Wednesday, 26 February 2020 16:49
To: Robert Raszuk
Cc: spring@ietf.org; 6man WG
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Robert,
> Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 !=
> IPv6 that's obvious.
>
> It also do
t; Happy Holidays,
> Pablo.
>
>
> -Original Message-
> From: Ron Bonica
> Date: Tuesday, 17 December 2019 at 16:06
> To: "Pablo Camarillo (pcamaril)" , "Joel M. Halpern"
, "spring@ietf.org"
> Subject: RE: [spr
nt:* Wednesday, February 26, 2020 8:06 AM
> *To:* Mark Smith
> *Cc:* Xiejingrong (Jingrong) ; Ron Bonica <
> rbon...@juniper.net>; spring@ietf.org; Joel M. Halpern <
> j...@joelhalpern.com>; Pablo Camarillo (pcamaril)
> *Subject:* Re: [spring] Is srv6 PSP a good idea
&g
Hi Robert,
> Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 !=
> IPv6 that's obvious.
>
> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and
> makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's
> it. With that in min
+1 and well said!
From: spring On Behalf Of Robert Raszuk
Sent: Wednesday, February 26, 2020 8:06 AM
To: Mark Smith
Cc: Xiejingrong (Jingrong) ; Ron Bonica
; spring@ietf.org; Joel M. Halpern ;
Pablo Camarillo (pcamaril)
Subject: Re: [spring] Is srv6 PSP a good idea
> Somebody choosing
> Somebody choosing not to use AH doesn't mean SPRING can ignore the IPv6
specifications.
I think it sure can and in fact it should.
See there is perhaps key misunderstanding here.
Regardless if folks agree or not with that SRv6 is a new data plane. SRv6
!= IPv6 that's obvious.
It also does not
...@ietf.org] On Behalf Of Mark Smith
> Sent: Wednesday, February 26, 2020 8:31 AM
> To: Pablo Camarillo (pcamaril)
> Cc: Ron Bonica ; spring@ietf.org; Joel M. Halpern <
> j...@joelhalpern.com>
> Subject: Re: [spring] Is srv6 PSP a good idea
>
> Hi Pablo,
>
> On Sat,
; explanation to provide.
>>> >
>>>
>>> "Just because you can do something, doesn't mean you should."
>>>
>>> How much troubleshooting experience have they had with this?
>>>
>>> I think a very important factor is how
esday, February 26, 2020 6:07 PM
To: Mark Smith
Cc: Ron Bonica ; spring@ietf.org; Joel M. Halpern
; Pablo Camarillo (pcamaril)
Subject: Re: [spring] Is srv6 PSP a good idea
So now we have one more to Pablo's list: "Let's not use it as it is hard to
troubleshoot" ...
Cl
very important factor is how easy something is to
>> troubleshoot - how obvious is the mechanism works; is the mechanism
>> consistent with existing behaviours i.e. the principle of least
>> surprise (removing EHs at an intermediary hop certainly isn't in IPv6,
>> even if
lpern
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Mark,
I think both AH and PSP are optional.
If AH is desired to deploy, then the operator can choose not to use PSP.
If AH is not deployed, and the operator has its requirements of
incremental-deployment, then the operator can choose to use PS
:06
> > To: "Pablo Camarillo (pcamaril)" , "Joel M.
> Halpern" , "spring@ietf.org"
> > Subject: RE: [spring] Is srv6 PSP a good idea
> >
> > Pablo,
> >
> > In your message below, are you arguing that it is easier for
pring@ietf.org; Joel M. Halpern
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Pablo,
On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
wrote:
>
> Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we
> have moved from “this violates RF
Message-
> From: Ron Bonica
> Date: Tuesday, 17 December 2019 at 16:06
> To: "Pablo Camarillo (pcamaril)" , "Joel M. Halpern"
> , "spring@ietf.org"
> Subject: RE: [spring] Is srv6 PSP a good idea
>
> Pablo,
>
> In your message be
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Ron,
I guess we are making some progress here but going in some circles. So far we
have moved from “this violates RFC8200” to “there are no use-cases or benefits”
to “this is complex for an ASIC” to “what is the benefit again” and now back to
“this
onica
Date: Tuesday, 17 December 2019 at 16:06
To: "Pablo Camarillo (pcamaril)" , "Joel M. Halpern"
, "spring@ietf.org"
Subject: RE: [spring] Is srv6 PSP a good idea
Pablo,
In your message below, are you arguing that it is easier for the
penultimate node t
>
> Juniper Business Use Only
>
> -Original Message-
> From: Pablo Camarillo (pcamaril)
> Sent: Saturday, December 14, 2019 4:50 AM
> To: Ron Bonica ; Joel M. Halpern ;
> spring@ietf.org
> Subject: Re: [spring] Is srv6 PSP a good idea
>
> Ron,
>
>
Only
-Original Message-
From: Pablo Camarillo (pcamaril)
Sent: Saturday, December 14, 2019 4:50 AM
To: Ron Bonica ; Joel M. Halpern ;
spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Ron,
What is the "price paid by the penultimate segment"? All the current
imple
,
Ron
Juniper Business Use Only
-Original Message-
From: spring On Behalf Of Voyer, Daniel
Sent: Friday, December 13, 2019 5:14 PM
To: Xiejingrong (Jingrong) ; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
I agree 100% with Jingrong,
PSP allows us
HI Pablo:
Replies in-line prefaced with DA>
-Original Message-
From: spring On Behalf Of Pablo Camarillo (pcamaril)
Sent: Saturday, December 14, 2019 1:57 AM
To: Xiejingrong (Jingrong) ; Joel M. Halpern
; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Hi Dave,
Th
Robert
Thank you for your candid and concise response.
Your response is exactly what I was looking for from Spring.
There has been a lot of development across almost every IETF WG related to
the SR specification for years now and I was not there Day 2 and even for
many of the former years during
Gyan,
Do you think that sending the exact same email twice by copy and paste
makes it any more valid ?
All,
To all opponents of PHP - let me refresh you with a bit of SR history. SR
assumed that most of the operational behaviour will be SID type agnostic.
Regardless if I use MPLS SID or IPv6 SID
Dan
The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
historical meaning as well as real consequences as far as a packet walk
through an mpls network.
>From a historical perspective which is really the correct way to look at
PHP in the MPLS world was designed by the develop
s,
> Mark.
>
>
>
>> Ron
>>
>>
>>
>>
>> Juniper Business Use Only
>>
>> -Original Message-
>> From: spring On Behalf Of Pablo Camarillo
>> (pcamaril)
>> Sent: Wedne
t; Ron
>
>
>
>
> Juniper Business Use Only
>
> -Original Message-----
> From: spring On Behalf Of Pablo Camarillo
> (pcamaril)
> Sent: Wednesday, December 11, 2019 3:12 PM
> To: Joel M. Halpern ; spring@iet
..@ietf.org] on behalf of Joel M. Halpern [
> j...@joelhalpern.com]
> Sent: Wednesday, December 11, 2019 22:15
> To: spring@ietf.org
> Subject: Re: [spring] Is srv6 PSP a good idea
>
> Thank you Jingrong for providing some of the other motivations. Two
> furhter comments.
&g
dnesday, December 11, 2019 22:15
To: spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Thank you Jingrong for providing some of the other motivations. Two
furhter comments.
As far as I know, the only savings on the end box is the processing for
noticing the SRH, noticing that SL is 0
pe this helps
Dave
-Original Message-
From: spring On Behalf Of Pablo Camarillo
(pcamaril)
Sent: Wednesday, December 11, 2019 12:12 PM
To: Xiejingrong (Jingrong) ; Joel M. Halpern
; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
NVAeEWpnAI
Cheers,
Pablo.
-Original Message-
From: Ron Bonica
Date: Thursday, 12 December 2019 at 21:50
To: "Pablo Camarillo (pcamaril)" , "Joel M. Halpern"
, "spring@ietf.org"
Subject: RE: [spring] Is srv6 PSP a good idea
Pablo,
I am not convi
te: Thursday, 12 December 2019 at 06:48
To: "Pablo Camarillo (pcamaril)" , "spring@ietf.org"
Subject: Re: [spring] Is srv6 PSP a good idea
There are several aspects of your reply that leave me wondering.
First, optional behaviors in a protocol spec have signficia
That is an udnerstandable argument, ... except:
It does not acknowledge that there is a cost for this capability, or
discuss the tradeoff. PSP clearly has a cost.
Also, that does not match my reading of the definition of the SR domain.
In fact, it becomes very confusing as to whether the PE
I agree 100% with Jingrong,
PSP allows us to bring SRv6 to legacy PE devices that are not capable of
processing the SRH in the dataplane, but are capable of supporting SRv6 in the
control plane.
See this example:
I am streaming traffic from a server to a customer;
The ingress PE (near the serv
esday, December 11, 2019 12:12 PM
To: Xiejingrong (Jingrong) ; Joel M. Halpern
; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Jingrong,
> Nothing new, but benefits that people have already said seems notable to me.
Agreed.
Cheers,
Pablo.
-Original Message-
From: sp
Ron
Juniper Business Use Only
-Original Message-
From: spring On Behalf Of Pablo Camarillo (pcamaril)
Sent: Wednesday, December 11, 2019 3:12 PM
To: Joel M. Halpern ; spring@ietf.org
Subject: Re: [spring] Is srv6 PSP a good idea
Joel,
1.- The use-case for PSP has already been provi
There are several aspects of your reply that leave me wondering.
First, optional behaviors in a protocol spec have signficiant cost. So
if they are nbot needed, we generally prefer not to have options.
Second, I am confused by your comments about complexity. From my
conversations with multi
Joel,
1.- The use-case for PSP has already been provided at the mailer. There are
scenarios where it provides benefits to operators.
2.- The PSP behavior is optional. It is up to the operator in his deployment to
decide whether to enable it or not at one particular router.
Similarly, a vendor m
ring@ietf.org"
Subject: Re: [spring] Is srv6 PSP a good idea
I think it's a good idea.
Nothing new, but benefits that people have already said seems notable to me.
(1) reduce the load of final destination. This benefit can be notable for
the following sub reasons.
Thank you Jingrong for providing some of the other motivations. Two
furhter comments.
As far as I know, the only savings on the end box is the processing for
noticing the SRH, noticing that SL is 0 and there are no relevant TLVs,
and then moving on.
If the actual end device is not part of t
I think it's a good idea.
Nothing new, but benefits that people have already said seems notable to me.
(1) reduce the load of final destination. This benefit can be notable for the
following sub reasons.
(1.1) final destination tends to have heavy load. It need to handle all the EHs
and do the d
66 matches
Mail list logo
