Re: [spring] SRv6 packets carrying multiple instances of the SRH

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Bruno,

Thank you for the hint.
For the current version -06 given the large amount of editorial changes in seemed difficult to send all the changes to the list.

For the purpose of this thread:
The best option seems to leave RFC8200 speak by itself and remove the sentence. This option got consensus with those who participated in the thread.

Thanks,
Pablo.

From: "[e-mail]" <[e-mail]>
Date: Monday, 9 December 2019 at 17:17
To: "Pablo Camarillo (pcamaril)" <[e-mail]>
Cc: Ron Bonica <[e-mail]>, SPRING WG <[e-mail]>, 6man Chairs <[e-mail]>
Subject: RE: SRv6 packets carrying multiple instances of the SRH

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:[e-mail]] 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 <[e-mail]>
Date: Sunday, 24 November 2019 at 01:28
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, SPRING WG <[e-mail]>, 6man Chairs <[e-mail]>
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.