Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Sat, 7 Mar 2020 12:13:23 +0100,
Robert Raszuk  wrote:

> > But, again, I expect not everyone agrees on this idea.  You probably
> > won't; then I'll respect that.  Sometimes we just have to agree to
> > disagree.
>
> Well perhaps to your surprise I am all for clarity in the specifications.
> So I have nothing against this spec (or any other spec) to formally update
> RFC8200. But correct me if I am wrong - but this would require also 6man
> WGLC if I am not mistaken in the process ?

Assuming you mean draft-bonica-6man-ext-hdr-update, yes, and it will
first need to be adopted way before that, and it's not even
guaranteed.

> But as you just mentioned there was "hundreds if not thousands of email
> messages" regarding header insertion/deletion in flight on 6man and that is
> why some authors may be actually resisting to take that path - just to keep
> the pandora box closed.

Perhaps.  While I strongly suspect it's an accidental bug rather than
an intentional art of obfuscation, I'm afraid we don't have an
evidence to prove (or deny) that in a court.

> Maybe a compromise is to either start a parallel effort to issue RFC8200bis
> or just propose a one page new 6man draft with clear statement that routing
> headers can be removed by nodes listed in the SRH segment list and move fwd
> ?

Hmm, what I proposed for draft-ietf-spring-srv6-network-programming is
essentially just that (in the context of, and with other restrictions
such as limiting it to the penultimate node, specific to
srv6-network-programming).

But if writing a separate document just focusing it (in which case
network-programming would refer to it as an example of that update)
makes the process faster, that can be an option.

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

> But, again, I expect not everyone agrees on this idea.  You probably
> won't; then I'll respect that.  Sometimes we just have to agree to
> disagree.

Well perhaps to your surprise I am all for clarity in the specifications.
So I have nothing against this spec (or any other spec) to formally update
RFC8200. But correct me if I am wrong - but this would require also 6man
WGLC if I am not mistaken in the process ?

But as you just mentioned there was "hundreds if not thousands of email
messages" regarding header insertion/deletion in flight on 6man and that is
why some authors may be actually resisting to take that path - just to keep
the pandora box closed.

Maybe a compromise is to either start a parallel effort to issue RFC8200bis
or just propose a one page new 6man draft with clear statement that routing
headers can be removed by nodes listed in the SRH segment list and move fwd
?

Many thx,
R.

On Sat, Mar 7, 2020 at 3:21 AM 神明達哉  wrote:

> At Fri, 6 Mar 2020 23:37:37 +0100,
> Robert Raszuk  wrote:
>
> > But in the same time I hear from both SR folks as well as 6man AD that
> the
> > current language of RFC8200 is purposely left to only say that only pure
> > transit nodes can not mess with the the IPv6 headers in any way while in
> > the same time node which address (/128 or less) is verbatim placed in
> > destination address field of the outermost IPv6 header can.
>
> Hmm, do you mean Suresh by "6man AD"?  Or do you mean 6mah WG chair(s)?
> I didn't think Suresh said it was intentionally left ambiguous so that
> it could allow a non-final destination node can remove an EH...Maybe
> you're referring to this message?
> https://mailarchive.ietf.org/arch/msg/ipv6/f-MzcHlmeklMXJ0E63TTzij4YQI/
>
> On re-reading it now, it's actually subtle: "We ended up strengthening
> some constraints while leaving some others open" or "it is impossible
> to determine after the fact if a different text formulation would have
> gotten consensus" could read as if this loophole was intentional, but
> the wording is so nuanced and I'm not sure if that's his intent.
>
> > I do not know if this is compliant with the IPv6 architecture spirit, but
> > when we process drafts which refer to prior RFCs we must base them on the
> > actual text and not the intentions of those who wrote it.
>
> I agree if this were a discussion on a law in a court, and I also tend
> to agree for an engineering discussion in general: after all
> "intentions" are generally a subjective matter.  But, in this case, it
> was clearly (to me) a bug of RFC8200, if only because this
> interpretation could still allow breaking PMTUD.  Recalling we spent
> hundreds if not thousands of email messages on whether we can allow
> it, it's really a surprise to me if it's just not a wording bug but an
> intentionally left loophole.  If my reading of this thread is correct,
> it was not only me who were surprised at it.
>
> From this point of view, publishing another document with its
> validity based on a bug will mean we're making another bug, and that's
> unfortunate from an engineering point of view.  Hence my sketch
> proposal: behavior-wise it's no different from network-programming-12
> (the penultimate node can still remove the SRH), but just based on a
> bug-fixed version of RFC8200 by updating it, thereby making
> network-programming less buggy as well.  I sincerely thought it would
> have a higher chance to be accepted: for the supporters of
> network-programming there's no change for implementations and
> operations; for those disagreeing it conforms to RFC8200, at least
> there's now no such reason (some people may still disagree with the
> update rationales, but I suspect that would be the same whether it
> tries to claim conformance or update).
>
> But, again, I expect not everyone agrees on this idea.  You probably
> won't; then I'll respect that.  Sometimes we just have to agree to
> disagree.
>
> > So while we are at it what puzzles me more now is to clearly understand
> > under what precise conditions the actual SRH insertion can take place
> since
> > the advice from IPv6 community was to move it to a different draft. One
> was
> > clearly articulated - assure the packets will not get dropped due to such
> > SRH insertion. Valid. Is there something more ?
> >
> > Procedurally I understand that as long as this new spinned off draft
> > updates RFC8200 we should be all ok. Is this a correct assumption ?
>
> Sorry, I'm not sure how to interpret these two paragraph...is it
> related to draft-ietf-spring-srv6-network-programming-12?
>
> --
> JINMEI, Tatuya
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Fri, 6 Mar 2020 23:37:37 +0100,
Robert Raszuk  wrote:

> But in the same time I hear from both SR folks as well as 6man AD that the
> current language of RFC8200 is purposely left to only say that only pure
> transit nodes can not mess with the the IPv6 headers in any way while in
> the same time node which address (/128 or less) is verbatim placed in
> destination address field of the outermost IPv6 header can.

Hmm, do you mean Suresh by "6man AD"?  Or do you mean 6mah WG chair(s)?
I didn't think Suresh said it was intentionally left ambiguous so that
it could allow a non-final destination node can remove an EH...Maybe
you're referring to this message?
https://mailarchive.ietf.org/arch/msg/ipv6/f-MzcHlmeklMXJ0E63TTzij4YQI/

On re-reading it now, it's actually subtle: "We ended up strengthening
some constraints while leaving some others open" or "it is impossible
to determine after the fact if a different text formulation would have
gotten consensus" could read as if this loophole was intentional, but
the wording is so nuanced and I'm not sure if that's his intent.

> I do not know if this is compliant with the IPv6 architecture spirit, but
> when we process drafts which refer to prior RFCs we must base them on the
> actual text and not the intentions of those who wrote it.

I agree if this were a discussion on a law in a court, and I also tend
to agree for an engineering discussion in general: after all
"intentions" are generally a subjective matter.  But, in this case, it
was clearly (to me) a bug of RFC8200, if only because this
interpretation could still allow breaking PMTUD.  Recalling we spent
hundreds if not thousands of email messages on whether we can allow
it, it's really a surprise to me if it's just not a wording bug but an
intentionally left loophole.  If my reading of this thread is correct,
it was not only me who were surprised at it.

>From this point of view, publishing another document with its
validity based on a bug will mean we're making another bug, and that's
unfortunate from an engineering point of view.  Hence my sketch
proposal: behavior-wise it's no different from network-programming-12
(the penultimate node can still remove the SRH), but just based on a
bug-fixed version of RFC8200 by updating it, thereby making
network-programming less buggy as well.  I sincerely thought it would
have a higher chance to be accepted: for the supporters of
network-programming there's no change for implementations and
operations; for those disagreeing it conforms to RFC8200, at least
there's now no such reason (some people may still disagree with the
update rationales, but I suspect that would be the same whether it
tries to claim conformance or update).

But, again, I expect not everyone agrees on this idea.  You probably
won't; then I'll respect that.  Sometimes we just have to agree to
disagree.

> So while we are at it what puzzles me more now is to clearly understand
> under what precise conditions the actual SRH insertion can take place since
> the advice from IPv6 community was to move it to a different draft. One was
> clearly articulated - assure the packets will not get dropped due to such
> SRH insertion. Valid. Is there something more ?
>
> Procedurally I understand that as long as this new spinned off draft
> updates RFC8200 we should be all ok. Is this a correct assumption ?

Sorry, I'm not sure how to interpret these two paragraph...is it
related to draft-ietf-spring-srv6-network-programming-12?

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

Dear Jinmei-san,

Thank you for your efforts to explain the spirit of RFC8200. I think we all
agree now that those who worked on IPv6 from the start by ultimate
destination consider either the destination which src host's socket puts in
the packet or (which I admit I never realized before this thread) the
*final* source routed node.

But in the same time I hear from both SR folks as well as 6man AD that the
current language of RFC8200 is purposely left to only say that only pure
transit nodes can not mess with the the IPv6 headers in any way while in
the same time node which address (/128 or less) is verbatim placed in
destination address field of the outermost IPv6 header can.

In that way I stated that PSP is compliant with current language of
RFC8200.

I do not know if this is compliant with the IPv6 architecture spirit, but
when we process drafts which refer to prior RFCs we must base them on the
actual text and not the intentions of those who wrote it.

So while we are at it what puzzles me more now is to clearly understand
under what precise conditions the actual SRH insertion can take place since
the advice from IPv6 community was to move it to a different draft. One was
clearly articulated - assure the packets will not get dropped due to such
SRH insertion. Valid. Is there something more ?

Procedurally I understand that as long as this new spinned off draft
updates RFC8200 we should be all ok. Is this a correct assumption ?

Many thx,
Robert.


On Fri, Mar 6, 2020 at 10:48 PM 神明達哉  wrote:

> At Thu, 5 Mar 2020 04:08:28 +,
> "Ketan Talaulikar (ketant)"  wrote:
>
> > If we argue this behavior as not violating "extension headers cannot be
> removed from a packet until it has arrived at its ultimate destination"
> because "segment left" is 0 at that point (and therefore
> > S2 is the "final destination"), that's a very innovative interpretation
> of the specification (not really surprisingly, given how "innovative" SRv6
> people are:-).  In fact, with that kind of logic, we could write a
> specification which allows any intermediate node in a routing header
> decreases the segment left to 0 (regardless of the previous value of it) at
> its own discretion, and then claim it's the final (ultimate) destination
> and does whatever is allowed for the final destination node.
> >
> > [KT] This is definitely not the argument. Please check this link for the
> explanation of the logic :
> https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/
>
> This link's explanation is that RFC8200 does NOT mean "extension
> headers cannot be removed from a packet until it has arrived at its
> ultimate destination" (and therefore PSP doesn't violate it), isn't
> it?  Then please remember the context of this conversation - it
> started with this comment by Robert:
>
> >> Even if RFC8200 section 4 text would say:
>
> >> "Extension headers cannot be added to a packet after it has left
> >> its source node and extension headers cannot be removed from a
> >> packet until it has arrived at its ultimate destination".
>
> >> PSP would be still not be violating anything said in this
> >> sentence.
>
> And I wondered about the logic how "it would *still* be not violate the
> RFC".  So this link's explanation isn't relevant to this specific
> discussion.
>
> As for that link's explanation, I already explained why that
> interpretation doesn't make sense, probably several times, so I won't
> repeat it again.  I know not everyone agrees with my explanation, and
> I'm pretty sure no further explanation can change the mind of people
> who firmly believe this link's argument, so there's no need for
> repeating the position.
>
> I guess that's the same for the rest of your response (sorry for not
> addressing these one by one but).  I knew not everyone would
> agree/support my arguments and suggestions.  From your response, it
> looks like I already made my points clear enough, you understood them
> correctly, and still disagreed with those.  At this point, I suspect
> we'll just have to agree to disagree than wasting everyone's time to
> keep making essentially the same points again and again.
>
> I guess the only feasible next move of mine is to bring my points to
> whatever next round of the process (another WGLC or IETF LC).
>
> --
> JINMEI, Tatuya
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Thu, 5 Mar 2020 04:08:28 +,
"Ketan Talaulikar (ketant)"  wrote:

> If we argue this behavior as not violating "extension headers cannot be 
> removed from a packet until it has arrived at its ultimate destination" 
> because "segment left" is 0 at that point (and therefore
> S2 is the "final destination"), that's a very innovative interpretation of 
> the specification (not really surprisingly, given how "innovative" SRv6 
> people are:-).  In fact, with that kind of logic, we could write a 
> specification which allows any intermediate node in a routing header 
> decreases the segment left to 0 (regardless of the previous value of it) at 
> its own discretion, and then claim it's the final (ultimate) destination and 
> does whatever is allowed for the final destination node.
>
> [KT] This is definitely not the argument. Please check this link for the 
> explanation of the logic : 
> https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/

This link's explanation is that RFC8200 does NOT mean "extension
headers cannot be removed from a packet until it has arrived at its
ultimate destination" (and therefore PSP doesn't violate it), isn't
it?  Then please remember the context of this conversation - it
started with this comment by Robert:

>> Even if RFC8200 section 4 text would say:

>> "Extension headers cannot be added to a packet after it has left
>> its source node and extension headers cannot be removed from a
>> packet until it has arrived at its ultimate destination".

>> PSP would be still not be violating anything said in this
>> sentence.

And I wondered about the logic how "it would *still* be not violate the
RFC".  So this link's explanation isn't relevant to this specific
discussion.

As for that link's explanation, I already explained why that
interpretation doesn't make sense, probably several times, so I won't
repeat it again.  I know not everyone agrees with my explanation, and
I'm pretty sure no further explanation can change the mind of people
who firmly believe this link's argument, so there's no need for
repeating the position.

I guess that's the same for the rest of your response (sorry for not
addressing these one by one but).  I knew not everyone would
agree/support my arguments and suggestions.  From your response, it
looks like I already made my points clear enough, you understood them
correctly, and still disagreed with those.  At this point, I suspect
we'll just have to agree to disagree than wasting everyone's time to
keep making essentially the same points again and again.

I guess the only feasible next move of mine is to bring my points to
whatever next round of the process (another WGLC or IETF LC).

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Brian E Carpenter]

> If we argue this behavior as not violating "extension headers cannot be 
> removed from a packet until it has arrived at its ultimate destination"

That is not, perhaps unfortunately, what RFC 8200 says.

Regards
   Brian Carpenter

