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