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

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

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) <[email-masked]>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>
Cc: [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 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=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:[email-masked]] On Behalf Of Wang, Weibin (NSB - CN/Shanghai)
Sent: Sunday, March 1, 2020 11:12 AM
To: John Scudder <jgs=[email-masked]<mailto:jgs=[email-masked]>>; 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

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

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.

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,

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]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:
At Fri, 28 Feb 2020 07:54:28 +0000,
"Xiejingrong (Jingrong)" <[email-masked]<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.

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
[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: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sun, 1 Mar 2020 08:24:14 +0000

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:[email-masked]]
Sent: Sunday, March 1, 2020 4:01 PM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: [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 Jingrong:

Cheers!

Wang Weibin

From: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, March 1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>>
Cc: [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

Hi Weibin,

Suppose:

Thanks
Jingrong

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

---

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

Hi Jingrong:

My comments inline;

Cheers!

Wang Weibin

Sent: Sunday, March 1, 2020 4:24 PM

Hi Weibin,

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.

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

Thanks
Jingrong

To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>

Hi Jingrong:

Cheers!

Wang Weibin

Hi Weibin,

Suppose:

Thanks
Jingrong

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

---

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

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

Hi Weibin,

Thanks
Jingrong

Hi Jingrong:

Cheers!

Wang Weibin

Hi Weibin,

Suppose:

Thanks
Jingrong

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

---

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

Cheers!
Jingrong

Sent: Sunday, March 1, 2020 4:53 PM

Hi Jingrong:

Cheers!

Wang Weibin

Hi Weibin,

Thanks
Jingrong

Hi Jingrong:

Cheers!

Wang Weibin

Hi Weibin,

Suppose:

Thanks
Jingrong

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Mar 2020 14:07:31 +0100

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 1 Mar 2020 08:21:50 -0500

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:
> function (to limit IGP burden) Example: odd SID includes PSP and even 
> SID does not.
> 
> On Sun, Mar 1, 2020 at 5:50 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 1 Mar 2020 14:32:18 +0100

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

> traversal is directed by even SID and is not subject to PSP..
>
> Done.
>
> Thx,
> R.
>
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 1 Mar 2020 13:57:47 +0000

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 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Sunday, March 1, 2020 at 8:32 AM
To: Robert Raszuk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, spring <[email-masked]>, "Joel M. Halpern" <[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,
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 1 Mar 2020 09:08:58 -0500

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.
> 
> *From: *spring <[email-masked]> on behalf of Greg Mirsky 
> <[email-masked]>
> *Date: *Sunday, March 1, 2020 at 8:32 AM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, spring <[email-masked]>, "Joel 
> M. Halpern" <[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,
> 
>     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.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sun, 1 Mar 2020 14:34:16 +0000

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" <[email-masked]>
Date: Sunday, March 1, 2020 at 9:09 AM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, spring <[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

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 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky
<[email-masked]<mailto:[email-masked]>>
*Date: *Sunday, March 1, 2020 at 8:32 AM
*To: *Robert Raszuk <[email-masked]<mailto:[email-masked]>>
*Cc: *"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, spring <[email-masked]<mailto:[email-masked]>>, "Joel
M. Halpern" <[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
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 <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]><mailto:[email-masked]%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 <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]><mailto:[email-masked]%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
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
     --------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 1 Mar 2020 16:29:02 +0100

Hi Zafar,

I think I am also missing something here. Let me ask few questions

Q1 -  I am talking describing the case of in-situ Node A to Node B
unidirection telemetry stream where assume nodes A & B are within given
administrative domain. How would B know that SRH was removed somewhere in
the middle ? Note - node A is never part of any reception of the probe
packets.

Q2 - Basic ping - Let's assume that src A is a host outside of SP and that
it wants to run ping or traceroute through the domain or even further. As
ingress node encapsulates the packets (hopefully this will be configured
such ICMP gets the same encap as TCP or UDP) how nodes within SR path till
the very end of the path will be able to send responses back A ?

Do you count on ingress node (encapsulation src address) doing the proxy
NAT function in the slow path ? Or is the assumption here that SRv6 does
not propagate TTL and what happens within the domain is invisible for the
external party ?

Thx,
R.

On Sun, Mar 1, 2020 at 3:34 PM Zafar Ali (zali) <zali=
[email-masked]> wrote:

> 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.
>
> *From: *"Joel M. Halpern" <[email-masked]>
> *Date: *Sunday, March 1, 2020 at 9:09 AM
> *To: *"Zafar Ali (zali)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, spring <[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 1 Mar 2020 15:19:44 -0500

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 <https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-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) <
[email-masked]> wrote:

> Got it.
> Thanks for your clarification of your point.
>
> Jingrong
>
> -----Original Message-----
> From: 神明達哉 [mailto:[email-masked]]
> Sent: Saturday, February 29, 2020 9:28 AM
> 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
>
> "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.
>
> 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
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Mon, 2 Mar 2020 00:59:01 +0000

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----[PE1----P2----P3----PE4]----CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the packet arriving P2 will be:
(SA=PE1, DA=P2<End>) (SL=2, PE4<End.DT4>, P3<End.X>, P2<End>)  (customer-packet)

Then, the packet arriving P3 will be:
(SA=PE1, DA=P3<End.X>) (SL=1, PE4<End.DT4>, P3<End.X>, P2<End>)  (customer-packet)

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

In PSP mode, the packet will be sent to PE4 like this:
(SA=PE1, DA=PE4<End.DT4>) (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: VM----TOR----Spine----Superspine----[PE1----P2----P3----PE4]----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:[email-masked]]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: [email-masked]; Bob Hinden <[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

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.

4.21.1<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.  PSP: Penultimate Segment Pop of the SRH

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) <[email-masked]<mailto:[email-masked]>> wrote:
Got it.
Thanks for your clarification of your point.

Jingrong

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

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

Email: [email-masked]<mailto:[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 2 Mar 2020 15:20:20 -0800

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

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 2 Mar 2020 23:51:59 -0500

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.

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) <
[email-masked]> 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:
>
> 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:
> VM----TOR----Spine----Superspine----[PE1----P2----P3----PE4]----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 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:[email-masked]]
> *Sent:* Monday, March 2, 2020 4:20 AM
> *To:* Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* [email-masked]; Bob Hinden <[email-masked]>; [email-masked];
> 神明達哉 <[email-masked]>
> *Subject:* Re: Suggest some text //RE: [spring] Request to close the LC
> 4.21.1
> <https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-07#section-4.21.1>.
> 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.
>
>
>
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 3 Mar 2020 06:34:40 +0000

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