On 05-Mar-20 17:08, Ketan Talaulikar (ketant) wrote:
> Hi Jinmei,
> 
>  
> 
> Please check inline below.
> 
>  
> 
> -Original Message-
> From: ipv6  On Behalf Of 
> Sent: 05 March 2020 05:15
> To: Pablo Camarillo (pcamaril) 
> Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden ; Robert 
> Raszuk 
> Subject: Re: [spring] Suggest some text //RE: Request to close the LC and 
> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
> 
>  
> 
> At Wed, 4 Mar 2020 12:17:07 +,
> 
> "Pablo Camarillo (pcamaril)"  <mailto:pcamaril=40cisco@dmarc.ietf.org>> wrote:
> 
>  
> 
>> Inline PC1.
> 
>  
> 
> Thank you for the clarification.  I'm not sure why you included the expanded 
> processing logic instead of just saying correct or incorrect
> 
> here:
> 
> */[KT] I believe Pablo might have done this as a hint on how to look at the 
> processing logic of the PSP flavor in the conjunction with the SID behavior 
> pseudocode./*
> 
>  
> 
>> PC1:
> 
>> 
> 
>> This is the exact processing at S2 combined End (4.1) with PSP (4.16.1):
> 
>  
> 
> but I interpret the entire response as my understanding is correct.
> 
>  
> 
> Then, going back to the message from Robert:
> 
>  
> 
>>>> "Extension headers cannot be added to a packet after it has left its
> 
>>>> source node and extension headers cannot be removed from a packet
> 
>>>> until it has arrived at its ultimate destination".
> 
>> 
> 
>>> PSP would be still not be violating anything said in this sentence.
> 
>>> Reason being is that we are dealing here with an *encapsulated*
> 
>>> packet which has as its ultimate destination SR node X. That SR node
> 
>>> X is to perform or not PSP. So it is still fully compliant with the 
>>> specification.
> 
>  
> 
> This explanation is still cryptic to me, but based on the 
> now-hopefully-correct understanding of the PSP behavior,
> 
> - We originally have (T, S1) (S3, S2, S1; SL=2) [payload=encapsulated
> 
> IPv6 pakcet]
> 
>   There are 3 nodes in the routing header.
> 
> - At the node identified by S2 (second node in the routing header), we
> 
>   remove the routing header, so we have (T, S3) [payload=encapsulated
> 
> IPv6 pakcet]
> 
> - Packet arrives at the node identified by S3, the payload is processed
> 
> */[KT] This is correct at a high level. The last line is about processing per 
> the behaviour of the SID S3 – e.g. when it is End.DT6 it would be to decap, 
> perform lookup in the VRF associated with the SID and then forward the inner 
> IPv6 packet./*
> 
>  
> 
> If we argue this behavior as not violating "extension headers cannot be 
> removed from a packet until it has arrived at its ultimate destination" 
> because "segment left" is 0 at that point (and therefore
> 
> S2 is the "final destination"), that's a very innovative interpretation of 
> the specification (not really surprisingly, given how "innovative" SRv6 
> people are:-).  In fact, with that kind of logic, we could write a 
> specification which allows any intermediate node in a routing header 
> decreases the segment left to 0 (regardless of the previous value of it) at 
> its own discretion, and then claim it's the final (ultimate) destination and 
> does whatever is allowed for the final destination node.
> 
> */[KT] This is definitely not the argument. Please check this link for the 
> explanation of the logic : 
> /*https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/
> 
>  
> 
> Overall, it seems so artificial, if not cheating, only for avoiding to be 
> told that it violates RFC8200.  The PSP behavior essentially gives an 
> intermediate ("penultimate") node in the routing header an option to remove 
> the routing header from the packet.  I can't think of a reason why we can't 
> just say so and say that it updates the corresponding part of RFC8200 
> accordingly, than for cheaply avoiding the discussions involved in updates to 
> an existing standard.
> 
> */[KT] Nothing artificial and no cheating. Things are clear as indicated in 
> the previous link. At least that is what the authors and (in my reading) a 
> significant number of other Spring WG members are saying. Please also check 
> the following:/*
> 
>

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Ketan Talaulikar (ketant)]

Hi Jinmei,



Please check inline below.



-Original Message-
From: ipv6  On Behalf Of 
Sent: 05 March 2020 05:15
To: Pablo Camarillo (pcamaril) 
Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden ; Robert 
Raszuk 
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming



At Wed, 4 Mar 2020 12:17:07 +,

"Pablo Camarillo (pcamaril)" 
mailto:pcamaril=40cisco@dmarc.ietf.org>>
 wrote:



> Inline PC1.



Thank you for the clarification.  I'm not sure why you included the expanded 
processing logic instead of just saying correct or incorrect

here:

[KT] I believe Pablo might have done this as a hint on how to look at the 
processing logic of the PSP flavor in the conjunction with the SID behavior 
pseudocode.



> PC1:

>

> This is the exact processing at S2 combined End (4.1) with PSP (4.16.1):



.but I interpret the entire response as my understanding is correct.



Then, going back to the message from Robert:



>>> "Extension headers cannot be added to a packet after it has left its

>>> source node and extension headers cannot be removed from a packet

>>> until it has arrived at its ultimate destination".

>

>> PSP would be still not be violating anything said in this sentence.

>> Reason being is that we are dealing here with an *encapsulated*

>> packet which has as its ultimate destination SR node X. That SR node

>> X is to perform or not PSP. So it is still fully compliant with the 
>> specification.



This explanation is still cryptic to me, but based on the now-hopefully-correct 
understanding of the PSP behavior,

- We originally have (T, S1) (S3, S2, S1; SL=2) [payload=encapsulated

IPv6 pakcet]

  There are 3 nodes in the routing header.

- At the node identified by S2 (second node in the routing header), we

  remove the routing header, so we have (T, S3) [payload=encapsulated

IPv6 pakcet]

- Packet arrives at the node identified by S3, the payload is processed

[KT] This is correct at a high level. The last line is about processing per the 
behaviour of the SID S3 - e.g. when it is End.DT6 it would be to decap, perform 
lookup in the VRF associated with the SID and then forward the inner IPv6 
packet.



If we argue this behavior as not violating "extension headers cannot be removed 
from a packet until it has arrived at its ultimate destination" because 
"segment left" is 0 at that point (and therefore

S2 is the "final destination"), that's a very innovative interpretation of the 
specification (not really surprisingly, given how "innovative" SRv6 people 
are:-).  In fact, with that kind of logic, we could write a specification which 
allows any intermediate node in a routing header decreases the segment left to 
0 (regardless of the previous value of it) at its own discretion, and then 
claim it's the final (ultimate) destination and does whatever is allowed for 
the final destination node.

[KT] This is definitely not the argument. Please check this link for the 
explanation of the logic : 
https://mailarchive.ietf.org/arch/msg/spring/kV6By4pnvbURdU1O7khwPbk_saM/



Overall, it seems so artificial, if not cheating, only for avoiding to be told 
that it violates RFC8200.  The PSP behavior essentially gives an intermediate 
("penultimate") node in the routing header an option to remove the routing 
header from the packet.  I can't think of a reason why we can't just say so and 
say that it updates the corresponding part of RFC8200 accordingly, than for 
cheaply avoiding the discussions involved in updates to an existing standard.

[KT] Nothing artificial and no cheating. Things are clear as indicated in the 
previous link. At least that is what the authors and (in my reading) a 
significant number of other Spring WG members are saying. Please also check the 
following:

https://mailarchive.ietf.org/arch/msg/spring/or8086G4iYfee5_Icw4PnhkPLBo/

https://mailarchive.ietf.org/arch/msg/spring/CmT-8nSZs8O8i9N9dD8gHd6uHAo/ (and 
the links provided by Martin on his previous email on that same thread)



Now, I've noticed an argument whether or not this spec violates/updates RFC8200 
isn't important.  In a sense I see the point:

what matters is to discuss the effect of the proposed behavior and make sure it 
doesn't cause unexpected problems; whether it updates the pre-exiting spec is a 
matter of formality in some sense.  But in this specific case, I still believe 
that's a bad move for two reasons:

[KT] I see a significant amount of discussion on the WG to discuss and conclude 
that there are no technical problems. In that same spirit, let us also look at 
your “reasons”.



1. (seemingly) as a result of trying to insist it's standard

   compliant, the processing logic becomes unnecessarily cryptic.

   There's essentially no nee

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[John Scudder]

Thanks for writing this.

> On Mar 4, 2020, at 6:45 PM, 神明達哉  wrote:
[...]
> If I were to offer something in order to be hopefully more
> constructive, that would be something like this:
> 
> - Add a tag of "Updates RFC8200 (if approved)"
[...]

Text elided not due to irrelevance, but because it’s all relevant but there’s 
no need to quote and repost it all.

I find your analysis and suggestion both constructive and compelling.

Regards,

—John
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Wed, 4 Mar 2020 12:17:07 +,
"Pablo Camarillo (pcamaril)"  wrote:

> Inline PC1.

Thank you for the clarification.  I'm not sure why you included the
expanded processing logic instead of just saying correct or incorrect
here:

> PC1:
>
> This is the exact processing at S2 combined End (4.1) with PSP (4.16.1):

but I interpret the entire response as my understanding is correct.

Then, going back to the message from Robert:

>>> "Extension headers cannot be added to a packet after it has left its
>>> source node and extension headers cannot be removed from a packet until it
>>> has arrived at its ultimate destination".
>
>> PSP would be still not be violating anything said in this sentence. Reason
>> being is that we are dealing here with an *encapsulated* packet which has
>> as its ultimate destination SR node X. That SR node X is to perform or not
>> PSP. So it is still fully compliant with the specification.

This explanation is still cryptic to me, but based on the
now-hopefully-correct understanding of the PSP behavior,
- We originally have (T, S1) (S3, S2, S1; SL=2) [payload=encapsulated
IPv6 pakcet]
  There are 3 nodes in the routing header.
- At the node identified by S2 (second node in the routing header), we
  remove the routing header, so we have (T, S3) [payload=encapsulated
IPv6 pakcet]
- Packet arrives at the node identified by S3, the payload is processed

If we argue this behavior as not violating "extension headers cannot
be removed from a packet until it has arrived at its ultimate
destination" because "segment left" is 0 at that point (and therefore
S2 is the "final destination"), that's a very innovative
interpretation of the specification (not really surprisingly, given
how "innovative" SRv6 people are:-).  In fact, with that kind of
logic, we could write a specification which allows any intermediate
node in a routing header decreases the segment left to 0 (regardless
of the previous value of it) at its own discretion, and then claim
it's the final (ultimate) destination and does whatever is allowed for
the final destination node.

Overall, it seems so artificial, if not cheating, only for avoiding to
be told that it violates RFC8200.  The PSP behavior essentially gives
an intermediate ("penultimate") node in the routing header an option
to remove the routing header from the packet.  I can't think of a
reason why we can't just say so and say that it updates the
corresponding part of RFC8200 accordingly, than for cheaply avoiding
the discussions involved in updates to an existing standard.

Now, I've noticed an argument whether or not this spec
violates/updates RFC8200 isn't important.  In a sense I see the point:
what matters is to discuss the effect of the proposed behavior and
make sure it doesn't cause unexpected problems; whether it updates the
pre-exiting spec is a matter of formality in some sense.  But in this
specific case, I still believe that's a bad move for two reasons:

1. (seemingly) as a result of trying to insist it's standard
   compliant, the processing logic becomes unnecessarily cryptic.
   There's essentially no need to decrease 'segment left' and then
   check if it is 0.  A more explicit condition that it's the
   penultimate node is that 'segment left == 1' on receiving the
   packet; we can simply perform the special PSP behavior from there.
   If we're willing to say it updates RFC8200, we can simply say the
   penultimate node has an option to remove the routing header and
   show the more straightforward logic.
2. I'm afraid this would establish an unfortunate precedent for future
   protocol development to look for a wording loophole in existing
   standards and exploit it as an easy shortcut to publish something
   possibly controversial.  Just as we saw, even a very carefully
   reviewed document like RFC8200 always has some glitches and
   ambiguities.  If we allow casually exploiting these loopholes for
   the convenience of new protocol designers, more and more people
   will follow and we'll eventually have very inconsistent protocols
   and, in worse cases, loss of interoperabaility and other harm.  On
   the other hand, we could use this opportunity for a good precedent
   to show no standard is set in stone and can be updated with new
   developments and proper discussions and justifications.

For this reason, I disagree with this text of
draft-ietf-spring-srv6-network-programming-12:

   This behavior does not contravene Section 4 of [RFC8200] because the
   current destination address of the incoming packet is the address of
   the node executing the PSP behavior.

If I were to offer something in order to be hopefully more
constructive, that would be something like this:

- Add a tag of "Updates RFC8200 (if approved)"

- In Section 4.16.1, simply say something like: "A penultimate SR
  Segment Node MAY remove the SRH from the IPv6 packet it forwards,
  even if it is not the final (ultimate) destination in the path
  specified in the 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Pablo Camarillo (pcamaril)]

Dear Jinmei-san,



Inline PC1.



Thanks,

Pablo.



-Original Message-

From: ipv6  on behalf of 神明達哉 

Date: Tuesday, 3 March 2020 at 00:21

To: Robert Raszuk 

Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>, Bob 
Hinden 

Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming



At Sat, 29 Feb 2020 12:06:17 +0100,

Robert Raszuk  wrote:



> Even if RFC8200 section 4 text would say:

>

>  "Extension headers cannot be added to a packet after it has left its

> source node and extension headers cannot be removed from a packet until it

> has arrived at its ultimate destination".

>

> PSP would be still not be violating anything said in this sentence. Reason

> being is that we are dealing here with an *encapsulated* packet which has

> as its ultimate destination SR node X. That SR node X is to perform or not

> PSP. So it is still fully compliant with the specification.



(Sorry for the hopefully small delay, I've been out of town for these

several days and am now catching up with the backlog).



Hmm, so, using the notation shown in Section 5.1 of

draft-ietf-spring-srv6-network-programming-10, is this how the PSP is

expected to work?



- Node N creates an encapsulated IPv6 packet:

  (T, S1) (S3, S2, S1; SL=2) (A, B2)

- at S1, since SL != 0,

  decrease SL to 1,

  copy SList[SL] = SList[1] = S2 to the destination address of the

  IPv6 header, so we now have:

  (T, S2) (S3, S2, S1; SL=1) (A, B2)

PC1: Correct



- at S2, since SL != 0,

  decrease SL to 0

  copy SList[SL] = SList[0] = S3 to the destination address of the

  IPv6 header, so we now have:

  (T, S3) (S3, S2, S1; SL=0) (A, B2)

  according to Section S14 of draft-ietf-spring-srv6-network-programming-10.

- Now we apply Section 4.16.1 (PSP).

  Since SL == 0 at this point, Payload length and next header value

  are adjusted, RH is removed, and we now have:

  (T, S3) (A, B2)



PC1:

This is the exact processing at S2 combined End (4.1) with PSP (4.16.1):


  S01. When an SRH is processed {
  S02.   If (Segments Left == 0) {
  S03.  Send an ICMP Parameter Problem message to the Source Address
   Code 4 (SR Upper-layer Header Error),
   Pointer set to the offset of the upper-layer header.
   Interrupt packet processing and discard the packet.
  S04.   }
  S05.   If (IPv6 Hop Limit <= 1) {
  S06.  Send an ICMP Time Exceeded message to the Source Address,
   Code 0 (Hop limit exceeded in transit),
   Interrupt packet processing and discard the packet.
  S07.   }
  S08.   max_LE = (Hdr Ext Len / 2) - 1
  S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
  S10.  Send an ICMP Parameter Problem to the Source Address,
   Code 0 (Erroneous header field encountered),
   Pointer set to the Segments Left field.
   Interrupt packet processing and discard the packet.

  S11.   }
  S12.   Decrement Hop Limit by 1
  S13.   Decrement Segments Left by 1
  S14.   Update IPv6 DA with Segment List[Segments Left]
  S14.1.   If (Segments Left == 0) {
 S14.2.  Update the Next Header field in the preceding header to the
Next Header value of the SRH
 S14.3.  Decrease the IPv6 header Payload Length by the Hdr Ext Len
value of the SRH
 S14.4.  Remove the SRH from the IPv6 extension header chain
 S14.5.   }
  S15.   Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
  S16. }




It's not clear what will happen next from the text of

draft-ietf-spring-srv6-network-programming-10, but is presumably it as

follows?



- The packet will be forwarded to S3

- At S3, since it's the (ultimate) destination of the outper IPv6

  packet, it decapsulates the packet, and we now have:

  (A, B2)

- The decapsulated packet is forwarded towards B2



PC1: This is correct.

Please note that there have been many editorial changes in the PSP section of 
the document. Hence I suggest you review revision 11.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-11#section-4.16.1





Many thanks,

Pablo.



--

JINMEI, Tatuya





IETF IPv6 working group mailing list

i...@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra]

I read the updated version 11 and the verbiage looks very good and provides
all the necessary clarity in the process.

https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-11#section-4.16.1

For 6MAN in terms of RFC 8200 as Brian Carpenter mentioned and noticed in
assistance in adding to the latest verbiage it really helped.

The key is that to the PSP node the incoming SL is 1 - but after the final
DA is copied the SL pointer is updated so  the outgoing SL is 0  - this
satisfying the pseudocode criteria and RFC 8200 to remove the SRH since the
final DA is now set.


If you look at this before the packet is received then it appears as in
flight and not final destination so it may appear not in RFC 8200
conformance which has been the contention all along.  However,  if you look
at it after PSP node has received and processed the PSP function psuedocode
you are now in RFC 8200 conformance.


Kind regards

Gyan


On Tue, Mar 3, 2020 at 10:18 AM Darren Dukes (ddukes) 
wrote:

> Hi Jingrong, I notified Gyan yesterday that the version he was reviewing
> was over a year old.
> I expect when Gyan reviews the current version it should clear up any
> lingering questions.
>
> Darren
>
> On Mar 3, 2020, at 1:34 AM, Xiejingrong (Jingrong) 
> wrote:
>
> Hi Gyan,
> What revision are you reading ?
> I found the 4.21.1 only in its very early revision (-00 and -01).
> There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft
> is rev-11 :
> https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
> And I think the explanation of “A penultimate SR Segment Endpoint Node” in
> the latest rev is helpful to understand better:
>SR Segment Endpoint Nodes receive the IPv6 packet with the
>Destination Address field of the IPv6 Header equal to its SID
>address.  A penultimate SR Segment Endpoint Node is one that, as part
>of the SID processing, copies the last SID from the SRH into the IPv6
>Destination Address and decrements Segments Left value from one to
>zero.
>
> Thanks
> Jingrong
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com ]
>
> *Sent:* Tuesday, March 3, 2020 12:52 PM
> *To:* Xiejingrong (Jingrong) 
> *Cc:* 6...@ietf.org; Bob Hinden ; spring@ietf.org;
> 神明達哉 
> *Subject:* Re: Suggest some text //RE: [spring] Request to close the LC
> and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
>
> Hi Jingrong
>
> I am following what you displayed and it makes sense. In section 4.21.1
> for the PSP flavor what was confusing was it said that the End.X with PSP
> flavor can pop the SRH.  The way it’s written,  to me it reads that any P
> router can pop the SRH when the last SID is written to the DA. So if the
> SRH SID list happens to not steer to the egress PE and ended a few hops
> early,  and If PSP is true then the SRH could be popped early on any P
> node.  Maybe I am reading to far into the verbiage.  I think since End.X
> could be any P transit router what I am saying could happen.
>
> 4.21.1
> .
> PSP: Penultimate Segment Pop of the SRH
>
>
>
>
>
>After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
>
>the following instructions must be added:
>
>
>
>  1.   IF updated SL = 0 & PSP is TRUE
>
>  2.  pop the top SRH ;; Ref1
>
>
>
>
>
>
>
>
>
>Ref1: The received SRH had SL=1.  When the last SID is written in the
>
>DA, the End, End.X and End.T functions with the PSP flavour pop the
>
>first (top-most) SRH.  Subsequent stacked SRH's may be present but
>
>are not processed as part of the function.
>
>
> At each hop each node copies the SID to DA and updates the SL = SL -1
>
> I am depicting an incoming SL value to each node and then each node
> updates the SL pointer along the path hop by hop.
>
> PSP mode
>
> CE1[PE1{SL=2} - P2--{SL=1} -P3--pop--PE4]CE2
>
> PSP disabled (USP)
>
> CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]CE2
>
> USD  (USD) - Decapsulation & forward native packet payload to customer CE
>
> CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]CE2
>
> Thanks
>
> Gyan
>
> On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) <
> xiejingr...@huawei.com> wrote:
>
> Hi Gyan,
> In my understanding, PSP is used right in a P node, works for both End and
> End.X ( I haven’t known End.T very well yet).
>
> Suppose:
> CE1[PE1P2P3PE4]CE2
> PE1 encapsulation the customer packet with an outer IPv6 header and an
> SRH, the packet arriving P2 will be:
> (SA=PE1, DA=P2) (SL=2, PE4, P3, P2)
>  (customer-packet)
>
> Then, the packet arriving P3 will be:
> (SA=PE1, DA=P3) (SL=1, PE4, P3, P2)
>  (customer-packet)
>
> In Non-PSP mode, the packet will be sent to PE4 like this:
> (SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)
>  (customer-packet)
>
> In PSP mode, the packet will be sent to PE4 like this:
> (SA=PE1, 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Darren Dukes (ddukes)]

Hi Jingrong, I notified Gyan yesterday that the version he was reviewing was 
over a year old.
I expect when Gyan reviews the current version it should clear up any lingering 
questions.

Darren

On Mar 3, 2020, at 1:34 AM, Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:

Hi Gyan,
What revision are you reading ?
I found the 4.21.1 only in its very early revision (-00 and -01).
There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft is 
rev-11 : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
And I think the explanation of “A penultimate SR Segment Endpoint Node” in the 
latest rev is helpful to understand better:
   SR Segment Endpoint Nodes receive the IPv6 packet with the
   Destination Address field of the IPv6 Header equal to its SID
   address.  A penultimate SR Segment Endpoint Node is one that, as part
   of the SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements Segments Left value from one to
   zero.

Thanks
Jingrong

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, March 3, 2020 12:52 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: 6...@ietf.org; Bob Hinden 
mailto:bob.hin...@gmail.com>>; 
spring@ietf.org; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Jingrong

I am following what you displayed and it makes sense. In section 4.21.1 for the 
PSP flavor what was confusing was it said that the End.X with PSP flavor can 
pop the SRH.  The way it’s written,  to me it reads that any P router can pop 
the SRH when the last SID is written to the DA. So if the SRH SID list happens 
to not steer to the egress PE and ended a few hops early,  and If PSP is true 
then the SRH could be popped early on any P node.  Maybe I am reading to far 
into the verbiage.  I think since End.X could be any P transit router what I am 
saying could happen.

4.21.1.
  PSP: Penultimate Segment Pop of the SRH





   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,

   the following instructions must be added:



 1.   IF updated SL = 0 & PSP is TRUE

 2.  pop the top SRH ;; Ref1









   Ref1: The received SRH had SL=1.  When the last SID is written in the

   DA, the End, End.X and End.T functions with the PSP flavour pop the

   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.


At each hop each node copies the SID to DA and updates the SL = SL -1

I am depicting an incoming SL value to each node and then each node updates the 
SL pointer along the path hop by hop.

PSP mode

CE1[PE1{SL=2} - P2--{SL=1} -P3--pop--PE4]CE2

PSP disabled (USP)

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]CE2

USD  (USD) - Decapsulation & forward native packet payload to customer CE

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]CE2

Thanks

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and 
End.X ( I haven’t known End.T very well yet).

Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the 
packet arriving P2 will be:
(SA=PE1, DA=P2) (SL=2, PE4, P3, P2)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3) (SL=1, PE4, P3, P2)  
(customer-packet)

In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)  
(customer-packet)

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (customer-packet)

For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS 
identical to MPLS would be both a SR source node and final destination node of 
an LSP.”
I don’t think that’s always true, you can find an example I was recently 
thinking about in another mail: 
VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
Even if it is true for some network, the capability to handle the SRH on a 
receiving packet is different than the encapsulation of an outer IPv6 header 
with an SRH header.
Sending (with encapsulation) and receiving (with 
recognizing/processing/demultiplexing),  they are not necessarily the same  
like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but 
may fail to process a little thing that it is unrecognized.

It may just drop any packet with Next Header value other than 4/41/47/etc.

It may send such packet with any routing header to its slow-path for the 
compliance but lose the 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Gyan,
What revision are you reading ?
I found the 4.21.1 only in its very early revision (-00 and -01).
There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft is 
rev-11 : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
And I think the explanation of “A penultimate SR Segment Endpoint Node” in the 
latest rev is helpful to understand better:
   SR Segment Endpoint Nodes receive the IPv6 packet with the
   Destination Address field of the IPv6 Header equal to its SID
   address.  A penultimate SR Segment Endpoint Node is one that, as part
   of the SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements Segments Left value from one to
   zero.

Thanks
Jingrong

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Tuesday, March 3, 2020 12:52 PM
To: Xiejingrong (Jingrong) 
Cc: 6...@ietf.org; Bob Hinden ; spring@ietf.org; 神明達哉 

Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Jingrong

I am following what you displayed and it makes sense. In section 4.21.1 for the 
PSP flavor what was confusing was it said that the End.X with PSP flavor can 
pop the SRH.  The way it’s written,  to me it reads that any P router can pop 
the SRH when the last SID is written to the DA. So if the SRH SID list happens 
to not steer to the egress PE and ended a few hops early,  and If PSP is true 
then the SRH could be popped early on any P node.  Maybe I am reading to far 
into the verbiage.  I think since End.X could be any P transit router what I am 
saying could happen.

4.21.1.
  PSP: Penultimate Segment Pop of the SRH





   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,

   the following instructions must be added:



 1.   IF updated SL = 0 & PSP is TRUE

 2.  pop the top SRH ;; Ref1









   Ref1: The received SRH had SL=1.  When the last SID is written in the

   DA, the End, End.X and End.T functions with the PSP flavour pop the

   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.

At each hop each node copies the SID to DA and updates the SL = SL -1

I am depicting an incoming SL value to each node and then each node updates the 
SL pointer along the path hop by hop.

PSP mode

CE1[PE1{SL=2} - P2--{SL=1} -P3--pop--PE4]CE2

PSP disabled (USP)

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]CE2

USD  (USD) - Decapsulation & forward native packet payload to customer CE

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]CE2

Thanks

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and 
End.X ( I haven’t known End.T very well yet).

Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the 
packet arriving P2 will be:
(SA=PE1, DA=P2) (SL=2, PE4, P3, P2)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3) (SL=1, PE4, P3, P2)  
(customer-packet)

In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)  
(customer-packet)

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (customer-packet)

For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS 
identical to MPLS would be both a SR source node and final destination node of 
an LSP.”
I don’t think that’s always true, you can find an example I was recently 
thinking about in another mail: 
VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
Even if it is true for some network, the capability to handle the SRH on a 
receiving packet is different than the encapsulation of an outer IPv6 header 
with an SRH header.
Sending (with encapsulation) and receiving (with 
recognizing/processing/demultiplexing),  they are not necessarily the same  
like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but 
may fail to process a little thing that it is unrecognized.

It may just drop any packet with Next Header value other than 4/41/47/etc.

It may send such packet with any routing header to its slow-path for the 
compliance but lose the necessary performance.

Thanks
Jingrong

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: 6...@ietf.org; Bob Hinden 
mailto:bob.hin...@gmail.com>>; 
spring@ietf.org; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: Suggest some text //RE: [spring] 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra]

Hi Jingrong

I am following what you displayed and it makes sense. In section 4.21.1 for
the PSP flavor what was confusing was it said that the End.X with PSP
flavor can pop the SRH.  The way it’s written,  to me it reads that any P
router can pop the SRH when the last SID is written to the DA. So if the
SRH SID list happens to not steer to the egress PE and ended a few hops
early,  and If PSP is true then the SRH could be popped early on any P
node.  Maybe I am reading to far into the verbiage.  I think since End.X
could be any P transit router what I am saying could happen.

4.21.1 
.
PSP: Penultimate Segment Pop of the SRH

   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
   the following instructions must be added:

 1.   IF updated SL = 0 & PSP is TRUE
 2.  pop the top SRH ;; Ref1





   Ref1: The received SRH had SL=1.  When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but
   are not processed as part of the function.


At each hop each node copies the SID to DA and updates the SL = SL -1

I am depicting an incoming SL value to each node and then each node updates
the SL pointer along the path hop by hop.

PSP mode

CE1[PE1{SL=2} - P2--{SL=1} -P3--pop--PE4]CE2

PSP disabled (USP)

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 pop]CE2

USD  (USD) - Decapsulation & forward native packet payload to customer CE

CE1[PE1{SL=2} - P2--{SL=1} -P3---{SL=0}--PE4 dencap]CE2

Thanks

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) <
xiejingr...@huawei.com> wrote:

> Hi Gyan,
>
> In my understanding, PSP is used right in a P node, works for both End and
> End.X ( I haven’t known End.T very well yet).
>
>
>
> Suppose:
>
> CE1[PE1P2P3PE4]CE2
>
> PE1 encapsulation the customer packet with an outer IPv6 header and an
> SRH, the packet arriving P2 will be:
>
> (SA=PE1, DA=P2) (SL=2, PE4, P3, P2)
>  (customer-packet)
>
>
>
> Then, the packet arriving P3 will be:
>
> (SA=PE1, DA=P3) (SL=1, PE4, P3, P2)
>  (customer-packet)
>
>
>
> In Non-PSP mode, the packet will be sent to PE4 like this:
>
> (SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)
>  (customer-packet)
>
>
>
> In PSP mode, the packet will be sent to PE4 like this:
>
> (SA=PE1, DA=PE4) (customer-packet)
>
>
>
> For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS
> identical to MPLS would be both a SR source node and final destination node
> of an LSP.”
>
> I don’t think that’s always true, you can find an example I was recently
> thinking about in another mail:
> VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
>
> Even if it is true for some network, the capability to handle the SRH on a
> receiving packet is different than the encapsulation of an outer IPv6
> header with an SRH header.
>
> Sending (with encapsulation) and receiving (with
> recognizing/processing/demultiplexing),  they are not necessarily the same
>  like the things to fragment and assembly.
>
> A PE may be well capable of encapsulation everything (like BFD template),
> but may fail to process a little thing that it is unrecognized.
>
> It may just drop any packet with Next Header value other than 4/41/47/etc..
>
> It may send such packet with any routing header to its slow-path for the
> compliance but lose the necessary performance.
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Monday, March 2, 2020 4:20 AM
> *To:* Xiejingrong (Jingrong) 
> *Cc:* 6...@ietf.org; Bob Hinden ; spring@ietf.org;
> 神明達哉 
> *Subject:* Re: Suggest some text //RE: [spring] Request to close the LC
> and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
>
>
> Hi Jingrong,
>
>
>
>
>
> Can you help provide some clarification on the use cases for PSP flavor
> with end.X and end.T functions.
>
>
>
> Under Ref1 where it mentions end.X and end.T functions to use PSP knob  as
> well if desired.
>
>
>
> How would that work with any P node using the PSP function?
>
>
>
> https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21
>
>
>
>
> 4.21.1
> .
> PSP: Penultimate Segment Pop of the SRH
>
>
>
>
>
>After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
>
>the following instructions must be added:
>
>
>
>  1.   IF updated SL = 0 & PSP is TRUE
>
>  2.  pop the top SRH ;; Ref1
>
>
>
> Ref1: The received SRH had SL=1.  When the last SID is written in the
>
>DA, the End, End.X and End.T functions with the PSP flavour pop the
>
>first (top-most) SRH.  Subsequent stacked SRH's 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Sat, 29 Feb 2020 12:06:17 +0100,
Robert Raszuk  wrote:

> Even if RFC8200 section 4 text would say:
>
>  "Extension headers cannot be added to a packet after it has left its
> source node and extension headers cannot be removed from a packet until it
> has arrived at its ultimate destination".
>
> PSP would be still not be violating anything said in this sentence. Reason
> being is that we are dealing here with an *encapsulated* packet which has
> as its ultimate destination SR node X. That SR node X is to perform or not
> PSP. So it is still fully compliant with the specification.

(Sorry for the hopefully small delay, I've been out of town for these
several days and am now catching up with the backlog).

Hmm, so, using the notation shown in Section 5.1 of
draft-ietf-spring-srv6-network-programming-10, is this how the PSP is
expected to work?

- Node N creates an encapsulated IPv6 packet:
  (T, S1) (S3, S2, S1; SL=2) (A, B2)
- at S1, since SL != 0,
  decrease SL to 1,
  copy SList[SL] = SList[1] = S2 to the destination address of the
  IPv6 header, so we now have:
  (T, S2) (S3, S2, S1; SL=1) (A, B2)
- at S2, since SL != 0,
  decrease SL to 0
  copy SList[SL] = SList[0] = S3 to the destination address of the
  IPv6 header, so we now have:
  (T, S3) (S3, S2, S1; SL=0) (A, B2)
  according to Section S14 of draft-ietf-spring-srv6-network-programming-10.
- Now we apply Section 4.16.1 (PSP).
  Since SL == 0 at this point, Payload length and next header value
  are adjusted, RH is removed, and we now have:
  (T, S3) (A, B2)

It's not clear what will happen next from the text of
draft-ietf-spring-srv6-network-programming-10, but is presumably it as
follows?
- The packet will be forwarded to S3
- At S3, since it's the (ultimate) destination of the outper IPv6
  packet, it decapsulates the packet, and we now have:
  (A, B2)
- The decapsulated packet is forwarded towards B2

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and 
End.X ( I haven’t known End.T very well yet).

Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the 
packet arriving P2 will be:
(SA=PE1, DA=P2) (SL=2, PE4, P3, P2)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3) (SL=1, PE4, P3, P2)  
(customer-packet)

In Non-PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (SL=0, PE4, P3, P2)  
(customer-packet)

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4) (customer-packet)

For you assumption, “Since every PE in an SR domain both SRv6 or SR-MPLS 
identical to MPLS would be both a SR source node and final destination node of 
an LSP.”
I don’t think that’s always true, you can find an example I was recently 
thinking about in another mail: 
VMTORSpineSuperspine[PE1P2P3PE4]subscribers.
Even if it is true for some network, the capability to handle the SRH on a 
receiving packet is different than the encapsulation of an outer IPv6 header 
with an SRH header.
Sending (with encapsulation) and receiving (with 
recognizing/processing/demultiplexing),  they are not necessarily the same  
like the things to fragment and assembly.
A PE may be well capable of encapsulation everything (like BFD template), but 
may fail to process a little thing that it is unrecognized.

It may just drop any packet with Next Header value other than 4/41/47/etc.

It may send such packet with any routing header to its slow-path for the 
compliance but lose the necessary performance.

Thanks
Jingrong

From: Gyan Mishra [mailto:hayabusa...@gmail.com]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) 
Cc: 6...@ietf.org; Bob Hinden ; spring@ietf.org; 神明達哉 

Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Jingrong,


Can you help provide some clarification on the use cases for PSP flavor with 
end.X and end.T functions.

Under Ref1 where it mentions end.X and end.T functions to use PSP knob  as well 
if desired.

How would that work with any P node using the PSP function?


https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21


4.21.1.
  PSP: Penultimate Segment Pop of the SRH





   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,

   the following instructions must be added:



 1.   IF updated SL = 0 & PSP is TRUE

 2.  pop the top SRH ;; Ref1


Ref1: The received SRH had SL=1.  When the last SID is written in the

   DA, the End, End.X and End.T functions with the PSP flavour pop the

   first (top-most) SRH.  Subsequent stacked SRH's may be present but

   are not processed as part of the function.

Also trying to understand the reason given for PSP function for legacy final 
destination egress PE not being SRv6 capable.

Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would be 
both a SR source node and final destination node of an LSP.  I am using the 
MPLS term LSP with SR as the concept of FEC destination which now is a prefix 
SID still exists that all traffic to egress final destination  PE is forwarded 
to.

Since LSPs built to FEC destination are uni directional as they are with MPLS  
and that would be the case as well for SR paths - the idea that the final 
destination PE would lack hardware capability for SRH processing does not make 
sense as the source and final destination node are one and the same.

Am I missing something?

Kind Regards

Gyan

On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>> wrote:
Got it.
Thanks for your clarification of your point.

Jingrong

-Original Message-
From: 神明達哉 [mailto:jin...@wide.ad.jp]
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: Ted Lemon mailto:mel...@fugue.com>>; Pablo Camarillo 
(pcamaril) mailto:pcama...@cisco.com>>; Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>>; Bob Hinden 
mailto:bob.hin...@gmail.com>>; Joel M. Halpern 
mailto:j...@joelhalpern.com>>; 
spring@ietf.org; 6...@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)" 
mailto:xiejingr...@huawei.com>> wrote:

> The design of PSP for the benefits of deployment is based on the
> understanding that it does not violate section 4 of RFC8200. In case
> the RFC8200 text may be modified in the future, the PSP may also need to 
> change accordingly.

No, it violates 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra]

Hi Jingrong,


Can you help provide some clarification on the use cases for PSP flavor
with end.X and end.T functions.

Under Ref1 where it mentions end.X and end.T functions to use PSP knob  as
well if desired.

How would that work with any P node using the PSP function?

https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21



4.21.1 
.
PSP: Penultimate Segment Pop of the SRH

   After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
   the following instructions must be added:

 1.   IF updated SL = 0 & PSP is TRUE
 2.  pop the top SRH ;; Ref1


Ref1: The received SRH had SL=1.  When the last SID is written in the
   DA, the End, End.X and End.T functions with the PSP flavour pop the
   first (top-most) SRH.  Subsequent stacked SRH's may be present but
   are not processed as part of the function.


Also trying to understand the reason given for PSP function for legacy
final destination egress PE not being SRv6 capable.

Since every PE in an SR domain both SRv6 or SR-MPLS identical to MPLS would
be both a SR source node and final destination node of an LSP.  I am using
the MPLS term LSP with SR as the concept of FEC destination which now is a
prefix SID still exists that all traffic to egress final destination  PE is
forwarded to.

Since LSPs built to FEC destination are uni directional as they are with
MPLS  and that would be the case as well for SR paths - the idea that the
final destination PE would lack hardware capability for SRH processing does
not make sense as the source and final destination node are one and the
same.

Am I missing something?

Kind Regards

Gyan

On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <
xiejingr...@huawei.com> wrote:

> Got it.
> Thanks for your clarification of your point.
>
> Jingrong
>
> -Original Message-
> From: 神明達哉 [mailto:jin...@wide.ad.jp]
> Sent: Saturday, February 29, 2020 9:28 AM
> To: Xiejingrong (Jingrong) 
> Cc: Ted Lemon ; Pablo Camarillo (pcamaril) <
> pcama...@cisco.com>; Brian E Carpenter ; Bob
> Hinden ; Joel M. Halpern ;
> spring@ietf.org; 6...@ietf.org
> Subject: Re: Suggest some text //RE: [spring] Request to close the LC and
> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
> At Fri, 28 Feb 2020 07:54:28 +,
> "Xiejingrong (Jingrong)"  wrote:
>
> > The design of PSP for the benefits of deployment is based on the
> > understanding that it does not violate section 4 of RFC8200. In case
> > the RFC8200 text may be modified in the future, the PSP may also need to
> change accordingly.
>
> No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss
> it at this level due to the poor editorial work then (I was also
> responsible for that as one of those reviewing the bis draft), but anyone
> who involved the discussion should know the intent of this text intended to
> say (borrowing from Ron's text) "Extension headers cannot be added to a
> packet after it has left the its source node and extension headers cannot
> be removed from a packet until it has arrived at its ultimate
> destination".  It might look "an attempt of blocking an innovation by a
> small group of vocal fundamentalists", but if you see the responses without
> a bias, you'd notice that even some of those who seem neutral about the
> underlying SRv6 matter interpret the text that way.
>
> I'd also note that simply because PSP violates RFC8200 doesn't immediately
> mean it (PSP) "needs to change".  It can update RFC8200 with explaining why
> it's necessary and justified.  That's what I requested as you summarized:
>
> > Jinmei: it should say it updates this part of RFC8200 and explain why
> it's justified.
>
> And, since PSP at least wouldn't break PMTUD, I guess the update proposal
> will have much more chance to be accepted than a proposal including EH
> insertion.  On the other hand, pretending there's no violation will
> certainly trigger many appeals and objections at the IETF last call (I'll
> certainly object to it).  In the end, it can easily take much longer, or
> even fail, than formally claiming an update to RFC8200.
>
> --
> JINMEI, Tatuya
> 
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Zafar Ali (zali)]

Hi Joel,

_All_ the existing IPv6 OAM tools will send OAM probes encoding the “actual PSP 
SID” in the packet (just mimicking data packets).
The penultimate node does not and cannot differentiate between the data packets 
and OAM probes and executes the exact same PSP SID.
None of the existing IPv6 OAM tools has any dependency on the SRH presence.
Like I mention, we can add clarification in the OAM draft.

Thanks

Regards … Zafar

From: "Joel M. Halpern" 
Date: Sunday, March 1, 2020 at 9:09 AM
To: "Zafar Ali (zali)" 
Cc: "6...@ietf.org" <6...@ietf.org>, spring 
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Zafar, I seem to have missed something.  I understand how the SRv6 OAM
works with a SID that happens to be a PSP SID, up until we get to the
step from the penultimate hop to the ultimate hop.  At the penultiamte
hop, everything works.  But before getting to the ultimate hop, the SRH
is stripped.  Therefore, at the ultimate hop no OAM can take place for
the path with PSP.
If you define the O bit to over-ride the PSP processing, that in and of
itself means that the packets on that final leg are different, again
modifying the intended behavior of OAM.

I will be happy if you can explain how you found a way out of this
conundrum.

Yours,
Joel

On 3/1/2020 8:57 AM, Zafar Ali (zali) wrote:
Greg, Joel,
_All_ the existing IPv6 OAM tools (e.g., ICMP, traceroute, TWAMP, BFD,
etc.) works “as-is” for the PSP SID.
They shall exercise the FIB entry for the PSP SIDs, follow the same path
as PSP SIDs, etc.
We can add clarification in the OAM draft.
Thanks
Regards … Zafar
*From: *spring mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky
mailto:gregimir...@gmail.com>>
*Date: *Sunday, March 1, 2020 at 8:32 AM
*To: *Robert Raszuk mailto:rob...@raszuk.net>>
*Cc: *"6...@ietf.org<mailto:6...@ietf.org>" 
<6...@ietf.org<mailto:6...@ietf.org>>, spring 
mailto:spring@ietf.org>>, "Joel
M. Halpern" mailto:j...@joelhalpern.com>>, 
神明達哉mailto:jin...@wide.ad.jp>>
*Subject: *Re: [spring] Suggest some text //RE: Request to close the LC
and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Robert,
yes, the path probably will be the same regardless whether PSP was
applied or not. But performance metrics, e.g. packet delay, may be
different for OAM and "regular" packets.
Regards,
Greg
On Sun, Mar 1, 2020, 14:08 Robert Raszuk 
mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net><mailto:rob...@raszuk.net%3e>> wrote:
 Nope.
 Node can advertise two SIDs or PSP in a given network may be a well
 know function (to limit IGP burden) Example: odd SID includes PSP
 and even SID does not.
 O*A*M  packets can use on the exact same path but the penultimate
 hop traversal is directed by even SID and is not subject to PSP..
 Done.
 Thx,
 R.
 On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern 
mailto:j...@joelhalpern.com>
 <mailto:j...@joelhalpern.com><mailto:j...@joelhalpern.com%3e>> wrote:
 Presuming that by "OEM" you mean "OAM", then no, this does not work.
 If the OAM is intended to monitor a path that has a last SID whose
 flavor is PSP, then something will break.  The monitoring will
 monitor
 something else, or it won't monitor the last hop, or...
 Given the point that was made that ignoring a source route (SRH or
 otherwise) with segments-left = 0 is a mandatory behavior of
 8200, I am
 really left puzzled as to what use case justifies the contortion
 of PSP.
 Yours,
 Joel
 
 IETF IPv6 working group mailing list
 i...@ietf.org<mailto:i...@ietf.org> <mailto:i...@ietf.org>
 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Joel M. Halpern]

Zafar, I seem to have missed something.  I understand how the SRv6 OAM 
works with a SID that happens to be a PSP SID, up until we get to the 
step from the penultimate hop to the ultimate hop.  At the penultiamte 
hop, everything works.  But before getting to the ultimate hop, the SRH 
is stripped.  Therefore, at the ultimate hop no OAM can take place for 
the path with PSP.
If you define the O bit to over-ride the PSP processing, that in and of 
itself means that the packets on that final leg are different, again 
modifying the intended behavior of OAM.


I will be happy if you can explain how you found a way out of this 
conundrum.


Yours,
Joel

On 3/1/2020 8:57 AM, Zafar Ali (zali) wrote:

Greg, Joel,

_All_ the existing IPv6 OAM tools (e.g., ICMP, traceroute, TWAMP, BFD, 
etc.) works “as-is” for the PSP SID.


They shall exercise the FIB entry for the PSP SIDs, follow the same path 
as PSP SIDs, etc.


We can add clarification in the OAM draft.

Thanks

Regards … Zafar

*From: *spring  on behalf of Greg Mirsky 


*Date: *Sunday, March 1, 2020 at 8:32 AM
*To: *Robert Raszuk 
*Cc: *"6...@ietf.org" <6...@ietf.org>, spring , "Joel 
M. Halpern" , 神明達哉
*Subject: *Re: [spring] Suggest some text //RE: Request to close the LC 
and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming


Hi Robert,

yes, the path probably will be the same regardless whether PSP was 
applied or not. But performance metrics, e.g. packet delay, may be 
different for OAM and "regular" packets.


Regards,

Greg

On Sun, Mar 1, 2020, 14:08 Robert Raszuk <mailto:rob...@raszuk.net>> wrote:


Nope.

Node can advertise two SIDs or PSP in a given network may be a well
know function (to limit IGP burden) Example: odd SID includes PSP
and even SID does not.

O*A*M  packets can use on the exact same path but the penultimate
hop traversal is directed by even SID and is not subject to PSP..

Done.

Thx,
R.

On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern mailto:j...@joelhalpern.com>> wrote:

Presuming that by "OEM" you mean "OAM", then no, this does not work.
If the OAM is intended to monitor a path that has a last SID whose
flavor is PSP, then something will break.  The monitoring will
monitor
something else, or it won't monitor the last hop, or...

Given the point that was made that ignoring a source route (SRH or
otherwise) with segments-left = 0 is a mandatory behavior of
8200, I am
really left puzzled as to what use case justifies the contortion
of PSP.

Yours,
Joel


IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Zafar Ali (zali)]

Greg, Joel,

All the existing IPv6 OAM tools (e.g., ICMP, traceroute, TWAMP, BFD, etc.) 
works “as-is” for the PSP SID.
They shall exercise the FIB entry for the PSP SIDs, follow the same path as PSP 
SIDs, etc.
We can add clarification in the OAM draft.

Thanks

Regards … Zafar

From: spring  on behalf of Greg Mirsky 

Date: Sunday, March 1, 2020 at 8:32 AM
To: Robert Raszuk 
Cc: "6...@ietf.org" <6...@ietf.org>, spring , "Joel M. 
Halpern" , 神明達哉 
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Robert,
yes, the path probably will be the same regardless whether PSP was applied or 
not. But performance metrics, e.g. packet delay, may be different for OAM and 
"regular" packets.

Regards,
Greg

On Sun, Mar 1, 2020, 14:08 Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Nope.

Node can advertise two SIDs or PSP in a given network may be a well know 
function (to limit IGP burden) Example: odd SID includes PSP and even SID does 
not.

O*A*M  packets can use on the exact same path but the penultimate hop traversal 
is directed by even SID and is not subject to PSP..

Done.

Thx,
R.

On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern 
mailto:j...@joelhalpern.com>> wrote:
Presuming that by "OEM" you mean "OAM", then no, this does not work.
If the OAM is intended to monitor a path that has a last SID whose
flavor is PSP, then something will break.  The monitoring will monitor
something else, or it won't monitor the last hop, or...

Given the point that was made that ignoring a source route (SRH or
otherwise) with segments-left = 0 is a mandatory behavior of 8200, I am
really left puzzled as to what use case justifies the contortion of PSP.

Yours,
Joel

IETF IPv6 working group mailing list
i...@ietf.org<mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Greg Mirsky]

Hi Robert,
yes, the path probably will be the same regardless whether PSP was
applied or not. But performance metrics, e.g. packet delay, may be
different for OAM and "regular" packets.

Regards,
Greg

On Sun, Mar 1, 2020, 14:08 Robert Raszuk  wrote:

> Nope.
>
> Node can advertise two SIDs or PSP in a given network may be a well know
> function (to limit IGP burden) Example: odd SID includes PSP and even SID
> does not.
>
> O*A*M  packets can use on the exact same path but the penultimate hop
> traversal is directed by even SID and is not subject to PSP..
>
> Done.
>
> Thx,
> R.
>
> On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern 
> wrote:
>
>> Presuming that by "OEM" you mean "OAM", then no, this does not work.
>> If the OAM is intended to monitor a path that has a last SID whose
>> flavor is PSP, then something will break.  The monitoring will monitor
>> something else, or it won't monitor the last hop, or...
>>
>> Given the point that was made that ignoring a source route (SRH or
>> otherwise) with segments-left = 0 is a mandatory behavior of 8200, I am
>> really left puzzled as to what use case justifies the contortion of PSP.
>>
>> Yours,
>> Joel
>>
>> 
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Joel Halpern Direct]

While the node is "asserting" that the two are the same, if you use 
different SIDs for OAM compared with data traffic then you are not 
actually checking the same forwarding path.  You are not using the same 
FIB entries.  Sure, if everything works right they are the same.  But 
the whole point of OAM is for when not everything is working right.


Yours,
Joel

On 3/1/2020 8:07 AM, Robert Raszuk wrote:

Nope.

Node can advertise two SIDs or PSP in a given network may be a well know 
function (to limit IGP burden) Example: odd SID includes PSP and even 
SID does not.


O*A*M  packets can use on the exact same path but the penultimate hop 
traversal is directed by even SID and is not subject to PSP.


Done.

Thx,
R.

On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern > wrote:


Presuming that by "OEM" you mean "OAM", then no, this does not work.
If the OAM is intended to monitor a path that has a last SID whose
flavor is PSP, then something will break.  The monitoring will monitor
something else, or it won't monitor the last hop, or...

Given the point that was made that ignoring a source route (SRH or
otherwise) with segments-left = 0 is a mandatory behavior of 8200, I am
really left puzzled as to what use case justifies the contortion of PSP.

Yours,
Joel



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

Nope.

Node can advertise two SIDs or PSP in a given network may be a well know
function (to limit IGP burden) Example: odd SID includes PSP and even SID
does not.

O*A*M  packets can use on the exact same path but the penultimate hop
traversal is directed by even SID and is not subject to PSP.

Done.

Thx,
R.

On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern  wrote:

> Presuming that by "OEM" you mean "OAM", then no, this does not work.
> If the OAM is intended to monitor a path that has a last SID whose
> flavor is PSP, then something will break.  The monitoring will monitor
> something else, or it won't monitor the last hop, or...
>
> Given the point that was made that ignoring a source route (SRH or
> otherwise) with segments-left = 0 is a mandatory behavior of 8200, I am
> really left puzzled as to what use case justifies the contortion of PSP.
>
> Yours,
> Joel
>
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Cheers!
Jingrong

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:53 PM
To: Xiejingrong (Jingrong) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

Read your content of SRH header again, I May have a mistake, the routers of 
rtA-rtB-rtC are not listed in longer SRH in your case;

Ok, it is right for your description, I think.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 4:24 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

The packet will look like this when the SRH is deleted:
(SA=VM, DA=subscriber) (payload).

Thanks
Jingrong

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
s

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Wang, Weibin (NSB - CN/Shanghai)]

Hi Jingrong:

Read your content of SRH header again, I May have a mistake, the routers of 
rtA-rtB-rtC are not listed in longer SRH in your case;

Ok, it is right for your description, I think.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
Sent: Sunday, March 1, 2020 4:24 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

The packet will look like this when the SRH is deleted:
(SA=VM, DA=subscriber) (payload).

Thanks
Jingrong

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1)Save bandwidth needed to carrying this SRH through SP network

(2)Not boring subscribers to deal with SRH.

(3)Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Wang, Weibin (NSB - CN/Shanghai)]

Hi Jingrong:

My comments inline;


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
Sent: Sunday, March 1, 2020 4:24 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

WWB: at first, I think, when the packet leave DCGW to continue its journey, 
according to processing rule defined in SRH draft, that is behavior of “SRv6 
transit endpoint”, the leaving packet doesn’t seem like that above, because the 
SL value decrease one by one along Endpoints listed in SRH.

The packet will look like this when the SRH is deleted:
(SA=VM, DA=subscriber) (payload).

WWB: the updated packet shown above will only appear in subscriber (host in 
your case) in your case, I think.

Thanks
Jingrong

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1)Save bandwidth needed to carrying this SRH through SP network

(2)Not boring subscribers to deal with SRH.

(3)Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday,

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Weibin,

I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by 
VM”.

The packet will look like this when the SRH is updated (but not deleted):
(SA=VM, DA=subscriber) (SL=0, subscriber, DCGW, SuperSpine, Spine, TOR) 
(payload).

The packet will look like this when the SRH is deleted:
(SA=VM, DA=subscriber) (payload).

Thanks
Jingrong

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:weibin.w...@nokia-sbell.com]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
mailto:xiejingr...@huawei.com>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encode

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Wang, Weibin (NSB - CN/Shanghai)]

Hi Jingrong:

You may have some misunderstandings of my point of view. It seems that you are 
considering the situation where the source and destination addresses of the 
initial packet from VM belong to the same srv6 domain;
In your example, I don't think DCGW has the right to pop SRH, because it (DCGW) 
is not the last or the penultimate endpoint in the SRH encapsulated by VM. We 
can NOT break basic RH processing rule as defined in SRH draft.


Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) 
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1)Save bandwidth needed to carrying this SRH through SP network

(2)Not boring subscribers to deal with SRH.

(3)Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end 
of src route) - honestly I have not seen such definition in any IETF document 
except in the proposed errata stating that SL==0 to consider destination an 
final destination. /* So if RH is removed before we would never reach final 
destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each 
destination node where DA from packet's header matches the address of one of 
its local interfaces. It is also the ultimate/final destination for specific 
segment as to reach it packet could have traversed many non SR capable nodes. 
As Dirk mentioned SR path can be represented by set of autonomous segments each 
doing complete decasulation and new encapsulation of the packet based on the 
SRH content. If so there is no violation of anything. /* And in this

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=DCGW) (SL=1, subscriber, DCGW, 
SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH when sending 
to the subscriber for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder 
mailto:jgs=40juniper@dmarc.ietf.org>>; 
Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end 
of src route) - honestly I have not seen such definition in any IETF document 
except in the proposed errata stating that SL==0 to consider destination an 
final destination. /* So if RH is removed before we would never reach final 
destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each 
destination node where DA from packet's header matches the address of one of 
its local interfaces. It is also the ultimate/final destination for specific 
segment as to reach it packet could have traversed many non SR capable nodes. 
As Dirk mentioned SR path can be represented by set of autonomous segments each 
doing complete decasulation and new encapsulation of the packet based on the 
SRH content. If so there is no violation of anything. /* And in this mode at 
least SR nodes could be PLRs for TI-LFA without the need for yet one more 
encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder 
mailto:j...@juniper.net>> wrote:
I see. So you are simply demonstrating that even the tightened language you 
quoted is subject to the same difference of interpretation that’s at the root 
of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a 
source-routed packet cannot be said to have reached its ultimate destination 
until it has reached the target of the source route, the point at which the 
source route has been fully consumed. I think (?) you'll agree that isn't the 
interpretation you've chosen, you’ve chosen t

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi Weibin,

Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be 
useful for host-to-host IPv6 packet as well.

Suppose:
[VM—TOR—Spine—SuperSpine—DCGW][rtArtBrtC]subscribers

The VM,TOR,Spine,SuperSpine,DCGW are all belonging to a DC operator.

The rtA, rtB, rtC are all belonging to a SP operator, and the subscribers are 
hosts that connected to internet through the SP.

The VM can send out an IPv6 packet using SRH to select a path (among 100 paths) 
through TOR—Spine—SuperSpine—DCGW.
The IPv6 packet is like this when reaching TOR: (SA=VM, DA=TOR) (SL=4, 
subscriber, DCGW, SuperSpine, Spine, TOR) (payload).
And is like this when reaching DCGW: (SA=VM, DA=subscriber) (SL=1, subscriber, 
DCGW, SuperSpine, Spine, TOR) (payload).

As a DC operator, the DCGW can be designed to delete/POP the SRH for 3 benefits:

(1) Save bandwidth needed to carrying this SRH through SP network

(2) Not boring subscribers to deal with SRH.

(3) Not letting subscribers to know unwanted path information.

From this point of view, I even think it is harmful to ban EH deletion  for 
IPv6’s development, deployment, innovation, openness, flexibility… you name it.

Thanks
Jingrong

From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Wang, Weibin (NSB - 
CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder ; Robert Raszuk 

Cc: spring@ietf.org; 6...@ietf.org; 神明達哉 
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6 mailto:ipv6-boun...@ietf.org>> On Behalf Of 
John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉 
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end 
of src route) - honestly I have not seen such definition in any IETF document 
except in the proposed errata stating that SL==0 to consider destination an 
final destination. /* So if RH is removed before we would never reach final 
destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each 
destination node where DA from packet's header matches the address of one of 
its local interfaces. It is also the ultimate/final destination for specific 
segment as to reach it packet could have traversed many non SR capable nodes. 
As Dirk mentioned SR path can be represented by set of autonomous segments each 
doing complete decasulation and new encapsulation of the packet based on the 
SRH content. If so there is no violation of anything. /* And in this mode at 
least SR nodes could be PLRs for TI-LFA without the need for yet one more 
encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder 
mailto:j...@juniper.net>> wrote:
I see. So you are simply demonstrating that even the tightened language you 
quoted is subject to the same difference of interpretation that’s at the root 
of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a 
source-routed packet cannot be said to have reached its ultimate destination 
until it has reached the target of the source route, the point at which the 
source route has been fully consumed. I think (?) you'll agree that isn't the 
interpretation you've chosen, you’ve chosen to interpret “ultimate destination” 
as meaning “the destination depicted in the outer IPv6 header," regardless of 
where the packet is along the source route. Right? So, status quo ante. (I 
think

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Joel M. Halpern]

Presuming that by "OEM" you mean "OAM", then no, this does not work.
If the OAM is intended to monitor a path that has a last SID whose 
flavor is PSP, then something will break.  The monitoring will monitor 
something else, or it won't monitor the last hop, or...


Given the point that was made that ignoring a source route (SRH or 
otherwise) with segments-left = 0 is a mandatory behavior of 8200, I am 
really left puzzled as to what use case justifies the contortion of PSP.


Yours,
Joel

On 2/29/2020 3:36 PM, Robert Raszuk wrote:

Greg,

You are thinking of PSP like MPLS PHP to apply to all packets towards 
the guy who advertised implicit-null label.


That is not the case here at all.

You apply PSP when you like on a per segment endpoint basis. OEM as we 
have all agreed will not be subject to PSP.. Is there a value to keep 
repeating that every day :) ?


Cheers,
R.



On Sat, Feb 29, 2020 at 8:57 PM Greg Mirsky > wrote:


Hi Brian,
you've said

  Also, answering
your question "what harm does it do?" I think the answer
objectively is "none, unless
you want to use AH". 


On the other thread Ron and I have pointed that PSP does have
decremental effect on the ability to perform OAM, particularly
performance monitoring, and the use of the O-bit proposed in
draft-ietf-6man-spring-srv6-oam
is
questionable. Though these may not be veied as harmful
consequences of PSP but they clearly, in my opinion, are benefitial
either.

Regards,
Greg

On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>>
wrote:

On 01-Mar-20 07:25, Robert Raszuk wrote:
 > Hi John,
 >
 > I respectfully will disagree with your assessment.
 >
 > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This
is base of SRv6 operation. If this would be deprecated, moved to
historic or made illegal - games over. But if this is still
legal then ultimate destination for a packet is what it listed
in outer IPv6 header DA. That's pretty basic. Now what the
destination in the header will do with the packet is completely
different story.
 >
 > Reason #2 - "a node can’t be both the penultimate, and the
ultimate, node." Of course it can. You are looking flat ..

But I've been told by several people that this is not the use
case. I believe
the little diagram I sent yesterday is the use case. And the
trick in the description
of PSP is what I pointed out yesterday too: deleting the header
when segments-left == 0
but the destination address is not yet set to the final one:


https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/

The thing is, it can be coded and I fully believe there is
running code. Also, answering
your question "what harm does it do?" I think the answer
objectively is "none, unless
you want to use AH". Making a packet smaller on the last hop
cannot break PMTUD.

So I think the text needs to admit the trick it's playing on RFC
8200. Then the IETF
can choose whether to let that trick pass.

    Brian


 > If you look at different layers the same node is in fact
acting in multiple roles - I can easily count 3 but with TI-LFA
it could be  even more.
 >
 > The same node is ultimate destination for the outer header
 > in the same time
 > The same node is penultimate destination for SR path
 > in the same time
 > The same node is just regular IPv6 transit from the
perspective of the original non encapsulated packet
 >
 > Kind regards,
 > R.
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 > On Sat, Feb 29, 2020 at 6:46 PM John Scudder mailto:j...@juniper.net> >> wrote:
 >
 >     Robert,
 >
 >     I think your comment (emphasis added):
 >
 >>     we are dealing here with an *encapsulated* packet which
_has as its ultimate destination_ SR node X. That SR node X is
to perform or not PSP.
 >
 >     Is wrong. It contradicts everything else that’s been said
in the hundreds of messages that have gone before, not to
mention the plain language
of draft-ietf-spring-srv6-network-programming-10. The word
“penultimate” itself is enough to prove this: by definition a
node can’t be both the penultimate, and the ultimate, node. It’s
a contradiction in terms, like saying 0 equals 1.
 >
 >     

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Wang, Weibin (NSB - CN/Shanghai)]

From the destination address of the initial IPv6 data packet viewpoint, all 
endpoints (segments) in SRH associated the outer IPv6 header are intermediate 
nodes to be visited, including endpoint identified by SL=0. so it is 
meaningless to entangle in the outer packet SRH which segment belongs to the 
ultimate destination address of the outer IPv6 packet; I think the roles of all 
segments in the SRH are the same which are used to perform part of total 
network programmable functions within SRv6 domain, their positions are the 
same, so there is nothing wrong for PSP in some ways, It is not necessary for 
segment identified by SL=0 to POP SRH.



Cheers!

Wang Weibin

From: ipv6  On Behalf Of John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk 
Cc: spring@ietf.org; 6...@ietf.org; 神明達哉 
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John


On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end 
of src route) - honestly I have not seen such definition in any IETF document 
except in the proposed errata stating that SL==0 to consider destination an 
final destination. /* So if RH is removed before we would never reach final 
destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each 
destination node where DA from packet's header matches the address of one of 
its local interfaces. It is also the ultimate/final destination for specific 
segment as to reach it packet could have traversed many non SR capable nodes. 
As Dirk mentioned SR path can be represented by set of autonomous segments each 
doing complete decasulation and new encapsulation of the packet based on the 
SRH content. If so there is no violation of anything. /* And in this mode at 
least SR nodes could be PLRs for TI-LFA without the need for yet one more 
encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder 
mailto:j...@juniper.net>> wrote:
I see. So you are simply demonstrating that even the tightened language you 
quoted is subject to the same difference of interpretation that’s at the root 
of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a 
source-routed packet cannot be said to have reached its ultimate destination 
until it has reached the target of the source route, the point at which the 
source route has been fully consumed. I think (?) you'll agree that isn't the 
interpretation you've chosen, you’ve chosen to interpret “ultimate destination” 
as meaning “the destination depicted in the outer IPv6 header," regardless of 
where the packet is along the source route. Right? So, status quo ante. (I 
think I could defend my reading as being objectively correct based on nothing 
more than the words as written, but that’s beside the point — once we get to 
the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural 
language can often be interpreted differently by different readers (especially 
those motivated to reach different interpretations) and leave it at that, 
resolving such differences when they arise through IETF process; or work to 
craft ever more precise language, accepting the consequence that we have to do 
extra work and our specs become more unwieldy as a result. In this particular 
case, I guess an excruciatingly precise definition of “ultimate destination” 
may be the key to resolving ambiguity.

—John


On Feb 29, 2020, at 1:25 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
operation. If this would be deprecated, moved to historic or made illegal - 
games over. But if this is still legal then ultimate destination for a packet 
is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of 
course it can. You are looking flat .. If you look at different layers the same 
node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA 
it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Zafar Ali (zali)]

Hi Greg,

O-bit is only used for telemetering a copy of sampled packets to a controller.
This is an advance use-case for a controller based in-band OAM (OAM on data 
packets).

Support for O-bit is optional.
As per PSP use-cases discussions and agreement on the mailer, a node 
advertising PSP capability is not expected to support O-bit.
If a node supports O-bit it is also expected to support Ultimate Segment Pop 
(USP) SID.

This is explained in the context of OAM draft (Github: 
https://github.com/ietf-6man/srv6-oam/blob/master/draft-ietf-6man-spring-srv6-oam.txt):
“If data from the last node in the segment-list (Egress node) is desired, the 
ingress uses an Ultimate Segment Pop (USP) SID advertised by the Egress node.“

Thanks

Regards … Zafar

From: ipv6  on behalf of Greg Mirsky 

Date: Saturday, February 29, 2020 at 3:47 PM
To: Robert Raszuk 
Cc: "spring@ietf.org" , "6...@ietf.org" <6...@ietf.org>, 神明達哉 

Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Robert,
s/OEM/OAM/ ;)
True, active OAM should not generate excessive number of test packets and that 
might make selective non-use of PSP on these packets acceptable. But some have 
made a use case for PSP by describing environment where the ultimate tunnel 
endpoint is not capable to process SRH. If that is the practical case, then how 
SRv6 OAM will work at all?

Regards,
Greg

On Sat, Feb 29, 2020 at 12:36 PM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
Greg,

You are thinking of PSP like MPLS PHP to apply to all packets towards the guy 
who advertised implicit-null label.

That is not the case here at all.

You apply PSP when you like on a per segment endpoint basis. OEM as we have all 
agreed will not be subject to PSP. Is there a value to keep repeating that 
every day :) ?

Cheers,
R.



On Sat, Feb 29, 2020 at 8:57 PM Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:
Hi Brian,
you've said
 Also, answering
your question "what harm does it do?" I think the answer objectively is "none, 
unless
you want to use AH".
On the other thread Ron and I have pointed that PSP does have decremental 
effect on the ability to perform OAM, particularly performance monitoring, and 
the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam 
<https://tools.ietf.org/html/draft-ietf-6man-spring-srv6-oam-03> is 
questionable. Though these may not be veied as harmful consequences of PSP but 
they clearly, in my opinion, are benefitial either.

Regards,
Greg

On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>> wrote:
On 01-Mar-20 07:25, Robert Raszuk wrote:
> Hi John,
>
> I respectfully will disagree with your assessment.
>
> Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
> operation. If this would be deprecated, moved to historic or made illegal - 
> games over. But if this is still legal then ultimate destination for a packet 
> is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
> destination in the header will do with the packet is completely different 
> story.
>
> Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." 
> Of course it can. You are looking flat ..

But I've been told by several people that this is not the use case. I believe
the little diagram I sent yesterday is the use case. And the trick in the 
description
of PSP is what I pointed out yesterday too: deleting the header when 
segments-left == 0
but the destination address is not yet set to the final one:

https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/

The thing is, it can be coded and I fully believe there is running code. Also, 
answering
your question "what harm does it do?" I think the answer objectively is "none, 
unless
you want to use AH". Making a packet smaller on the last hop cannot break PMTUD.

So I think the text needs to admit the trick it's playing on RFC 8200. Then the 
IETF
can choose whether to let that trick pass.

   Brian


> If you look at different layers the same node is in fact acting in multiple 
> roles - I can easily count 3 but with TI-LFA it could be  even more.
>
> The same node is ultimate destination for the outer header
> in the same time
> The same node is penultimate destination for SR path
> in the same time
> The same node is just regular IPv6 transit from the perspective of the 
> original non encapsulated packet
>
> Kind regards,
> R.
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 29, 2020 at 6:46 PM John Scudder 
> mailto:j...@juniper.net> 
> <mailto:j...@juniper.net<mailto:j...@juniper.net>>> wrote:
>
> Robert,
>
> I think your comment (emphasis added):
>
>>

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[John Scudder]

Yes, this is essentially what my second paragraph said. So we agree as to what 
our point of disagreement is :-) and I think we can leave it there until there 
is something new to discuss.

—John

On Feb 29, 2020, at 3:55 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

John,

So for some packet's final destination is the one located in the most inner 
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or end 
of src route) - honestly I have not seen such definition in any IETF document 
except in the proposed errata stating that SL==0 to consider destination an 
final destination. /* So if RH is removed before we would never reach final 
destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each 
destination node where DA from packet's header matches the address of one of 
its local interfaces. It is also the ultimate/final destination for specific 
segment as to reach it packet could have traversed many non SR capable nodes. 
As Dirk mentioned SR path can be represented by set of autonomous segments each 
doing complete decasulation and new encapsulation of the packet based on the 
SRH content. If so there is no violation of anything. /* And in this mode at 
least SR nodes could be PLRs for TI-LFA without the need for yet one more 
encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder 
mailto:j...@juniper.net>> wrote:
I see. So you are simply demonstrating that even the tightened language you 
quoted is subject to the same difference of interpretation that’s at the root 
of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a 
source-routed packet cannot be said to have reached its ultimate destination 
until it has reached the target of the source route, the point at which the 
source route has been fully consumed. I think (?) you'll agree that isn't the 
interpretation you've chosen, you’ve chosen to interpret “ultimate destination” 
as meaning “the destination depicted in the outer IPv6 header," regardless of 
where the packet is along the source route. Right? So, status quo ante. (I 
think I could defend my reading as being objectively correct based on nothing 
more than the words as written, but that’s beside the point — once we get to 
the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural 
language can often be interpreted differently by different readers (especially 
those motivated to reach different interpretations) and leave it at that, 
resolving such differences when they arise through IETF process; or work to 
craft ever more precise language, accepting the consequence that we have to do 
extra work and our specs become more unwieldy as a result. In this particular 
case, I guess an excruciatingly precise definition of “ultimate destination” 
may be the key to resolving ambiguity.

—John

On Feb 29, 2020, at 1:25 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
operation. If this would be deprecated, moved to historic or made illegal - 
games over. But if this is still legal then ultimate destination for a packet 
is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of 
course it can. You are looking flat .. If you look at different layers the same 
node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA 
it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original 
non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate 
destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of 
messages that have gone before, not to mention the plain language of 
draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is 
enough to prove this: by definition a node can’t be both the penultimate, and 
the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would 
be a different story, but the whole point of PSP is that X removes the RH and 
then sends the encapsulated packet on to Y which performs 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

John,

So for some packet's final destination is the one located in the most inner
header of the packet. The one applied by the sender's socket.

For you apparently the final destination is the one encoded in the SRH (or
end of src route) - honestly I have not seen such definition in any IETF
document except in the proposed errata stating that SL==0 to consider
destination an final destination. /* So if RH is removed before we would
never reach final destination per current errata */

