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

[Bob Hinden <[e-mail]>]

My take on this is that it is fine to show text from RFC8200 without any change (with a reference), but it is not good to try to summarize that text (for example, as in “We assume….”).

Thanks,
Bob


> On Nov 23, 2019, at 4:28 PM, Ron Bonica <[e-mail]> wrote:
> 
> 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