Sent: Tuesday, March 3, 2020 12:52 PM

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.

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

PSP disabled (USP)

Thanks

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> 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:

Thanks
Jingrong

From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, March 2, 2020 4:20 AM
To: Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Bob Hinden <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 神明達哉 <[email-masked]<mailto:[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

Hi Jingrong,

Am I missing something?

Kind Regards

Gyan

Jingrong

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 3 Mar 2020 15:18:06 +0000

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

Hi Gyan,

Thanks
Jingrong

Hi Jingrong

PSP mode

PSP disabled (USP)

Thanks

Gyan

Suppose:

Thanks
Jingrong

Hi Jingrong,

Am I missing something?

Kind Regards

Gyan

Jingrong

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

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Mar 2020 11:25:45 -0500

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

> On Mar 3, 2020, at 1:34 AM, Xiejingrong (Jingrong) <[email-masked]>
> wrote:
>
> Hi Gyan,
> 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:
> *From:* Gyan Mishra [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Tuesday, March 3, 2020 12:52 PM
> 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
> 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
>
> [email-masked]

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 4 Mar 2020 15:16:17 +0800

Please use the text in the latest version as the start piont to generate the proper and acceptable text. Version 07 is too old.

Again to speed the standard process, I suggest the flavor part be removed from the srv6-network-programming doc. Since flavor is optional to srv6, we can disscuss it in a separate doc as an optional enhancement feature to SRv6.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: Gyan Mishra
Date: 2020-03-03 12:51
To: Xiejingrong (Jingrong)
CC: [email-masked]; [email-masked]; Bob Hinden; 神明達哉
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 

4.21.1.  PSP: Penultimate Segment Pop of the SRH

PSP mode

PSP disabled (USP)

Thanks 

Gyan

On Sun, Mar 1, 2020 at 7:59 PM Xiejingrong (Jingrong) <[email-masked]> 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:

 

Thanks
Jingrong

Hi Jingrong,

 

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.

 
 
Am I missing something?
 
Kind Regards 
 
Gyan
 
On Fri, Feb 28, 2020 at 9:14 PM Xiejingrong (Jingrong) <[email-masked]> wrote:
Got it.
Thanks for your clarification of your point. 

Jingrong

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 4 Mar 2020 12:17:07 +0000

Dear Jinmei-san,

Inline PC1.

Thanks,

Pablo.

-----Original Message-----

From: ipv6 <[email-masked]> on behalf of 神明達哉 <[email-masked]>

Date: Tuesday, 3 March 2020 at 00:21

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bob Hinden <[email-masked]>

    expected to work?

    - at S1, since SL != 0,

      decrease SL to 1,

PC1: Correct

    - at S2, since SL != 0,

      decrease SL to 0

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

    follows?

      (A, 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.

Many thanks,

Pablo.

    --

    JINMEI, Tatuya

    [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Wed, 4 Mar 2020 15:45:00 -0800

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

> 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

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

>> 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 SRH". (I notice network-programming-12 is already
  pretty close to this)

- Perhaps change the pseudo code as follows
  S11.1   If (Segments Left == 1) { /* meaning this is a penultimate node */
  S11.2      Update IPv6 DA with Segment List[0]
  S12.3.     Update the Next Header field in the preceding header to the
             Next Header value of the SRH
  S12.4.     Decrease the IPv6 header Payload Length by the Hdr Ext Len
             value of the SRH
  S12.5.     Remove the SRH from the IPv6 extension header chain
  S12.6.     Go to S15
  S12.7.  }

- Clarify it's an update to RFC8200, e.g. as follows:

    This behavior formally updates Section 4 of [RFC8200], which does
    not allow deleting an extension header until the packet arrives at
    the destination.  While the literal text of RFC8200 could read as
    if the deletion were allowed for an intermediate node specified in
    a routing header, this document takes a safer and tighter
    interpretation as described in [the expected draft by Ron here]
    and updates it.

    The update is believed to be sufficiently safe and worthwhile:
    [Justifications here: why we need PSP; explain it doesn't break
    PMTUD; add considerations on AH, etc]

Like Brian's proposed text, whether such an update is acceptable is a
different question.  But it's at least a fair game to me.  I'd
seriously consider the justifications, and, depending on its details,
it's quite possible that it's something I can support.

(Whether we really need such a hack as PSP may also be a question, as
some others have questioned.  It seems cleaner to me if we could avoid
the hack in the first place, but I guess I don't have enough knowledge
to judge how badly it is needed and whether there's really no
"cleaner" alternative, so I wouldn't comment on it here).

--
JINMEI, Tatuya

---

From: John Scudder <[email-masked]>
Date: Thu, 5 Mar 2020 00:21:25 +0000

Thanks for writing this.

> On Mar 4, 2020, at 6:45 PM, 神明達哉 <[email-masked]> wrote:
[...]
> - 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

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 5 Mar 2020 04:08:28 +0000

Hi Jinmei,

Please check inline below.

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of ????
Sent: 05 March 2020 05:15
To: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Hinden <[email-masked]>; Robert Raszuk <[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

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

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

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

IPv6 pakcet]

IPv6 pakcet]

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

[KT] There is no technical problem being stated here. The logic is not cryptic - please consider the hint from Pablo above i.e. to look at the processing as whole. If the pseudocode is complicated for you to consume, then please do refer to the recent text update that make things crystal clear : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1

   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node and does not happen at any Transit Node.

And then

   This behavior does not contravene Section 4 of [RFC8200]<https://tools.ietf.org/html/rfc8200#section-4> because the

[KT] Again, this is not a technical point. It arises out of our disagreement on RFC8200 text.

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

[KT] There is no case for doing this. Again it is the same disagreement on RFC8200 text.

  pretty close to this)

[KT] What is there in the draft already is a much better text IMHO.

             value of the SRH

  S12.6.     Go to S15

  S12.7.  }

[KT] Please look at the processing pseudocode for a SID behavior and the PSP (as well as other non-PSP) flavors as a whole. At the end, any implementer is free to code and implement the logic in their own way as long as the behaviour and result is consistent.

    and updates it.

[KT] I don’t need to repeat why not required …

[KT] These are covered already. Can you please re-check https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1

Like Brian's proposed text, whether such an update is acceptable is a different question.  But it's at least a fair game to me.  I'd seriously consider the justifications, and, depending on its details, it's quite possible that it's something I can support.

[KT] Thanks for your review and feedback. I can only hope to have been able to help clarify and look forward to your support.

Thanks,

Ketan

(Whether we really need such a hack as PSP may also be a question, as some others have questioned.  It seems cleaner to me if we could avoid the hack in the first place, but I guess I don't have enough knowledge to judge how badly it is needed and whether there's really no "cleaner" alternative, so I wouldn't comment on it here).

--

JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Mar 2020 11:32:30 +1300

> 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:
> "Pablo Camarillo (pcamaril)" <pcamaril=[email-masked] <mailto:pcamaril=[email-masked]>> wrote:
> 
>  
> 
>> Inline PC1.
> 
>  
> 
> */[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:
> 
>> 
> 
> */[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./*
> 
>  
> 
> */[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/
> 
>  
> 
> */[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/CmT-8nSZs8O8i9N9dD8gHd6uHAo/ */(and the links provided by Martin on his previous email on that same thread)/*
> 
>  
> 
> */[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”./*
> 
>  
> 
> */[KT] There is no technical problem being stated here. The logic is not cryptic – please consider the hint from Pablo above i.e. to look at the processing as whole. If the pseudocode is complicated for you to consume, then please do refer to the recent text update that make things crystal clear : /*https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1*//*
> 
> */ /*
> 
> */ /*
> */And then/*
> */ /*
>    This behavior does not contravene Section 4 of [RFC8200] <https://tools.ietf.org/html/rfc8200#section-4> because the
> 
> */ /*
> */ /*
> */[KT] Again, this is not a technical point. It arises out of our disagreement on RFC8200 text./*
> 
>  
> 
> */[KT] There is no case for doing this. Again it is the same disagreement on RFC8200 text./*
> 
>  
> 
> */[KT] What is there in the draft already is a much better text IMHO./*
> 
>  
> 
> */[KT] Please look at the processing pseudocode for a SID behavior and the PSP (as well as other non-PSP) flavors as a whole. At the end, any implementer is free to code and implement the logic in their own way as long as the behaviour and result is consistent./*
> 
>  
> 
> */[KT] I don’t need to repeat why not required …/*
> 
>  
> 
> */[KT] These are covered already. Can you please re-check /*https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-12#section-4.16.1
> 
>  
> 
> */[KT] Thanks for your review and feedback. I can only hope to have been able to help clarify and look forward to your support./*
> 
> */ /*
> 
> */Thanks,/*
> 
> */Ketan/*
> 
>  
>

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 Mar 2020 13:48:47 -0800

At Thu, 5 Mar 2020 04:08:28 +0000,

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

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Mar 2020 23:37:37 +0100

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 6 Mar 2020 18:21:06 -0800

At Fri, 6 Mar 2020 23:37:37 +0100,

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

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

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Mar 2020 12:13:23 +0100

> won't; then I'll respect that.  Sometimes we just have to agree to

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.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Mar 2020 14:47:12 -0700

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

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

> why some authors may be actually resisting to take that path - just to keep

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.

> 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