RE: WGLC - draft-ietf-spring-srv6-network-programming

[<[e-mail]>]

Fernando,

Thank you for spelling out your comment, plus on the WGLC thread.
More in-line

> Bruno,
> 
> On 5/12/19 12:15, [e-mail] wrote:
> [....]>
> > This email starts a two weeks Working Group Last Call on
> > draft-ietf-spring-srv6-network-programming [1].
> > 
> >  
> > 
> > Please read this document if you haven't read the most recent version,
> > and send your comments to the SPRING WG list, no later than December 20.
> > 
> >  
> > 
> > You may copy the 6MAN WG for IPv6 related comment, but consider not
> > duplicating emails on the 6MAN mailing list for the comments which are
> > only spring specifics.
> > 
> >  
> > 
> > If you are raising a point which you expect will be specifically debated
> > on the mailing list, consider using a specific email/thread for this point.
> > 
> > This may help avoiding that the thread become specific to this point and
> > that other points get forgotten (or that the thread get converted into
> > parallel independent discussions)
> 
> Penultimate Segment Popping describes/specifies the removal of a SRH at
> a place other than the final destination of the packet.
> 
> Such behavior violates RFC8200, which specifies:
> 
   > 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.
> 
> Note, of course, that the reference of "Destination Address" in RFC8200
> is clearly the final destination of the packet -- for instance, RFC8200

I hear and can understand your reading of RFC8200.
At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".
Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.
I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

> does not specify any routing header type, and hence the meaning is
> unambiguous (there's no destination other than the final destination of
> the packet).
> 
> This is of course in line with IPv6 being and end-to-end protocol, and
> crucial for other related mechanisms to work as expected (such as IPsec
> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.
> 
> So, in order to proceed with the document, there are multiple options
> forward:
> 
> 1) Just remove the corresponding text/behavior

That is indeed one option. But as of today, this is not my assumption.
 
> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
> re-encap)

SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.
 
> 3) Do the necessary standards work to update RFC8200, such that it
> allows this sort of behavior, and only ship the network-programming
> draft for publication when at least 6man has consensus to proceed on
> that path.

Not the preferred path as of today.
 
> P.S.: I will go through the document once again... but the same
> reasoning should be applied to any EH-insertion/removal at a place other
> than the source of the packet or its final destination.

It looks to me that SRH insertion and SRH removal are to be treated differently. The difference been that for SRH insertion, in general the node doing insertion is any node on the path hence not specifically a node ' identified in the Destination Address field of the IPv6 header." While for and End* PSP behavior, the node doing SRH removal is a node '' identified in the Destination Address field of the IPv6 header.". Or at minimum this seems a possible interpretation of RFC 8200.
In all cases, while this is sorted out, let's treat both as different.

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

_________________________________________________________________________________________________________________________

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.