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

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 28 Feb 2020 07:54:28 +0000

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 <draft-ietf-6man-segment-routing-header>
or in this document.

The use of PSP does not impact the MTU Considerations defined in section 5.3 of
<draft-ietf-6man-segment-routing-header>.

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:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, February 28, 2020 4:55 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> 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?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Feb 2020 11:46:03 +1300

Hi Jingrong,

Thanks for your suggestion.

> so that the tunnel endpoint

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:
> *From:*spring [mailto:[email-masked]] *On Behalf Of *Ted Lemon
> *Sent:* Friday, February 28, 2020 4:55 AM
> *To:* Pablo Camarillo (pcamaril) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *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) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Feb 2020 14:51:45 -0800

Brian,

> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Jingrong,
> 

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

Bob

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Feb 2020 17:27:45 -0800

At Fri, 28 Feb 2020 07:54:28 +0000,

> 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

> 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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 29 Feb 2020 02:03:30 +0000

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:[email-masked]] 
Sent: Saturday, February 29, 2020 6:52 AM
To: Brian Carpenter <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; Ted Lemon <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; 神明達哉 <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Suggest some text //RE: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian,

Bob

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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 29 Feb 2020 02:13:51 +0000

Got it.
Thanks for your clarification of your point. 

Jingrong

-----Original Message-----
From: 神明達哉 [mailto:[email-masked]] 
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Ted Lemon <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>; Brian E Carpenter <[email-masked]>; Bob Hinden <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]
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 +0000,
"Xiejingrong (Jingrong)" <[email-masked]> 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.

> 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

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 28 Feb 2020 21:37:45 -0500

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) <
[email-masked]> wrote:

> Cc: Ted Lemon <[email-masked]>; Pablo Camarillo (pcamaril) <
> [email-masked]>; Brian E Carpenter <[email-masked]>; Bob
> Hinden <[email-masked]>; Joel M. Halpern <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: Suggest some text //RE: [spring] Request to close the LC and
> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
> 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:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 28 Feb 2020 21:45:41 -0500

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 <[email-masked]> wrote:

> 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.
>
>> [email-masked]>; Brian E Carpenter <[email-masked]>;
>> Bob Hinden <[email-masked]>; Joel M. Halpern <[email-masked]>;
>> discuss it at this level due to the poor editorial work then (I was also
>> explaining why it's necessary and justified.  That's what I requested as
>> you summarized:
>>

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 12:06:17 +0100

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 神明達哉 <[email-masked]> wrote:

> understanding

---

From: John Scudder <[email-masked]>
Date: Sat, 29 Feb 2020 17:46:38 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear Jinmei,

 "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:

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.

Many thx,
R.

On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
At Fri, 28 Feb 2020 07:54:28 +0000,

--
JINMEI, Tatuya

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 19:25:43 +0100

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 <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
>
> Dear Jinmei,
>
> 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.
>
>> "Xiejingrong (Jingrong)" <[email-masked]
>> <xiejingrong@huawei..com>> wrote:
>>
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>
>>
> [email-masked]
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$

---

From: John Scudder <[email-masked]>
Date: Sat, 29 Feb 2020 19:23:05 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

—John

Dear Jinmei,

Many thx,
R.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Mar 2020 08:25:30 +1300

On 01-Mar-20 07:25, Robert Raszuk wrote:
> 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. 
> 
> On Sat, Feb 29, 2020 at 6:46 PM John Scudder <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Robert,
> 
>>     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.
> 
>     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 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Dear Jinmei,
>>
>>     On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         "Xiejingrong (Jingrong)" <[email-masked] <mailto:xiejingrong@huawei...com>> wrote:
>>
>>         [email-masked] <mailto:[email-masked]>
>>         https://www.ietf.org/mailman/listinfo/spring <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$ <https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: John Scudder <[email-masked]>
Date: Sat, 29 Feb 2020 19:32:31 +0000

Thanks, Brian.

On Feb 29, 2020, at 2:25 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

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

—John

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 29 Feb 2020 11:57:24 -0800

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 <
[email-masked]> wrote:

> > 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.
> >
> >>     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
> >
> >>      "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:
> >>
> >>
> >>     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.
> >>
> >>         https://www.ietf.org/mailman/listinfo/spring <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$
> >
> >>
> <
> https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$
> >

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 21:36:17 +0100

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 <[email-masked]> wrote:

>> >>     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.
>> >
>> >     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
>> >>     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.
>> >>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 29 Feb 2020 12:46:27 -0800

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 <[email-masked]> wrote:

> 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.
>
>
>
>>> > 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 29 Feb 2020 21:55:26 +0100

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 <[email-masked]> 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 <[email-masked]> wrote:
>
> Hi John,
>
> 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.
>
>> Now, if node X were to remove the RH *and perform the decapsulation*

---

From: John Scudder <[email-masked]>
Date: Sat, 29 Feb 2020 21:47:25 +0000

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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.

—John

Hi John,

Kind regards,
R.

—John

Dear Jinmei,

Many thx,
R.

--
JINMEI, Tatuya

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 29 Feb 2020 22:47:21 +0000

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 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Saturday, February 29, 2020 at 3:47 PM
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 神明達哉 <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

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

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

   Brian

> On Sat, Feb 29, 2020 at 6:46 PM John Scudder <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Robert,
>
>     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 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>     Dear Jinmei,
>>
>>     On Sat, Feb 29, 2020 at 2:28 AM 神明達哉 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>         "Xiejingrong (Jingrong)" <[email-masked]<mailto:[email-masked]> <mailto:xiejingrong@huawei.<mailto:xiejingrong@huawei.>..com>> wrote:
>>
>>         at its ultimate destination"..  It might look "an attempt of blocking
>>         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>         https://www.ietf.org/mailman/listinfo/spring <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>>
>>
>>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$> <https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$<https://urldefense.com/v3/__https:/www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$>>

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Sun, 1 Mar 2020 03:11:38 +0000

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 <[email-masked]> On Behalf Of John Scudder
Sent: Sunday, March 1, 2020 5:47 AM
To: Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]; 神明達哉 <[email-masked]>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

