Subject: [spring] PSP and a logical application of RFC8200

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 2 Mar 2020 14:52:54 +0000

What follows has been made clear on the list for a while,
I am re-stating it.

The draft-ietf-spring-srv6-network-programming PSP behavior
strictly follows the letter of RFC 8200.

     RFC8200 section 4 says:

     Extension headers (except for the Hop-by-Hop Options header) are not
     processed, inserted, or deleted by any node along a packet's delivery
     path, until the packet reaches the node (or each of the set of nodes,
     in the case of multicast) identified in the Destination Address field
     of the IPv6 header.

The processing, insertion and deletion restrictions only apply
“until the packet reaches the node identified in the Destination
Address field of the IPv6 header”.

At the penuptimate segment of the segment list, the endpoint IS
“the node identified in the Destination Address field of the IPv6
header” and hence the PSP operation programmed by the source SR
node strictly follows the letter of RFC 8200.

Thanks,
  Darren

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 12:35:32 -0300

On 2/3/20 11:52, Darren Dukes (ddukes) wrote:
> *processed, inserted, or deleted* by any node along a packet's delivery
>       path, until the packet reaches *the node* (or each of the set of 
> nodes,
>       in the case of multicast) *identified in the Destination Address 
> field*
> * of the IPv6 header.*

That is certainly not the intended behavior of RFC8200.

In fact, you may see that Appendix B says:

    o  Clarified that extension headers (except for the Hop-by-Hop
       Options header) are not processed, inserted, or deleted by any
       node along a packet's delivery path.

and the routing headers (Section 4.4) are specified as:

    The Routing header is used by an IPv6 source to list one or more
    intermediate nodes to be "visited" on the way to a packet's
    destination.

As it may be obvious, teh wording in RFC8200 is indeed prone to 
confusion, and hence should be fixed (this is not the only bug in the 
EH-processing part of RFC8200, as noted by Brian, myself, and others).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Mar 2020 08:33:54 +1300

Darren,