My reading of RFC8200 leads me to believe that final destination is each
destination node where DA from packet's header matches the address of one
of its local interfaces. It is also the ultimate/final destination for
specific segment as to reach it packet could have traversed many non SR
capable nodes. As Dirk mentioned SR path can be represented by set of
autonomous segments each doing complete decasulation and new
encapsulation of the packet based on the SRH content. If so there is no
violation of anything. /* And in this mode at least SR nodes could be PLRs
for TI-LFA without the need for yet one more encapsulation */.

Robert.

On Sat, Feb 29, 2020 at 8:23 PM John Scudder  wrote:

> I see. So you are simply demonstrating that even the tightened language
> you quoted is subject to the same difference of interpretation that’s at
> the root of the controversy. That’s helpful to know.
>
> Clearly (at least this is clear to me) the intent of that sentence is that
> a source-routed packet cannot be said to have reached its ultimate
> destination until it has reached the target of the source route, the point
> at which the source route has been fully consumed. I think (?) you'll agree
> that isn't the interpretation you've chosen, you’ve chosen to interpret
> “ultimate destination” as meaning “the destination depicted in the outer
> IPv6 header," regardless of where the packet is along the source route.
> Right? So, status quo ante. (I think I could defend my reading as being
> objectively correct based on nothing more than the words as written, but
> that’s beside the point — once we get to the stage of spec-lawyering, we
> have all lost.)
>
> I suppose the choice here remains as it always has been: accept that
> natural language can often be interpreted differently by different readers
> (especially those motivated to reach different interpretations) and leave
> it at that, resolving such differences when they arise through IETF
> process; or work to craft ever more precise language, accepting the
> consequence that we have to do extra work and our specs become more
> unwieldy as a result. In this particular case, I guess an excruciatingly
> precise definition of “ultimate destination” may be the key to resolving
> ambiguity.
>
> —John
>
> On Feb 29, 2020, at 1:25 PM, Robert Raszuk  wrote:
>
> Hi John,
>
> I respectfully will disagree with your assessment.
>
> Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of
> SRv6 operation. If this would be deprecated, moved to historic or made
> illegal - games over. But if this is still legal then ultimate destination
> for a packet is what it listed in outer IPv6 header DA. That's pretty
> basic. Now what the destination in the header will do with the packet is
> completely different story.
>
> Reason #2 - "a node can’t be both the penultimate, and the ultimate,
> node." Of course it can. You are looking flat .. If you look at different
> layers the same node is in fact acting in multiple roles - I can easily
> count 3 but with TI-LFA it could be  even more.
>
> The same node is ultimate destination for the outer header
> in the same time
> The same node is penultimate destination for SR path
> in the same time
> The same node is just regular IPv6 transit from the perspective of the
> original non encapsulated packet
>
> Kind regards,
> R.
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 29, 2020 at 6:46 PM John Scudder  wrote:
>
>> Robert,
>>
>> I think your comment (emphasis added):
>>
>> we are dealing here with an *encapsulated* packet which *has as its
>> ultimate destination* SR node X. That SR node X is to perform or not PSP..
>>
>>
>> Is wrong. It contradicts everything else that’s been said in the hundreds
>> of messages that have gone before, not to mention the plain language
>> of draft-ietf-spring-srv6-network-programming-10. The word “penultimate”
>> itself is enough to prove this: by definition a node can’t be both the
>> penultimate, and the ultimate, node. It’s a contradiction in terms, like
>> saying 0 equals 1.
>>
>> Now, if node X were to remove the RH *and perform the decapsulation*
>> that would be a different story, but the whole point of PSP is that X
>> removes the RH and then sends the encapsulated packet on to Y which
>> performs the decapsulation. (This point was made in one of the other
>> threads recently, but I’ve lost track of by whom and which thread.) As far
>> as I can tell, this non-controversial behavior is described in 4.16.3 of
>> the draft 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Greg Mirsky]