—John

John,

Robert.

—John

Hi John,

Kind regards,
R.

—John

Dear Jinmei,

                value of the SRH

 S14.5.   }

Many thx,
R.

--
JINMEI, Tatuya

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3UdazBorQ$>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$>
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Feb 2020 23:50:00 -0500

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.
> 
> have all agreed will not be subject to PSP.. Is there a value to keep 
>     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
>     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
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>          > 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 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 <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>          >
>          >     Robert,
>          >
>          >>     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.
>          >
>         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
>          >>     On Feb 29, 2020, at 6:06 AM, Robert Raszuk
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          >>
>          >>     Dear Jinmei,
>          >>
>          >>      "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:
>          >>
>          >>
>          >>     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.
>          >>
>          >>     On Sat, Feb 29, 2020 at 2:28 AM 神明達哉
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>          >>
>         <mailto:[email-masked]> <mailto:xiejingrong@huawei.
>         <mailto:xiejingrong@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.
>          >>
>          >>         > Jinmei: it should say it updates this part of
>         RFC8200 and explain why it's justified.
>          >>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>          >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>          >>     Administrative Requests:
>         <https://urldefense.com/v3/__https://www..ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Qj4iGvIKXE0YABWYjk5PNMfr1edPfPjJBED6VMnC3MxTiIYCqCc0y3X18TtwYw$>
>          >>   
>         https://www.ietf.org/mailman/listinfo/ipv6
>          >

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 1 Mar 2020 07:33:00 +0000

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]----[rtA----rtB----rtC]----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:[email-masked]] On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder <jgs=[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; [email-masked]; 神明達哉 <[email-masked]>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Cheers!

Wang Weibin

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

—John

John,

Robert.

—John

Hi John,

Kind regards,
R.

—John

Dear Jinmei,

                value of the SRH

 S14.5.   }

Many thx,
R.

--
JINMEI, Tatuya

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 1 Mar 2020 07:41:14 +0000

Hi Weibin,

Suppose:

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:

Thanks
Jingrong

To: John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>

Cheers!

Wang Weibin

—John

John,

Robert.

—John

Hi John,

Kind regards,
R.

—John

Dear Jinmei,

                value of the SRH

 S14.5.   }

Many thx,
R.

--
JINMEI, Tatuya