Hi Pablo,
Ø I will change that sentence in the next revision of the draft. Thank you for actively engaging on the resolutions of the WGLC comments, and for updating the draft accordingly. Appreciated. (especially on your first day coming back from holydays, with tens of email in the backlog) That been said, if you already know in what way you will change that sentence, I feel that it would be even better to state in your email reply your proposed change. That would allow the change to be agreed upon/refined even before the next draft revision. Thank you, --Bruno From: spring [mailto:[email protected]] On Behalf Of Pablo Camarillo (pcamaril) Sent: Monday, December 9, 2019 4:15 PM To: Ron Bonica; SPRING WG; 6man Chairs Subject: Re: [spring] SRv6 packets carrying multiple instances of the SRH Ron, As agreed during the IETF106 meeting I will change that sentence in the next revision of the draft. Thank you, Pablo. From: Ron Bonica <[email protected]> Date: Sunday, 24 November 2019 at 01:28 To: "Pablo Camarillo (pcamaril)" <[email protected]>, SPRING WG <[email protected]>, 6man Chairs <[email protected]> Subject: SRv6 packets carrying multiple instances of the SRH Pablo, During the SPRING WG meeting at IETF 106, we discussed the following text from Section 2 of draft-ietf-spring-srv6-network-programming-05: “SRH: Segment Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be present multiple times inside each packet.” This text contradicts the following text from RFC 8200: “Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header).” The following redaction reconciles the contradiction by remaining silent and allowing RFC 8200 to speak for itself: OLD> SRH: Segment Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be present multiple times inside each packet <OLD NEW> SRH: Segment Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. <NEW During the meeting, you mentioned the need to import some text from RFC 8200. If you feel the need to do that, the follow redaction imports all relevant text without bias: OLD> SRH: Segment Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. We assume that the SRH may be present multiple times inside each packet. <OLD NEW> SRH: Segment Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. As per Section 4.1 of RFC 8200, the Routing header (e.g., SRH) should occur at most one inside a packet. However, IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the recommendations found in Section 4.1 of RFC 8200 until and unless subsequent specifications revise those recommendation. <NEW Happy Holidays, Ron Juniper Business Use Only _________________________________________________________________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/spring