Hi Robert,
s/OEM/OAM/ ;)
True, active OAM should not generate excessive number of test packets and
that might make selective non-use of PSP on these packets acceptable. But
some have made a use case for PSP by describing environment where the
ultimate tunnel endpoint is not capable to process SRH. If that is the
practical case, then how SRv6 OAM will work at all?

Regards,
Greg

On Sat, Feb 29, 2020 at 12:36 PM Robert Raszuk  wrote:

> Greg,
>
> You are thinking of PSP like MPLS PHP to apply to all packets towards the
> guy who advertised implicit-null label.
>
> That is not the case here at all.
>
> You apply PSP when you like on a per segment endpoint basis. OEM as we
> have all agreed will not be subject to PSP. Is there a value to keep
> repeating that every day :) ?
>
> Cheers,
> R.
>
>
>
> On Sat, Feb 29, 2020 at 8:57 PM Greg Mirsky  wrote:
>
>> Hi Brian,
>> you've said
>>
>>  Also, answering
>> your question "what harm does it do?" I think the answer objectively is
>> "none, unless
>> you want to use AH".
>>
>> On the other thread Ron and I have pointed that PSP does have decremental
>> effect on the ability to perform OAM, particularly performance monitoring,
>> and the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam
>> is
>> questionable. Though these may not be veied as harmful consequences of PSP
>> but they clearly, in my opinion, are benefitial either.
>>
>> Regards,
>> Greg
>>
>> On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter <
>> brian.e.carpen...@gmail.com> wrote:
>>
>>> On 01-Mar-20 07:25, Robert Raszuk wrote:
>>> > Hi John,
>>> >
>>> > I respectfully will disagree with your assessment.
>>> >
>>> > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base
>>> of SRv6 operation. If this would be deprecated, moved to historic or made
>>> illegal - games over. But if this is still legal then ultimate destination
>>> for a packet is what it listed in outer IPv6 header DA. That's pretty
>>> basic. Now what the destination in the header will do with the packet is
>>> completely different story.
>>> >
>>> > Reason #2 - "a node can’t be both the penultimate, and the ultimate,
>>> node." Of course it can. You are looking flat ..
>>>
>>> But I've been told by several people that this is not the use case. I
>>> believe
>>> the little diagram I sent yesterday is the use case. And the trick in
>>> the description
>>> of PSP is what I pointed out yesterday too: deleting the header when
>>> segments-left == 0
>>> but the destination address is not yet set to the final one:
>>>
>>> https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/
>>>
>>> The thing is, it can be coded and I fully believe there is running code..
>>> Also, answering
>>> your question "what harm does it do?" I think the answer objectively is
>>> "none, unless
>>> you want to use AH". Making a packet smaller on the last hop cannot
>>> break PMTUD.
>>>
>>> So I think the text needs to admit the trick it's playing on RFC 8200.
>>> Then the IETF
>>> can choose whether to let that trick pass.
>>>
>>>Brian
>>>
>>>
>>> > If you look at different layers the same node is in fact acting in
>>> multiple roles - I can easily count 3 but with TI-LFA it could be  even
>>> more.
>>> >
>>> > The same node is ultimate destination for the outer header
>>> > in the same time
>>> > The same node is penultimate destination for SR path
>>> > in the same time
>>> > The same node is just regular IPv6 transit from the perspective of the
>>> original non encapsulated packet
>>> >
>>> > Kind regards,
>>> > R.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Feb 29, 2020 at 6:46 PM John Scudder >> j...@juniper.net>> wrote:
>>> >
>>> > Robert,
>>> >
>>> > I think your comment (emphasis added):
>>> >
>>> >> we are dealing here with an *encapsulated* packet which _has as
>>> its ultimate destination_ SR node X. That SR node X is to perform or not
>>> PSP.
>>> >
>>> > Is wrong. It contradicts everything else that’s been said in the
>>> hundreds of messages that have gone before, not to mention the plain
>>> language of draft-ietf-spring-srv6-network-programming-10. The word
>>> “penultimate” itself is enough to prove this: by definition a node can’t be
>>> both the penultimate, and the ultimate, node. It’s a contradiction in
>>> terms, like saying 0 equals 1.
>>> >
>>> > Now, if node X were to remove the RH /and perform the
>>> decapsulation/ that would be a different story, but the whole point of PSP
>>> is that X removes the RH and then sends the encapsulated packet on to Y
>>> which performs the decapsulation. (This point was made in one of the other
>>> threads recently, but I’ve lost track of by whom and which thread.) As far
>>> as I can tell, this non-controversial behavior is described in 4.16.3 of
>>> the draft and referred to as “USD”.
>>> >
>>> > —John
>>> >
>>> >> On Feb 29, 2020, at 6:06 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

