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
On 05-Mar-20 01:25, Pablo Camarillo (pcamaril) wrote:
> 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 <brian.e.carpen...@gmail.com>
> Date: Tuesday, 3 March 2020 at 22:17
> To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>,
> "bruno.decra...@orange.com" <bruno.decra...@orange.com>
> Cc: "Darren Dukes (ddukes)" <ddu...@cisco.com>, 6man WG <i...@ietf.org>,
> SPRING WG List <spring@ietf.org>
> Subject: Re: PSP and a logical application of RFC8200
>
> 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
