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:
> 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 PSP operation only takes place at a penultimate SR Segment
>
> Endpoint Node and does not happen at any Transit Node.
>
>
>
> 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.
>
>
>
> 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>*
>
> *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>*
>
>
>
> Additionally, please find some replies inline to the comments from Bruno
> [PC2].
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> -----Original Message-----
>
> From: "bruno.decra...@orange.com" <bruno.decra...@orange.com>
>
> Date: Tuesday, 3 March 2020 at 15:49
>
> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, Brian E Carpenter
> <brian.e.carpen...@gmail.com>
>
> Cc: "Darren Dukes (ddukes)" <ddukes=40cisco....@dmarc.ietf.org>, 6man WG
> <i...@ietf.org>, SPRING WG List <spring@ietf.org>
>
> Subject: RE: PSP and a logical application of RFC8200
>
>
>
> 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.
>
>
>
> 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)
>
> 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.
>
>
>
> 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
>
>
>
> > From: ipv6 [mailto:ipv6-boun...@ietf.org] 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)
>
> 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.
>
>
>
> 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.)
>
>
>
>
>
>
>
> Or whatever text indicating the issue.
>
>
>
> Regards,
>
> --Bruno
>
>
>
> >
>
> > Regards
>
> > Brian
>
> > >
>
> > > Many thanks,
>
> > > Pablo.
>
> > >
>
> > > -----Original Message-----
>
> > > From: ipv6 <ipv6-boun...@ietf.org> on behalf of Brian E Carpenter
> <brian.e.carpen...@gmail.com>
>
> > > Date: Monday, 2 March 2020 at 20:34
>
> > > To: "Darren Dukes (ddukes)" <ddukes=40cisco....@dmarc.ietf.org>, 6man
> WG <i...@ietf.org>, SPRING WG List <spring@ietf.org>
>
> > > 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
>
> > > > i...@ietf.org
>
> > > > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>
> > > >
> --------------------------------------------------------------------
>
> > > >
>
> > >
>
> > >
> --------------------------------------------------------------------
>
> > > IETF IPv6 working group mailing list
>
> > > i...@ietf.org
>
> > > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>
> > >
> --------------------------------------------------------------------
>
> > >
>
> > >
>
> >
>
> > --------------------------------------------------------------------
>
> > IETF IPv6 working group mailing list
>
> > i...@ietf.org
>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
> > --------------------------------------------------------------------
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>
>
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