Greg,

You are thinking of PSP like MPLS PHP to apply to all packets towards the
guy who advertised implicit-null label.

That is not the case here at all.

You apply PSP when you like on a per segment endpoint basis. OEM as we have
all agreed will not be subject to PSP. Is there a value to keep repeating
that every day :) ?

Cheers,
R.



On Sat, Feb 29, 2020 at 8:57 PM Greg Mirsky  wrote:

> Hi Brian,
> you've said
>
>  Also, answering
> your question "what harm does it do?" I think the answer objectively is
> "none, unless
> you want to use AH".
>
> On the other thread Ron and I have pointed that PSP does have decremental
> effect on the ability to perform OAM, particularly performance monitoring,
> and the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam
> is
> questionable. Though these may not be veied as harmful consequences of PSP
> but they clearly, in my opinion, are benefitial either.
>
> Regards,
> Greg
>
> On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> On 01-Mar-20 07:25, Robert Raszuk wrote:
>> > Hi John,
>> >
>> > I respectfully will disagree with your assessment.
>> >
>> > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of
>> SRv6 operation. If this would be deprecated, moved to historic or made
>> illegal - games over. But if this is still legal then ultimate destination
>> for a packet is what it listed in outer IPv6 header DA. That's pretty
>> basic. Now what the destination in the header will do with the packet is
>> completely different story.
>> >
>> > Reason #2 - "a node can’t be both the penultimate, and the ultimate,
>> node." Of course it can. You are looking flat ..
>>
>> But I've been told by several people that this is not the use case. I
>> believe
>> the little diagram I sent yesterday is the use case. And the trick in the
>> description
>> of PSP is what I pointed out yesterday too: deleting the header when
>> segments-left == 0
>> but the destination address is not yet set to the final one:
>>
>> https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/
>>
>> The thing is, it can be coded and I fully believe there is running code.
>> Also, answering
>> your question "what harm does it do?" I think the answer objectively is
>> "none, unless
>> you want to use AH". Making a packet smaller on the last hop cannot break
>> PMTUD.
>>
>> So I think the text needs to admit the trick it's playing on RFC 8200.
>> Then the IETF
>> can choose whether to let that trick pass.
>>
>>Brian
>>
>>
>> > If you look at different layers the same node is in fact acting in
>> multiple roles - I can easily count 3 but with TI-LFA it could be  even
>> more.
>> >
>> > The same node is ultimate destination for the outer header
>> > in the same time
>> > The same node is penultimate destination for SR path
>> > in the same time
>> > The same node is just regular IPv6 transit from the perspective of the
>> original non encapsulated packet
>> >
>> > Kind regards,
>> > R.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Feb 29, 2020 at 6:46 PM John Scudder > j...@juniper.net>> wrote:
>> >
>> > Robert,
>> >
>> > I think your comment (emphasis added):
>> >
>> >> we are dealing here with an *encapsulated* packet which _has as
>> its ultimate destination_ SR node X. That SR node X is to perform or not
>> PSP.
>> >
>> > Is wrong. It contradicts everything else that’s been said in the
>> hundreds of messages that have gone before, not to mention the plain
>> language of draft-ietf-spring-srv6-network-programming-10. The word
>> “penultimate” itself is enough to prove this: by definition a node can’t be
>> both the penultimate, and the ultimate, node. It’s a contradiction in
>> terms, like saying 0 equals 1.
>> >
>> > Now, if node X were to remove the RH /and perform the
>> decapsulation/ that would be a different story, but the whole point of PSP
>> is that X removes the RH and then sends the encapsulated packet on to Y
>> which performs the decapsulation. (This point was made in one of the other
>> threads recently, but I’ve lost track of by whom and which thread.) As far
>> as I can tell, this non-controversial behavior is described in 4.16.3 of
>> the draft and referred to as “USD”.
>> >
>> > —John
>> >
>> >> On Feb 29, 2020, at 6:06 AM, Robert Raszuk > > wrote:
>> >>
>> >> Dear Jinmei,
>> >>
>> >> Even if RFC8200 section 4 text would say:
>> >>
>> >>  "Extension headers cannot be added to a packet after it has left
>> its source node and extension headers cannot be removed from a packet until
>> it has arrived at its ultimate destination".
>> >>
>> >> PSP would be still not be violating anything said in this
>> sentence. Reason being is that we are dealing here with an *encapsulated*
>> packet which has as its ultimate destination SR node X. That SR node X is

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Greg Mirsky]