Regardless of whether you accept Fernando's comment about the intention of RFC 8200, there is also the fact that the description of the PSP flavor cheats by considering the packet to have
 (Segments Left == 0 and Destination Address == the PSP node's address).
In fact that is *never* the state of the packet on the wire, which is either
 (Segments Left == 1 and Destination Address == the PSP node's address)
or
 (Segments Left == 0 and Destination Address == the final node's address)

OK, maybe it's not cheating, maybe it's only a side effect of the pseudocode, but the fact is that the test "S14.1.   If (Segments Left == 0) {" in section 4.16.1 is very confusing because it's applied to a packet that is half way through processing of the routing header (Segments Left has been updated, but Destination Address has not been updated). This makes it very unclear how the spec is claiming to interpret RFC 8200.

Regards
   Brian Carpenter

On 03-Mar-20 03:52, Darren Dukes (ddukes) wrote:
>      path, until the packet reaches *the node* (or each of the set of nodes,
>      in the case of multicast) *identified in the Destination Address field*
>     * of the IPv6 header.*
>   
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 2 Mar 2020 20:02:54 +0000

Brian,

The PSP pseudocode is presented as a modification to the End pseudocode starting at line S14 of such.
Please go through the PSP pseudocode in conjunction with the End pseudocode (Section 4.1). 
You will see that the ingress state of the packet is (Segments Left == 1 and Destination Address == the PSP node's address).

Many thanks,
Pablo.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Monday, 2 March 2020 at 20:34
To: "Darren Dukes (ddukes)" <ddukes=[email-masked]>, 6man WG <[email-masked]>, SPRING WG List <[email-masked]>
Subject: Re: PSP and a logical application of RFC8200

    Darren,

    
    Regards
       Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 17:45:22 -0300

> You will see that the ingress state of the packet is (Segments Left == 1 and Destination Address == the PSP node's address).

You are also changing the semantics of routing headers: if you prcessed 
the RH when Segments Left == N, you don't get to decrement SegmentsLeft 
and process the routing header again.

So, again, you should be updating RFC8200, and probably even the 
segment-routing-header I-D.

Thanks,

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 2 Mar 2020 21:09:54 +0000

Fernando, you are wrong.  SRH processing only occurs at the segment endpoint, there is no "processing the routing header again”.

Darren

> On Mar 2, 2020, at 3:45 PM, Fernando Gont <[email-masked]> wrote:
> 
> You are also changing the semantics of routing headers: if you prcessed the RH when Segments Left == N, you don't get to decrement SegmentsLeft and process the routing header again.
> 
> So, again, you should be updating RFC8200, and probably even the segment-routing-header I-D.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 18:15:37 -0300

> Fernando, you are wrong.  SRH processing only occurs at the segment endpoint, there is no "processing the routing header again”.

Does the fact that PSP stands for "Penultimate Segment Pop" ring any bells?

PSP specifies en-route removal of IPv6 extension headers. This violated 
RFC8200 that prohibits such behaviour, and also violates the 
specification of routing headers.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Mar 2020 12:21:47 +1300

> You will see that the ingress state of the packet is (Segments Left == 1 and Destination Address == the PSP node's address).

Exactly my point. With SL == 1, you are not at the ultimate destination, so according to what I'll call "Fernando's reading" of RFC8200, you are not entitled to delete the header. That is the point that IMHO needs to be stated explicitly in the draft. You are using "Darren's reading" of RFC8200.

I really think you need to say so explicitly. Something like:

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

This will not change the argument, but it will make the issue clear so that we (the IETF) can decide whether to accept it or not. And that is orthogonal to whether RFC 8200 is wrong.

Regards
    Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 21:46:25 -0300

> is the address of the node executing the PSP behavior.

A node that does PSP essentially processes the SR header twice. How is 
that compliant with draft-ietf-6man-segment-routing-header itself?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Mar 2020 21:58:28 -0300

> Exactly my point. With SL == 1, you are not at the ultimate destination, so according to what I'll call "Fernando's reading" of RFC8200, you are not entitled to delete the header. That is the point…

FWIW, I don't think there are two ways to read the spec.

Either en-route insertion/deletion is supported, or it isn't.

If it is, RFC8200 should have an explanation of how PMTUD and error 
reporting works. And it doesn't have one.

In that light, I'm curious how folks can state that eh insertion/removal 
is allowed.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: <[email-masked]>
Date: Tue, 3 Mar 2020 14:48:25 +0000

Pablo, 

My reading is that Brian is asking for a clarification of the text, not a change in the behavior.
In general, I think that clarification is good and that Brian's request is reasonable.

Related to Brian's comment, but on top of them, I have further points on this section 4.16.1:

1)
" S14.1.   If (Segments Left == 0) {"

Although I agree that reading the whole pseudo code (split across the whole document) is self-descriptive, there is the opportunity for people to misread and confuse "Segment Left in the received packet" with "Updated Segment Left". I'd like to avoid misunderstanding similar to the ones in RFC 8200. Could you propose something? E.g.  :s/ Segments Left/ Updated Segments Left.

2)
As a possible change to try to address Brian's comment
OLD:
   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node and does not happen at any Transit Node.

NEW:
   The PSP operation only takes place at a penultimate SR Segment
   Endpoint Node (where Segment Left == 1) and does not happen at any Transit Node.

More inline

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> 

3)
Given that there is even heated discussions on the text/wording in RFC8200, I'm afraid that whatever text be inserted in draft-ietf-spring-srv6-network-programming would trigger controversy and that in the end be asked to be removed. 
However, I'm also in favor of making the issue clear.

Brian, I would personally prefer to stick as close as possible to the text from RFC 8200, plus that we make clear that we are not changing it but only referring to. So I would propose something along the following:

	As indicated in RFC 8200 section 4, extension headers [...] are not [to be]
	   processed, inserted, or deleted by any node along a packet's delivery
	   path, until the packet reaches the node [...] identified in the Destination Address field
	   of the IPv6 header.
   
	The PSP behavior defined in this section specifies that, the node identified in the Destination Address field of the IPv6 header (as restricted by RFC 8200 section 4), when Segment Left is received as 1 and when specifically instructed by the source node, removes the SRH header.

As a reminder, the text from RFC 8200 is 
"   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

I believe that my proposed edits are clearly indicated by "[]" and helps the reader to focus on the relevant text. However, I'm also fine with copy pasting the text verbatim from RFC 8200.

4) There is an interesting comment on the 6MAN WG https://mailarchive.ietf.org/arch/msg/ipv6/AJzOX97mUeHjEcDSIgpqUw8gNk0/
Although not sent in the SPRING WG, and not mentioning to this document, I think that I should be taken into account.
More specifically
" IMHO, any specification breaking AH (e.g., by modifying the NextHeader in transport mode) should clearly note that it 'breaks AH' or constraints its use; but, this is still acceptable for an IETF standard specification IMHO to 'break AH'." 

I'd propose:
OLD:
   As a reminder, [I-D.ietf-6man-segment-routing-header] defines in
   section 5 the SR Deployment Model within the SR Domain [RFC8402].
   Within this framework, the Authentication Header (AH) is not used to
   secure the SRH as described in Section 7.5 of
   [I-D.ietf-6man-segment-routing-header].

NEW:
Removing the SRH requires modifying the Next Header field which is defined as Immutable by RFC 4302.  As indicated in [I-D.ietf-6man-segment-routing-header], the use of RH with AH by an SR source node, and processing at a SR
   segment endpoint node is not defined in this document.  Future documents may define use of SRH with AH and its processing. Such future document needs to take into account that the use of PSP requires the Next Header field to not be Immutable.

Or whatever text indicating the issue.

Regards,
--Bruno

> >     > node strictly follows the letter of RFC 8200.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 3 Mar 2020 20:37:34 +0000

Brian, Bruno,

Many thanks for your comments.

Based on the feedback I would propose to add Brian's proposed text as is into the draft.

4.16.1.  PSP: Penultimate Segment Pop of the SRH

   SR Segment Endpoint Nodes advertise the SIDs instantiated on them via

   control plane protocols as described in Section 8.  Different

   behavior ids are allocated for flavored and unflavored SIDs [Table 4]

   such that an SR Source Node can identify PSP-flavored SIDs as such.

   The PSP flavor is specifically used by the Source SR Node when it

   needs to instruct the penultimate SR Segment Endpoint Node listed in

   the SRH to remove the SRH from the IPv6 header.

   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.

   The SRH processing of the End, End.X and End.T behaviors are

   modified: after the instruction "S14.  Update IPv6 DA with Segment

   List[Segments Left]" is executed, the following instructions must be

   executed as well:

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

   The usage of PSP does not increase the MTU of the IPv6 packet and

   hence does not have any impact on the PMTU discovery mechanism.

<NEW>

This behavior does not contravene section 4 of [RFC8200]

</NEW>

Additionally, please find some replies inline to the comments from Bruno [PC2].

Thanks,

Pablo.

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

From: "[email-masked]" <[email-masked]>

Date: Tuesday, 3 March 2020 at 15:49

To: "Pablo Camarillo (pcamaril)" <[email-masked]>, Brian E Carpenter <[email-masked]>

Cc: "Darren Dukes (ddukes)" <ddukes=[email-masked]>, 6man WG <[email-masked]>, SPRING WG List <[email-masked]>

Subject: RE: PSP and a logical application of RFC8200

    Pablo,

    1)

PC2: In previous versions of this document we used the term “updated SL”. As part of the WGLC we changed this text in December to “Segments Left” since it is the name of the field defined in the SRH. While I do find the “Updated Segments Left” easier to understand, the working group feedback wasn’t the same in December. Hence I would tend to keep it as is. But no strong preference on my side really.

    2)

    OLD:

    NEW:

PC2: Given the new text added, and given that we already have this, do we need it?

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.

    More inline

    3)

                   of the IPv6 header.

       of the IPv6 header."

    More specifically

    I'd propose:

    OLD:

    NEW:

PC2: Given the following text from RFC4301, and the quote above from the SRH, do we really need this?
   IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

    Regards,

    --Bruno

    Thank you.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Mar 2020 10:17:26 +1300

Right, let's get the text clarified. Whether or not the IETF (not just these two WGs, which plainly cannot agree) accepts or refuses this interpretation of RFC 8200 is a separate question.

Regards
   Brian

On 04-Mar-20 09:37, Pablo Camarillo (pcamaril) wrote:
> *<NEW>*
> *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.*
> 
> *</NEW>*
> 
>  
> 
> *A penultimate SR Segment Endpoint Node*is one that, as part
> 
>    Destination Address and *decrements Segments Left value from one to*
> 
> *   zero.*
> 
>  
> 
>     More inline
> 
>    
> 
>     > From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> 
>     >
> 
>     > On 03-Mar-20 09:02, Pablo Camarillo (pcamaril) wrote:
> 
>     > > Brian,
> 
>     > >
> 
>     > > The PSP pseudocode is presented as a modification to the End pseudocode starting at line S14 of such.
> 
>     > > Please go through the PSP pseudocode in conjunction with the End pseudocode (Section 4.1).
> 
>     > > You will see that the ingress state of the packet is (Segments Left == 1 and Destination Address == the PSP node's address).
> 
>     >
> 
>     > Exactly my point. With SL == 1, you are not at the ultimate destination, so according to what I'll call "Fernando's reading" of RFC8200, you are not entitled to delete the header. That is the point that IMHO needs to be stated explicitly in the draft. You are using "Darren's reading" of RFC8200.
> 
>     >
> 
>     > I really think you need to say so explicitly. Something like:
> 
>     >
> 
>     > Note: 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.
> 
>     >
> 
>     > This will not change the argument, but it will make the issue clear so that we (the IETF) can decide whether to accept it or not. And that is orthogonal to whether RFC 8200 is wrong.
> 
>    
> 
>     3)
> 
>     >
>     > Regards
>         > Brian
>     > >
>     > > Many thanks,
>     > > Pablo.
>     > >
>     > > -----Original Message-----
> 
>     > > From: ipv6 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
> 
>     > > Date: Monday, 2 March 2020 at 20:34
> 
>     > > To: "Darren Dukes (ddukes)" <ddukes=[email-masked]>, 6man WG <[email-masked]>, SPRING WG List <[email-masked]>
> 
>     > > Subject: Re: PSP and a logical application of RFC8200
> 
>     > >
> 
>     > >     Darren,
> 
>     > >    
> 
>     > >     Regardless of whether you accept Fernando's comment about the intention of RFC 8200, there is also the fact that the description of the PSP flavor cheats by considering the packet to have
> 
>     > >      (Segments Left == 0 and Destination Address == the PSP node's address).
> 
>     > >     In fact that is *never* the state of the packet on the wire, which is either
> 
>     > >      (Segments Left == 1 and Destination Address == the PSP node's address)
> 
>     > >     or
> 
>     > >      (Segments Left == 0 and Destination Address == the final node's address)
> 
>     > >    
> 
>     > >     OK, maybe it's not cheating, maybe it's only a side effect of the pseudocode, but the fact is that the test "S14.1.   If (Segments Left == 0) {" in section 4.16.1 is very confusing because it's applied to a packet that is half way through processing of the routing header (Segments Left has been updated, but Destination Address has not been updated). This makes it very unclear how the spec is claiming to interpret RFC 8200.
> 
>     > >    
> 
>     > >     Regards
> 
>     > >        Brian Carpenter
> 
>     > >    
> 
>     > >     On 03-Mar-20 03:52, Darren Dukes (ddukes) wrote:
> 
>     > >     > What follows has been made clear on the list for a while,
> 
>     > >     > I am re-stating it.
> 
>     > >     >
> 
>     > >     > The draft-ietf-spring-srv6-network-programming PSP behavior
> 
>     > >     > strictly follows the letter of RFC 8200.
> 
>     > >     > 
> 
>     > >     >      RFC8200 section 4 says:
> 
>     > >     > 
> 
>     > >     >      Extension headers (except for the Hop-by-Hop Options header) are not
> 
>     > >     >      *processed, inserted, or deleted* by any node along a packet's delivery
> 
>     > >     >      path, until the packet reaches *the node* (or each of the set of nodes,
> 
>     > >     >      in the case of multicast) *identified in the Destination Address field*
> 
>     > >     >     * of the IPv6 header.*
> 
>     > >     >  
> 
>     > >     >
> 
>     > >     > The processing, insertion and deletion restrictions only apply
> 
>     > >     > “until the packet reaches the node identified in the Destination
> 
>     > >     > Address field of the IPv6 header”.
> 
>     > >     > 
> 
>     > >     > At the penuptimate segment of the segment list, the endpoint IS
> 
>     > >     > “the node identified in the Destination Address field of the IPv6
> 
>     > >     > header” and hence the PSP operation programmed by the source SR
> 
>     > >     > node strictly follows the letter of RFC 8200.
> 
>     > >     >
> 
>     > >     >
> 
>     > >     > Thanks,
> 
>     > >     >   Darren
> 
>     > >     >
> 
>     > >     > --------------------------------------------------------------------
> 
>     > >     > IETF IPv6 working group mailing list
> 
>     > >     > [email-masked]
> 
>     > >     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     > >     > --------------------------------------------------------------------
> 
>     > >     >
> 
>     > >    
> 
>     > >     --------------------------------------------------------------------
> 
>     > >     IETF IPv6 working group mailing list
> 
>     > >     [email-masked]
> 
>     > >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     > >     --------------------------------------------------------------------
> 
>     > >    
> 
>     > >
> 
>     >
> 
>     > --------------------------------------------------------------------
> 
>     > IETF IPv6 working group mailing list
> 
>     > [email-masked]
> 
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
>     > --------------------------------------------------------------------
> 
>    
>

---

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

Brian, Bruno,

I have just made this change to the draft.
This is the only change for revision 12.

Many thanks,
Pablo.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Tuesday, 3 March 2020 at 22:17
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Darren Dukes (ddukes)" <[email-masked]>, 6man WG <[email-masked]>, SPRING WG List <[email-masked]>
Subject: Re: PSP and a logical application of RFC8200

    Regards
       Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Mar 2020 09:47:32 +1300

Hi,

I think this version makes the issue very clear (and orthogonal to the
question whether RFC8200 says what it was intended to say).

May I humbly suggest a *new* WGLC on this version?

Regards
   Brian Carpenter