Hi Brian,
you've said

 Also, answering
your question "what harm does it do?" I think the answer objectively is
"none, unless
you want to use AH".

On the other thread Ron and I have pointed that PSP does have decremental
effect on the ability to perform OAM, particularly performance monitoring,
and the use of the O-bit proposed in draft-ietf-6man-spring-srv6-oam
is
questionable. Though these may not be veied as harmful consequences of PSP
but they clearly, in my opinion, are benefitial either.

Regards,
Greg

On Sat, Feb 29, 2020 at 11:25 AM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 01-Mar-20 07:25, Robert Raszuk wrote:
> > Hi John,
> >
> > I respectfully will disagree with your assessment.
> >
> > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of
> SRv6 operation. If this would be deprecated, moved to historic or made
> illegal - games over. But if this is still legal then ultimate destination
> for a packet is what it listed in outer IPv6 header DA. That's pretty
> basic. Now what the destination in the header will do with the packet is
> completely different story.
> >
> > Reason #2 - "a node can’t be both the penultimate, and the ultimate,
> node." Of course it can. You are looking flat ..
>
> But I've been told by several people that this is not the use case. I
> believe
> the little diagram I sent yesterday is the use case. And the trick in the
> description
> of PSP is what I pointed out yesterday too: deleting the header when
> segments-left == 0
> but the destination address is not yet set to the final one:
>
> https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/
>
> The thing is, it can be coded and I fully believe there is running code.
> Also, answering
> your question "what harm does it do?" I think the answer objectively is
> "none, unless
> you want to use AH". Making a packet smaller on the last hop cannot break
> PMTUD.
>
> So I think the text needs to admit the trick it's playing on RFC 8200.
> Then the IETF
> can choose whether to let that trick pass.
>
>Brian
>
>
> > If you look at different layers the same node is in fact acting in
> multiple roles - I can easily count 3 but with TI-LFA it could be  even
> more.
> >
> > The same node is ultimate destination for the outer header
> > in the same time
> > The same node is penultimate destination for SR path
> > in the same time
> > The same node is just regular IPv6 transit from the perspective of the
> original non encapsulated packet
> >
> > Kind regards,
> > R.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Feb 29, 2020 at 6:46 PM John Scudder  j...@juniper.net>> wrote:
> >
> > Robert,
> >
> > I think your comment (emphasis added):
> >
> >> we are dealing here with an *encapsulated* packet which _has as its
> ultimate destination_ SR node X. That SR node X is to perform or not PSP.
> >
> > Is wrong. It contradicts everything else that’s been said in the
> hundreds of messages that have gone before, not to mention the plain
> language of draft-ietf-spring-srv6-network-programming-10. The word
> “penultimate” itself is enough to prove this: by definition a node can’t be
> both the penultimate, and the ultimate, node. It’s a contradiction in
> terms, like saying 0 equals 1.
> >
> > Now, if node X were to remove the RH /and perform the decapsulation/
> that would be a different story, but the whole point of PSP is that X
> removes the RH and then sends the encapsulated packet on to Y which
> performs the decapsulation. (This point was made in one of the other
> threads recently, but I’ve lost track of by whom and which thread..) As far
> as I can tell, this non-controversial behavior is described in 4.16.3 of
> the draft and referred to as “USD”.
> >
> > —John
> >
> >> On Feb 29, 2020, at 6:06 AM, Robert Raszuk  > wrote:
> >>
> >> Dear Jinmei,
> >>
> >> Even if RFC8200 section 4 text would say:
> >>
> >>  "Extension headers cannot be added to a packet after it has left
> its source node and extension headers cannot be removed from a packet until
> it has arrived at its ultimate destination".
> >>
> >> PSP would be still not be violating anything said in this sentence..
> Reason being is that we are dealing here with an *encapsulated* packet
> which has as its ultimate destination SR node X. That SR node X is to
> perform or not PSP. So it is still fully compliant with the specification..
> >>
> >> IMHO the only grey area as pointed by Brian is if RFC8200 section
> 4.4 really mandates you to look at segments_left before processing the
> packet or it is equally legal to look at that value after local processing
> occurs. Definition says:
> >>
> >>
> >>   Segments Left   8-bit unsigned integer.  Number of route
> >>   segments remaining, i.e., number of
> explicitly
> >>  

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[John Scudder]

Thanks, Brian.

On Feb 29, 2020, at 2:25 PM, Brian E Carpenter 
mailto:brian.e.carpen...@gmail.com>> wrote:

So I think the text needs to admit the trick it's playing on RFC 8200. Then the 
IETF
can choose whether to let that trick pass.

I agree. (I’ve said as much before, as have others.)

—John
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Brian E Carpenter]

On 01-Mar-20 07:25, Robert Raszuk wrote:
> Hi John,
> 
> I respectfully will disagree with your assessment. 
> 
> Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
> operation. If this would be deprecated, moved to historic or made illegal - 
> games over. But if this is still legal then ultimate destination for a packet 
> is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
> destination in the header will do with the packet is completely different 
> story. 
> 
> Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." 
> Of course it can. You are looking flat .. 

But I've been told by several people that this is not the use case. I believe
the little diagram I sent yesterday is the use case. And the trick in the 
description
of PSP is what I pointed out yesterday too: deleting the header when 
segments-left == 0
but the destination address is not yet set to the final one:

https://mailarchive.ietf.org/arch/msg/spring/n46VuroVGvRurIgGNLZxFbAHvIo/

The thing is, it can be coded and I fully believe there is running code. Also, 
answering
your question "what harm does it do?" I think the answer objectively is "none, 
unless
you want to use AH". Making a packet smaller on the last hop cannot break PMTUD.

So I think the text needs to admit the trick it's playing on RFC 8200. Then the 
IETF
can choose whether to let that trick pass.

   Brian


> If you look at different layers the same node is in fact acting in multiple 
> roles - I can easily count 3 but with TI-LFA it could be  even more. 
> 
> The same node is ultimate destination for the outer header 
> in the same time 
> The same node is penultimate destination for SR path
> in the same time 
> The same node is just regular IPv6 transit from the perspective of the 
> original non encapsulated packet 
> 
> Kind regards,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Feb 29, 2020 at 6:46 PM John Scudder  > wrote:
> 
> Robert,
> 
> I think your comment (emphasis added):
> 
>> we are dealing here with an *encapsulated* packet which _has as its 
>> ultimate destination_ SR node X. That SR node X is to perform or not PSP.
> 
> Is wrong. It contradicts everything else that’s been said in the hundreds 
> of messages that have gone before, not to mention the plain language of 
> draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself 
> is enough to prove this: by definition a node can’t be both the penultimate, 
> and the ultimate, node. It’s a contradiction in terms, like saying 0 equals 
> 1. 
> 
> Now, if node X were to remove the RH /and perform the decapsulation/ that 
> would be a different story, but the whole point of PSP is that X removes the 
> RH and then sends the encapsulated packet on to Y which performs the 
> decapsulation. (This point was made in one of the other threads recently, but 
> I’ve lost track of by whom and which thread.) As far as I can tell, this 
> non-controversial behavior is described in 4.16.3 of the draft and referred 
> to as “USD”.
> 
> —John
> 
>> On Feb 29, 2020, at 6:06 AM, Robert Raszuk > > wrote:
>>
>> Dear Jinmei,
>>
>> Even if RFC8200 section 4 text would say: 
>>
>>  "Extension headers cannot be added to a packet after it has left its 
>> source node and extension headers cannot be removed from a packet until it 
>> has arrived at its ultimate destination".
>>
>> PSP would be still not be violating anything said in this sentence. 
>> Reason being is that we are dealing here with an *encapsulated* packet which 
>> has as its ultimate destination SR node X. That SR node X is to perform or 
>> not PSP. So it is still fully compliant with the specification. 
>>
>> IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 
>> really mandates you to look at segments_left before processing the packet or 
>> it is equally legal to look at that value after local processing occurs. 
>> Definition says: 
>>
>>
>>   Segments Left   8-bit unsigned integer.  Number of route
>>   segments remaining, i.e., number of explicitly
>>   listed intermediate nodes still to be visited
>>   before reaching the final destination.
>>
>> which to me really means that as long as you recognize given routing 
>> header type you can decrement this value and if zero remove it. 
>>
>> Besides that is a minor detail - as NPG draft could be updated to say: 
>>
>>  S14.1.   If (Segments Left Before Local Decrement == 1) {
>>  S14.2.  Update the Next Header field in the preceding header to the
>> Next Header value of the SRH
>>  S14.3.  Decrease the IPv6 header Payload Length by the Hdr Ext Len
>> value of the SRH
>>  S14.4.  Remove the SRH from the IPv6 extension header chain
>>

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[John Scudder]

I see. So you are simply demonstrating that even the tightened language you 
quoted is subject to the same difference of interpretation that’s at the root 
of the controversy. That’s helpful to know.

Clearly (at least this is clear to me) the intent of that sentence is that a 
source-routed packet cannot be said to have reached its ultimate destination 
until it has reached the target of the source route, the point at which the 
source route has been fully consumed. I think (?) you'll agree that isn't the 
interpretation you've chosen, you’ve chosen to interpret “ultimate destination” 
as meaning “the destination depicted in the outer IPv6 header," regardless of 
where the packet is along the source route. Right? So, status quo ante. (I 
think I could defend my reading as being objectively correct based on nothing 
more than the words as written, but that’s beside the point — once we get to 
the stage of spec-lawyering, we have all lost.)

I suppose the choice here remains as it always has been: accept that natural 
language can often be interpreted differently by different readers (especially 
those motivated to reach different interpretations) and leave it at that, 
resolving such differences when they arise through IETF process; or work to 
craft ever more precise language, accepting the consequence that we have to do 
extra work and our specs become more unwieldy as a result. In this particular 
case, I guess an excruciatingly precise definition of “ultimate destination” 
may be the key to resolving ambiguity.

—John

On Feb 29, 2020, at 1:25 PM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 
operation. If this would be deprecated, moved to historic or made illegal - 
games over. But if this is still legal then ultimate destination for a packet 
is what it listed in outer IPv6 header DA. That's pretty basic. Now what the 
destination in the header will do with the packet is completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node." Of 
course it can. You are looking flat .. If you look at different layers the same 
node is in fact acting in multiple roles - I can easily count 3 but with TI-LFA 
it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original 
non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder 
mailto:j...@juniper.net>> wrote:
Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate 
destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of 
messages that have gone before, not to mention the plain language of 
draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is 
enough to prove this: by definition a node can’t be both the penultimate, and 
the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would 
be a different story, but the whole point of PSP is that X removes the RH and 
then sends the encapsulated packet on to Y which performs the decapsulation. 
(This point was made in one of the other threads recently, but I’ve lost track 
of by whom and which thread.) As far as I can tell, this non-controversial 
behavior is described in 4.16.3 of the draft and referred to as “USD”.

—John

On Feb 29, 2020, at 6:06 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its source 
node and extension headers cannot be removed from a packet until it has arrived 
at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason 
being is that we are dealing here with an *encapsulated* packet which has as 
its ultimate destination SR node X. That SR node X is to perform or not PSP. So 
it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 really 
mandates you to look at segments_left before processing the packet or it is 
equally legal to look at that value after local processing occurs. Definition 
says:



  Segments Left   8-bit unsigned integer.  Number of route
  segments remaining, i.e., number of explicitly
  listed intermediate nodes still to be visited
  before reaching the final destination.

which to me really means that as long as you recognize given routing header 
type you can decrement this 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

Hi John,

I respectfully will disagree with your assessment.

Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of
SRv6 operation. If this would be deprecated, moved to historic or made
illegal - games over. But if this is still legal then ultimate destination
for a packet is what it listed in outer IPv6 header DA. That's pretty
basic. Now what the destination in the header will do with the packet is
completely different story.

Reason #2 - "a node can’t be both the penultimate, and the ultimate, node."
Of course it can. You are looking flat .. If you look at different layers
the same node is in fact acting in multiple roles - I can easily count 3
but with TI-LFA it could be  even more.

The same node is ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the
original non encapsulated packet

Kind regards,
R.










On Sat, Feb 29, 2020 at 6:46 PM John Scudder  wrote:

> Robert,
>
> I think your comment (emphasis added):
>
> we are dealing here with an *encapsulated* packet which *has as its
> ultimate destination* SR node X. That SR node X is to perform or not PSP.
>
>
> Is wrong. It contradicts everything else that’s been said in the hundreds
> of messages that have gone before, not to mention the plain language
> of draft-ietf-spring-srv6-network-programming-10. The word “penultimate”
> itself is enough to prove this: by definition a node can’t be both the
> penultimate, and the ultimate, node. It’s a contradiction in terms, like
> saying 0 equals 1.
>
> Now, if node X were to remove the RH *and perform the decapsulation* that
> would be a different story, but the whole point of PSP is that X removes
> the RH and then sends the encapsulated packet on to Y which performs the
> decapsulation. (This point was made in one of the other threads recently,
> but I’ve lost track of by whom and which thread.) As far as I can tell,
> this non-controversial behavior is described in 4.16.3 of the draft and
> referred to as “USD”.
>
> —John
>
> On Feb 29, 2020, at 6:06 AM, Robert Raszuk  wrote:
>
> Dear Jinmei,
>
> Even if RFC8200 section 4 text would say:
>
>  "Extension headers cannot be added to a packet after it has left its
> source node and extension headers cannot be removed from a packet until it
> has arrived at its ultimate destination".
>
> PSP would be still not be violating anything said in this sentence. Reason
> being is that we are dealing here with an *encapsulated* packet which has
> as its ultimate destination SR node X. That SR node X is to perform or not
> PSP. So it is still fully compliant with the specification.
>
> IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4
> really mandates you to look at segments_left before processing the packet
> or it is equally legal to look at that value after local processing occurs.
> Definition says:
>
>
>   Segments Left   8-bit unsigned integer.  Number of route
>   segments remaining, i.e., number of explicitly
>   listed intermediate nodes still to be visited
>   before reaching the final destination.
>
>
> which to me really means that as long as you recognize given routing
> header type you can decrement this value and if zero remove it.
>
> Besides that is a minor detail - as NPG draft could be updated to say:
>
>  S14.1.   If (Segments Left Before Local Decrement == 1) {
>  S14.2.  Update the Next Header field in the preceding header to the
> Next Header value of the SRH
>  S14.3.  Decrease the IPv6 header Payload Length by the Hdr Ext Len
> value of the SRH
>  S14.4.  Remove the SRH from the IPv6 extension header chain
>  S14.5.   }
>
>
> Many thx,
> R.
>
> On Sat, Feb 29, 2020 at 2:28 AM 神明達哉  wrote:
>
>> At Fri, 28 Feb 2020 07:54:28 +,
>> "Xiejingrong (Jingrong)" > > wrote:
>>
>> > The design of PSP for the benefits of deployment is based on the
>> understanding
>> > that it does not violate section 4 of RFC8200. In case the RFC8200 text
>> may be
>> > modified in the future, the PSP may also need to change accordingly.
>>
>> No, it violates Section 4 of RFC8200.  It's a pity that we have to
>> discuss it at this level due to the poor editorial work then (I was
>> also responsible for that as one of those reviewing the bis draft),
>> but anyone who involved the discussion should know the intent of this
>> text intended to say (borrowing from Ron's text) "Extension headers
>> cannot be added to a packet after it has left the its source node and
>> extension headers cannot be removed from a packet until it has arrived
>> at its ultimate destination".  It might look "an attempt of blocking
>> an innovation by a small group of vocal fundamentalists", but if you
>> see the responses without a bias, you'd notice that even some of those
>> who 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[John Scudder]

Robert,

I think your comment (emphasis added):

we are dealing here with an *encapsulated* packet which has as its ultimate 
destination SR node X. That SR node X is to perform or not PSP.

Is wrong. It contradicts everything else that’s been said in the hundreds of 
messages that have gone before, not to mention the plain language of 
draft-ietf-spring-srv6-network-programming-10. The word “penultimate” itself is 
enough to prove this: by definition a node can’t be both the penultimate, and 
the ultimate, node. It’s a contradiction in terms, like saying 0 equals 1.

Now, if node X were to remove the RH and perform the decapsulation that would 
be a different story, but the whole point of PSP is that X removes the RH and 
then sends the encapsulated packet on to Y which performs the decapsulation. 
(This point was made in one of the other threads recently, but I’ve lost track 
of by whom and which thread.) As far as I can tell, this non-controversial 
behavior is described in 4.16.3 of the draft and referred to as “USD”.

—John

On Feb 29, 2020, at 6:06 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its source 
node and extension headers cannot be removed from a packet until it has arrived 
at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason 
being is that we are dealing here with an *encapsulated* packet which has as 
its ultimate destination SR node X. That SR node X is to perform or not PSP. So 
it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4 really 
mandates you to look at segments_left before processing the packet or it is 
equally legal to look at that value after local processing occurs. Definition 
says:



  Segments Left   8-bit unsigned integer.  Number of route
  segments remaining, i.e., number of explicitly
  listed intermediate nodes still to be visited
  before reaching the final destination.

which to me really means that as long as you recognize given routing header 
type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:


 S14.1.   If (Segments Left Before Local Decrement == 1) {
 S14.2.  Update the Next Header field in the preceding header to the
Next Header value of the SRH
 S14.3.  Decrease the IPv6 header Payload Length by the Hdr Ext Len
value of the SRH
 S14.4.  Remove the SRH from the IPv6 extension header chain
 S14.5.   }

Many thx,
R.

On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 
mailto:jin...@wide.ad.jp>> wrote:
At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)" 
mailto:xiejingr...@huawei..com>> wrote:

> The design of PSP for the benefits of deployment is based on the understanding
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> modified in the future, the PSP may also need to change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to
discuss it at this level due to the poor editorial work then (I was
also responsible for that as one of those reviewing the bis draft),
but anyone who involved the discussion should know the intent of this
text intended to say (borrowing from Ron's text) "Extension headers
cannot be added to a packet after it has left the its source node and
extension headers cannot be removed from a packet until it has arrived
at its ultimate destination".  It might look "an attempt of blocking
an innovation by a small group of vocal fundamentalists", but if you
see the responses without a bias, you'd notice that even some of those
who seem neutral about the underlying SRv6 matter interpret the text
that way.

I'd also note that simply because PSP violates RFC8200 doesn't
immediately mean it (PSP) "needs to change".  It can update RFC8200 with
explaining why it's necessary and justified.  That's what I
requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
> justified.

And, since PSP at least wouldn't break PMTUD, I guess the update
proposal will have much more chance to be accepted than a proposal
including EH insertion.  On the other hand, pretending there's no
violation will certainly trigger many appeals and objections at the
IETF last call (I'll certainly object to it).  In the end, it can
easily take much longer, or even fail, than formally claiming an
update to RFC8200.

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Robert Raszuk]

Dear Jinmei,

Even if RFC8200 section 4 text would say:

 "Extension headers cannot be added to a packet after it has left its
source node and extension headers cannot be removed from a packet until it
has arrived at its ultimate destination".

PSP would be still not be violating anything said in this sentence. Reason
being is that we are dealing here with an *encapsulated* packet which has
as its ultimate destination SR node X. That SR node X is to perform or not
PSP. So it is still fully compliant with the specification.

IMHO the only grey area as pointed by Brian is if RFC8200 section 4.4
really mandates you to look at segments_left before processing the packet
or it is equally legal to look at that value after local processing occurs.
Definition says:


  Segments Left   8-bit unsigned integer.  Number of route
  segments remaining, i.e., number of explicitly
  listed intermediate nodes still to be visited
  before reaching the final destination.


which to me really means that as long as you recognize given routing header
type you can decrement this value and if zero remove it.

Besides that is a minor detail - as NPG draft could be updated to say:

 S14.1.   If (Segments Left Before Local Decrement == 1) {
 S14.2.  Update the Next Header field in the preceding header to the
Next Header value of the SRH
 S14.3.  Decrease the IPv6 header Payload Length by the Hdr Ext Len
value of the SRH
 S14.4.  Remove the SRH from the IPv6 extension header chain
 S14.5.   }


Many thx,
R.

On Sat, Feb 29, 2020 at 2:28 AM 神明達哉  wrote:

> At Fri, 28 Feb 2020 07:54:28 +,
> "Xiejingrong (Jingrong)"  wrote:
>
> > The design of PSP for the benefits of deployment is based on the
> understanding
> > that it does not violate section 4 of RFC8200. In case the RFC8200 text
> may be
> > modified in the future, the PSP may also need to change accordingly.
>
> No, it violates Section 4 of RFC8200.  It's a pity that we have to
> discuss it at this level due to the poor editorial work then (I was
> also responsible for that as one of those reviewing the bis draft),
> but anyone who involved the discussion should know the intent of this
> text intended to say (borrowing from Ron's text) "Extension headers
> cannot be added to a packet after it has left the its source node and
> extension headers cannot be removed from a packet until it has arrived
> at its ultimate destination".  It might look "an attempt of blocking
> an innovation by a small group of vocal fundamentalists", but if you
> see the responses without a bias, you'd notice that even some of those
> who seem neutral about the underlying SRv6 matter interpret the text
> that way.
>
> I'd also note that simply because PSP violates RFC8200 doesn't
> immediately mean it (PSP) "needs to change".  It can update RFC8200 with
> explaining why it's necessary and justified.  That's what I
> requested as you summarized:
>
> > Jinmei: it should say it updates this part of RFC8200 and explain why
> it's justified.
>
> And, since PSP at least wouldn't break PMTUD, I guess the update
> proposal will have much more chance to be accepted than a proposal
> including EH insertion.  On the other hand, pretending there's no
> violation will certainly trigger many appeals and objections at the
> IETF last call (I'll certainly object to it).  In the end, it can
> easily take much longer, or even fail, than formally claiming an
> update to RFC8200.
>
> --
> JINMEI, Tatuya
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra]

Along those same lines of thought.

If you upgrade all your source SR node ingress PEs to be SRv6 capable you
have in fact upgraded all your final destination egress PE nodes to be SRv6
capable.

Gyan

On Fri, Feb 28, 2020 at 9:37 PM Gyan Mishra  wrote:

> Jingrong & Bruno
>
> Here is another point for consideration related to PSP.
>
> Drawing an analogy here between MPLS and SRv6 as SRv6 would be the Next
> Gen replacement of MPLS.
>
> Topology
>
> A - B - C
>
> An LSP is uni directional where the path to  FEC destination egress PE
>  can be in either direction where the LSP is built from A to C with PHP
> node B -and an LSP is built in the reverse direction from C to A with PHP
> node B.
>
> This same philosophy applies to SR both SRv6 and SR-MPLS.
>
> So the thought that the final destination egress PE node has legacy
> hardware with SRH processing limitations would apply to all PEs, both the
> SR source node which would be acting as a destination node for an LSP as
> well  in the reverse direction.
>
> So the idea that PSP is beneficial for the final destination egress PE
> legacy node old hardware does not make sense.
>
> As I mentioned to Pablo all the heavy lifting routing protocols heavy
> processing is done on the PEs and not the P routers.  However due to the
> scenario described above you can get away with not upgrading the P transit
> nodes in being SRv6 capable but you really have no choice and have to
> upgrade all your PEs to be SRv6 capable.
>
> Kind regards
>
> Gyan
>
> On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <
> xiejingr...@huawei.com> wrote:
>
>> Got it.
>> Thanks for your clarification of your point.
>>
>> Jingrong
>>
>> -Original Message-
>> From: 神明達哉 [mailto:jin...@wide.ad.jp]
>> Sent: Saturday, February 29, 2020 9:28 AM
>> To: Xiejingrong (Jingrong) 
>> Cc: Ted Lemon ; Pablo Camarillo (pcamaril) <
>> pcama...@cisco.com>; Brian E Carpenter ;
>> Bob Hinden ; Joel M. Halpern ;
>> spring@ietf.org; 6...@ietf.org
>> Subject: Re: Suggest some text //RE: [spring] Request to close the LC and
>> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>>
>> At Fri, 28 Feb 2020 07:54:28 +,
>> "Xiejingrong (Jingrong)"  wrote:
>>
>> > The design of PSP for the benefits of deployment is based on the
>> > understanding that it does not violate section 4 of RFC8200. In case
>> > the RFC8200 text may be modified in the future, the PSP may also need
>> to change accordingly.
>>
>> No, it violates Section 4 of RFC8200.  It's a pity that we have to
>> discuss it at this level due to the poor editorial work then (I was also
>> responsible for that as one of those reviewing the bis draft), but anyone
>> who involved the discussion should know the intent of this text intended to
>> say (borrowing from Ron's text) "Extension headers cannot be added to a
>> packet after it has left the its source node and extension headers cannot
>> be removed from a packet until it has arrived at its ultimate
>> destination".  It might look "an attempt of blocking an innovation by a
>> small group of vocal fundamentalists", but if you see the responses without
>> a bias, you'd notice that even some of those who seem neutral about the
>> underlying SRv6 matter interpret the text that way.
>>
>> I'd also note that simply because PSP violates RFC8200 doesn't
>> immediately mean it (PSP) "needs to change".  It can update RFC8200 with
>> explaining why it's necessary and justified.  That's what I requested as
>> you summarized:
>>
>> > Jinmei: it should say it updates this part of RFC8200 and explain why
>> it's justified.
>>
>> And, since PSP at least wouldn't break PMTUD, I guess the update proposal
>> will have much more chance to be accepted than a proposal including EH
>> insertion.  On the other hand, pretending there's no violation will
>> certainly trigger many appeals and objections at the IETF last call (I'll
>> certainly object to it).  In the end, it can easily take much longer, or
>> even fail, than formally claiming an update to RFC8200.
>>
>> --
>> JINMEI, Tatuya
>> ___
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: 301 502-1347
>
> Email: gyan.s.mis...@verizon.com
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Gyan Mishra]

Jingrong & Bruno

Here is another point for consideration related to PSP.

Drawing an analogy here between MPLS and SRv6 as SRv6 would be the Next Gen
replacement of MPLS.

Topology

A - B - C

An LSP is uni directional where the path to  FEC destination egress PE  can
be in either direction where the LSP is built from A to C with PHP node B
-and an LSP is built in the reverse direction from C to A with PHP node B.

This same philosophy applies to SR both SRv6 and SR-MPLS.

So the thought that the final destination egress PE node has legacy
hardware with SRH processing limitations would apply to all PEs, both the
SR source node which would be acting as a destination node for an LSP as
well  in the reverse direction.

So the idea that PSP is beneficial for the final destination egress PE
legacy node old hardware does not make sense.

As I mentioned to Pablo all the heavy lifting routing protocols heavy
processing is done on the PEs and not the P routers.  However due to the
scenario described above you can get away with not upgrading the P transit
nodes in being SRv6 capable but you really have no choice and have to
upgrade all your PEs to be SRv6 capable.

Kind regards

Gyan

On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <
xiejingr...@huawei.com> wrote:

> Got it.
> Thanks for your clarification of your point.
>
> Jingrong
>
> -Original Message-
> From: 神明達哉 [mailto:jin...@wide.ad.jp]
> Sent: Saturday, February 29, 2020 9:28 AM
> To: Xiejingrong (Jingrong) 
> Cc: Ted Lemon ; Pablo Camarillo (pcamaril) <
> pcama...@cisco.com>; Brian E Carpenter ; Bob
> Hinden ; Joel M. Halpern ;
> spring@ietf.org; 6...@ietf.org
> Subject: Re: Suggest some text //RE: [spring] Request to close the LC and
> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
> At Fri, 28 Feb 2020 07:54:28 +,
> "Xiejingrong (Jingrong)"  wrote:
>
> > The design of PSP for the benefits of deployment is based on the
> > understanding that it does not violate section 4 of RFC8200. In case
> > the RFC8200 text may be modified in the future, the PSP may also need to
> change accordingly.
>
> No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss
> it at this level due to the poor editorial work then (I was also
> responsible for that as one of those reviewing the bis draft), but anyone
> who involved the discussion should know the intent of this text intended to
> say (borrowing from Ron's text) "Extension headers cannot be added to a
> packet after it has left the its source node and extension headers cannot
> be removed from a packet until it has arrived at its ultimate
> destination".  It might look "an attempt of blocking an innovation by a
> small group of vocal fundamentalists", but if you see the responses without
> a bias, you'd notice that even some of those who seem neutral about the
> underlying SRv6 matter interpret the text that way.
>
> I'd also note that simply because PSP violates RFC8200 doesn't immediately
> mean it (PSP) "needs to change".  It can update RFC8200 with explaining why
> it's necessary and justified.  That's what I requested as you summarized:
>
> > Jinmei: it should say it updates this part of RFC8200 and explain why
> it's justified.
>
> And, since PSP at least wouldn't break PMTUD, I guess the update proposal
> will have much more chance to be accepted than a proposal including EH
> insertion.  On the other hand, pretending there's no violation will
> certainly trigger many appeals and objections at the IETF last call (I'll
> certainly object to it).  In the end, it can easily take much longer, or
> even fail, than formally claiming an update to RFC8200.
>
> --
> JINMEI, Tatuya
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Got it.
Thanks for your clarification of your point. 

Jingrong

-Original Message-
From: 神明達哉 [mailto:jin...@wide.ad.jp] 
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong) 
Cc: Ted Lemon ; Pablo Camarillo (pcamaril) 
; Brian E Carpenter ; Bob 
Hinden ; Joel M. Halpern ; 
spring@ietf.org; 6...@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)"  wrote:

> The design of PSP for the benefits of deployment is based on the 
> understanding that it does not violate section 4 of RFC8200. In case 
> the RFC8200 text may be modified in the future, the PSP may also need to 
> change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to discuss it 
at this level due to the poor editorial work then (I was also responsible for 
that as one of those reviewing the bis draft), but anyone who involved the 
discussion should know the intent of this text intended to say (borrowing from 
Ron's text) "Extension headers cannot be added to a packet after it has left 
the its source node and extension headers cannot be removed from a packet until 
it has arrived at its ultimate destination".  It might look "an attempt of 
blocking an innovation by a small group of vocal fundamentalists", but if you 
see the responses without a bias, you'd notice that even some of those who seem 
neutral about the underlying SRv6 matter interpret the text that way.

I'd also note that simply because PSP violates RFC8200 doesn't immediately mean 
it (PSP) "needs to change".  It can update RFC8200 with explaining why it's 
necessary and justified.  That's what I requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
> justified.

And, since PSP at least wouldn't break PMTUD, I guess the update proposal will 
have much more chance to be accepted than a proposal including EH insertion.  
On the other hand, pretending there's no violation will certainly trigger many 
appeals and objections at the IETF last call (I'll certainly object to it).  In 
the end, it can easily take much longer, or even fail, than formally claiming 
an update to RFC8200.

--
JINMEI, Tatuya
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Got it.
So the gap may be the 'protocol spec' and the 'code/implementation reality'.
"a non-SRV6 capable router receives SRV6 with segments-left == 0" may have many 
reasons not implemented this well  If Segments Left is zero, the node must 
ignore the Routing header with an unrecognized Routing Type value.
It may just drop any packet with Next Header value other than 4/41/47/etc. 
It may send such packet with any routing header to its slow-path for the 
compliance but lose the necessary performance.
I guess the proposal of PSP is only to solve that kind of engineering problems 
for deployment, and that's why I think once that is not necessary it should not 
be recommended.

Thanks
Jingrong

-Original Message-
From: Bob Hinden [mailto:bob.hin...@gmail.com] 
Sent: Saturday, February 29, 2020 6:52 AM
To: Brian Carpenter 
Cc: Bob Hinden ; Xiejingrong (Jingrong) 
; Ted Lemon ; Pablo Camarillo 
(pcamaril) ; 神明達哉 ; Joel M. Halpern 
; spring@ietf.org; 6...@ietf.org
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move 
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian,

> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter  
> wrote:
> 
> Hi Jingrong,
> 
> Thanks for your suggestion.
> 
>> so that the tunnel endpoint
>> router (C) doesn't have to deal with SRH.
> 
> Actually, why does this matter? RFC8200 already handles this case:
> 
>   If, while processing a received packet, a node encounters a Routing
>   header with an unrecognized Routing Type value, the required behavior
>   of the node depends on the value of the Segments Left field, as
>   follows:
> 
>  If Segments Left is zero, the node must ignore the Routing header
>  and proceed to process the next header in the packet, whose type
>  is identified by the Next Header field in the Routing header.
> 
> If a non-SRV6 capable router receives SRV6 with segments-left == 0, it 
> must ignore it. (So why is PSP needed at all?)

Good point and question.   This is why there is a common base format for all 
IPv6 routing headers, it allows for this case.

Bob


> 
> Regards
>   Brian
> 
> On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
>> Hi
>> 
>> 
>> 
>> Thanks Ted for the constructive suggestions, which remind me to try to 
>> understand the questions. Here are the questions I think give the clear 
>> suggestions for LC.
>> 
>> 
>> 
>> Brian: So could the draft make this explicit, because I guarantee you it is 
>> not in the least obvious to the non-expert reader?
>> 
>> 
>> 
>> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
>> justified.
>> 
>> 
>> 
>> Joel: it would seem that there ought to be a good reason for including PSP, 
>> rather than claiming that objectors need to motivate removing it.
>> 
>> 
>> 
>> Bob: There seems to be questions about its relationship with RFC8200.  I am 
>> not seeing this as being resolved.
>> 
>> 
>> 
>> As far as I understand the concern and the draft, I may have the following 
>> proposed text, though I don’t know if that will help to close or narrow the 
>> gap:
>> 
>> 
>> 
>> Proposed text to explicitly explain the PSP at the end of 4.16.1 
>> of rev-10
>> 
>> 
>> 
>> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that 
>> is, router (A)
>> 
>> imposes an SRH, and a Penultimate Segment router (B) removes the SRH 
>> before
>> 
>> this packet goes to the tunnel end point router (C), so that the 
>> tunnel endpoint
>> 
>> router (C) doesn't have to deal with SRH.
>> 
>> 
>> 
>> This has some very important benefits for deployment in some networks 
>> when the
>> 
>> final tunnel end point is a lower-end node which is not capable of 
>> processing
>> 
>> the SRH for reasons like the hardware is overloaded or unable to 
>> upgraded to
>> 
>> process well with SRH.
>> 
>> 
>> 
>> The use of SRH with AH by an SR source node, and processing at a SR 
>> Penultimate
>> 
>> segment endpoint node is not defined in 
>> 
>> 
>> or in this document.
>> 
>> 
>> 
>> The use of PSP does not impact the MTU Considerations defined in 
>> section 5.3 of
>> 
>> .
>> 
>> 
>> 
>> The design of PSP for the benefits of deployment is based on the 
>> understanding
>> 
>> that it does not violate section 4 of RFC8200. In case the RFC8200 
>> text may be
>> 
>> modified in the future, the PSP may also need to change accordingly.
>> 
>> 
>> 
>> In case the final tunnel endpoint router is fully capable of the 
>> functionality
>> 
>> of SRH and the SRv6-NP defined in this document, it is recommended 
>> not to use
>> 
>> the PSP.
>> 
>> 
>> 
>> ***End
>> 
>> 
>> 
>> Thanks
>> 
>> Jingrong
>> 
>> 
>> 
>> 
>> 
>> *From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Ted 
>> Lemon
>> *Sent:* Friday, February 28, 2020 4:55 AM
>> *To:* Pablo Camarillo (pcamaril) 
>> *Cc:* spring@ietf.org; 6...@ietf.org
>> *Subject:* Re: [spring] Request to close the LC and move forward//RE: 
>> WGLC - 

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[神明達哉]

At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)"  wrote:

> The design of PSP for the benefits of deployment is based on the understanding
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> modified in the future, the PSP may also need to change accordingly.

No, it violates Section 4 of RFC8200.  It's a pity that we have to
discuss it at this level due to the poor editorial work then (I was
also responsible for that as one of those reviewing the bis draft),
but anyone who involved the discussion should know the intent of this
text intended to say (borrowing from Ron's text) "Extension headers
cannot be added to a packet after it has left the its source node and
extension headers cannot be removed from a packet until it has arrived
at its ultimate destination".  It might look "an attempt of blocking
an innovation by a small group of vocal fundamentalists", but if you
see the responses without a bias, you'd notice that even some of those
who seem neutral about the underlying SRv6 matter interpret the text
that way.

I'd also note that simply because PSP violates RFC8200 doesn't
immediately mean it (PSP) "needs to change".  It can update RFC8200 with
explaining why it's necessary and justified.  That's what I
requested as you summarized:

> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
> justified.

And, since PSP at least wouldn't break PMTUD, I guess the update
proposal will have much more chance to be accepted than a proposal
including EH insertion.  On the other hand, pretending there's no
violation will certainly trigger many appeals and objections at the
IETF last call (I'll certainly object to it).  In the end, it can
easily take much longer, or even fail, than formally claiming an
update to RFC8200.

--
JINMEI, Tatuya

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Brian E Carpenter]

Hi Jingrong,

Thanks for your suggestion.

> so that the tunnel endpoint
> router (C) doesn't have to deal with SRH.  

Actually, why does this matter? RFC8200 already handles this case:

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

  If Segments Left is zero, the node must ignore the Routing header
  and proceed to process the next header in the packet, whose type
  is identified by the Next Header field in the Routing header.

If a non-SRV6 capable router receives SRV6 with segments-left == 0, it
must ignore it. (So why is PSP needed at all?)

Regards
   Brian

On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
> Hi
> 
>  
> 
> Thanks Ted for the constructive suggestions, which remind me to try to 
> understand the questions. Here are the questions I think give the clear 
> suggestions for LC.
> 
>  
> 
> Brian: So could the draft make this explicit, because I guarantee you it is 
> not in the least obvious to the non-expert reader?
> 
>  
> 
> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
> justified.
> 
>  
> 
> Joel: it would seem that there ought to be a good reason for including PSP, 
> rather than claiming that objectors need to motivate removing it.
> 
>  
> 
> Bob: There seems to be questions about its relationship with RFC8200.  I am 
> not seeing this as being resolved.
> 
>  
> 
> As far as I understand the concern and the draft, I may have the following 
> proposed text, though I don’t know if that will help to close or narrow the 
> gap:
> 
>  
> 
> Proposed text to explicitly explain the PSP at the end of 4.16.1 of 
> rev-10
> 
>  
> 
> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that is, 
> router (A)
> 
> imposes an SRH, and a Penultimate Segment router (B) removes the SRH before
> 
> this packet goes to the tunnel end point router (C), so that the tunnel 
> endpoint
> 
> router (C) doesn't have to deal with SRH. 
> 
>  
> 
> This has some very important benefits for deployment in some networks when the
> 
> final tunnel end point is a lower-end node which is not capable of processing
> 
> the SRH for reasons like the hardware is overloaded or unable to upgraded to
> 
> process well with SRH.
> 
>  
> 
> The use of SRH with AH by an SR source node, and processing at a SR 
> Penultimate
> 
> segment endpoint node is not defined in 
> 
> 
> or in this document.
> 
>  
> 
> The use of PSP does not impact the MTU Considerations defined in section 5.3 
> of
> 
> .
> 
>  
> 
> The design of PSP for the benefits of deployment is based on the understanding
> 
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> 
> modified in the future, the PSP may also need to change accordingly.
> 
>  
> 
> In case the final tunnel endpoint router is fully capable of the functionality
> 
> of SRH and the SRv6-NP defined in this document, it is recommended not to use
> 
> the PSP.
> 
>  
> 
> ***End
> 
>  
> 
> Thanks
> 
> Jingrong
> 
>  
> 
>  
> 
> *From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Friday, February 28, 2020 4:55 AM
> *To:* Pablo Camarillo (pcamaril) 
> *Cc:* spring@ietf.org; 6...@ietf.org
> *Subject:* Re: [spring] Request to close the LC and move forward//RE: WGLC - 
> draft-ietf-spring-srv6-network-programming
> 
>  
> 
> On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril)  > wrote:
> 
> The discussion that we are having is about PSP which has nothing to do 
> with that.
> 
>  
> 
> So, there is text in the document that addresses Brian’s question?
> 
>  
> 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Bob Hinden]

Brian,

> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter  
> wrote:
> 
> Hi Jingrong,
> 
> Thanks for your suggestion.
> 
>> so that the tunnel endpoint
>> router (C) doesn't have to deal with SRH.
> 
> Actually, why does this matter? RFC8200 already handles this case:
> 
>   If, while processing a received packet, a node encounters a Routing
>   header with an unrecognized Routing Type value, the required behavior
>   of the node depends on the value of the Segments Left field, as
>   follows:
> 
>  If Segments Left is zero, the node must ignore the Routing header
>  and proceed to process the next header in the packet, whose type
>  is identified by the Next Header field in the Routing header.
> 
> If a non-SRV6 capable router receives SRV6 with segments-left == 0, it
> must ignore it. (So why is PSP needed at all?)

Good point and question.   This is why there is a common base format for all 
IPv6 routing headers, it allows for this case.

Bob


> 
> Regards
>   Brian
> 
> On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
>> Hi
>> 
>> 
>> 
>> Thanks Ted for the constructive suggestions, which remind me to try to 
>> understand the questions. Here are the questions I think give the clear 
>> suggestions for LC.
>> 
>> 
>> 
>> Brian: So could the draft make this explicit, because I guarantee you it is 
>> not in the least obvious to the non-expert reader?
>> 
>> 
>> 
>> Jinmei: it should say it updates this part of RFC8200 and explain why it's 
>> justified.
>> 
>> 
>> 
>> Joel: it would seem that there ought to be a good reason for including PSP, 
>> rather than claiming that objectors need to motivate removing it.
>> 
>> 
>> 
>> Bob: There seems to be questions about its relationship with RFC8200.  I am 
>> not seeing this as being resolved.
>> 
>> 
>> 
>> As far as I understand the concern and the draft, I may have the following 
>> proposed text, though I don’t know if that will help to close or narrow the 
>> gap:
>> 
>> 
>> 
>> Proposed text to explicitly explain the PSP at the end of 4.16.1 of 
>> rev-10
>> 
>> 
>> 
>> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that is, 
>> router (A)
>> 
>> imposes an SRH, and a Penultimate Segment router (B) removes the SRH before
>> 
>> this packet goes to the tunnel end point router (C), so that the tunnel 
>> endpoint
>> 
>> router (C) doesn't have to deal with SRH.
>> 
>> 
>> 
>> This has some very important benefits for deployment in some networks when 
>> the
>> 
>> final tunnel end point is a lower-end node which is not capable of processing
>> 
>> the SRH for reasons like the hardware is overloaded or unable to upgraded to
>> 
>> process well with SRH.
>> 
>> 
>> 
>> The use of SRH with AH by an SR source node, and processing at a SR 
>> Penultimate
>> 
>> segment endpoint node is not defined in 
>> 
>> 
>> or in this document.
>> 
>> 
>> 
>> The use of PSP does not impact the MTU Considerations defined in section 5.3 
>> of
>> 
>> .
>> 
>> 
>> 
>> The design of PSP for the benefits of deployment is based on the 
>> understanding
>> 
>> that it does not violate section 4 of RFC8200. In case the RFC8200 text may 
>> be
>> 
>> modified in the future, the PSP may also need to change accordingly.
>> 
>> 
>> 
>> In case the final tunnel endpoint router is fully capable of the 
>> functionality
>> 
>> of SRH and the SRv6-NP defined in this document, it is recommended not to use
>> 
>> the PSP.
>> 
>> 
>> 
>> ***End
>> 
>> 
>> 
>> Thanks
>> 
>> Jingrong
>> 
>> 
>> 
>> 
>> 
>> *From:*spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Ted Lemon
>> *Sent:* Friday, February 28, 2020 4:55 AM
>> *To:* Pablo Camarillo (pcamaril) 
>> *Cc:* spring@ietf.org; 6...@ietf.org
>> *Subject:* Re: [spring] Request to close the LC and move forward//RE: WGLC - 
>> draft-ietf-spring-srv6-network-programming
>> 
>> 
>> 
>> On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) > > wrote:
>> 
>>The discussion that we are having is about PSP which has nothing to do 
>> with that.
>> 
>> 
>> 
>> So, there is text in the document that addresses Brian’s question?
>> 
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

[Xiejingrong (Jingrong)]

Hi

Thanks Ted for the constructive suggestions, which remind me to try to 
understand the questions. Here are the questions I think give the clear 
suggestions for LC.

Brian: So could the draft make this explicit, because I guarantee you it is not 
in the least obvious to the non-expert reader?

Jinmei: it should say it updates this part of RFC8200 and explain why it's 
justified.

Joel: it would seem that there ought to be a good reason for including PSP, 
rather than claiming that objectors need to motivate removing it.

Bob: There seems to be questions about its relationship with RFC8200.  I am not 
seeing this as being resolved.

As far as I understand the concern and the draft, I may have the following 
proposed text, though I don’t know if that will help to close or narrow the gap:

Proposed text to explicitly explain the PSP at the end of 4.16.1 of 
rev-10

Note that, the SRH is used in an X-in-IP6 tunnel end point case, that is, 
router (A)
imposes an SRH, and a Penultimate Segment router (B) removes the SRH before
this packet goes to the tunnel end point router (C), so that the tunnel endpoint
router (C) doesn't have to deal with SRH.

This has some very important benefits for deployment in some networks when the
final tunnel end point is a lower-end node which is not capable of processing
the SRH for reasons like the hardware is overloaded or unable to upgraded to
process well with SRH.

The use of SRH with AH by an SR source node, and processing at a SR Penultimate
segment endpoint node is not defined in 
or in this document.

The use of PSP does not impact the MTU Considerations defined in section 5.3 of
.

The design of PSP for the benefits of deployment is based on the understanding
that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
modified in the future, the PSP may also need to change accordingly.

In case the final tunnel endpoint router is fully capable of the functionality
of SRH and the SRv6-NP defined in this document, it is recommended not to use
the PSP.

***End

Thanks
Jingrong


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Friday, February 28, 2020 4:55 AM
To: Pablo Camarillo (pcamaril) 
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - 
draft-ietf-spring-srv6-network-programming

On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) 
mailto:pcama...@cisco.com>> wrote:
The discussion that we are having is about PSP which has nothing to do with 
that.

So, there is text in the document that addresses Brian’s question?

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring