Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>

[stefano previdi <[e-mail]>]

Hi Ron,


> On Apr 5, 2018, at 8:44 PM, Ron Bonica <[e-mail]> wrote:
> 
> Hi Stephano,
> 
> I'm glad you asked this question. RFC 8200 and draft-ietf-6man-segment-routing-header define Segments Left (SL) differently. The difference is a bit subtle and took me a few readings to catch.
> 
> RFC 8200 defines SL as follows:
> 
> "8-bit unsigned integer.  Number of route  segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination."
> 
> Therefore, if a packet arrives at a node and the following conditions are true, the node skips over the Routing Extension Header and processes the next header:
> 
> - The packets IPv6 Destination address is local to the node
> - The packet contains a Routing Extension Header
> - The SL value in the Routing Extension Header is equal to 0


the same behavior happens into a SR node.


> In RFC 2460, Routing Extension Type RH0 was compliant with this behavior. The description of RHO (RFC 2460, Section 4.4) explains how RH0 used to process SL, offering pseudocode and an example. Between the publication of RFC 2460 and RFC 8200, RHO was deprecated for other reasons. Therefore, the detailed example of SL handling was not brought forward into RFC 8200.


ok. RFC2460 being obsoleted and RFC8200 not having any description, it looks to me the only reference where the processing of the routing header is explained is the SRH draft. 

Obviously, the processing of the routing header and the processing of an unrecognized routing header type didn’t change.


> But even though this example was not brought forward into RFC 8200, it explains why RFC 8200 says:
> 
> "If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as  follows:
> 
> If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header.
> 
> If Segments Left is non-zero, the node must discard the packet and  send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type."
> 
> This is because an SL value of 0 means that the Routing Extension Header has already been completely processed by upstream nodes. Even if the node recognized the Routing Type, it still would skip over it.


correct. And note that by 
    “processing of the routing header” 
we intend 
    “update the DA with the next segment on the list”.

So, when SL==0 there’s nothing that needs to be processed in the header.


> By contrast, draft-ietf-6man-segment-routing header defines the Segments Left as follows:
> 
> "Defined in [RFC8200], it contains the index, in the Segment List, of the next segment to inspect.  Segments Left  is decremented at each segment.
> 
> Therefore, if a packet arrives at a node and the following conditions are true, the node processes Segment[0]:
> 
> - The packets IPv6 Destination address is local to the node
> - The packet contains a Routing Extension Header
> - The SL value in the Routing Extension Header is equal to 0


SL==0 doesn’t imply any processing of the SRH. Both END and END.x functions starts with “IF SegmentsLeft > 0”.


> This is different from the behavior described in RFC 8200 and 2460. It also raises two questions:
> 
> - If the node doesn't recognize SRH, is it safe to ignore the SRH, as recommended by RFC 8200


rfc8200 applies here. 


> - If the node does recognize SRH and the segment requires decapsulation and forwarding, are Extension Headers that follow SRH (e.g. Fragment, Destination Options) ignored?


rfc8200 applies here.

Thanks.
s.


> 
>                                                             Ron
> 
> 
>> -----Original Message-----
>> From: stefano previdi <[e-mail]>
>> Sent: Thursday, April 5, 2018 5:30 AM
>> To: Ron Bonica <[e-mail]>
>> Cc: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
>> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
>> header-11.txt>
>> 
>> Ron,
>> 
>> on comment 5:
>> 
>> 
>>> Section 2.2 SRv6 Segment (Comment 5)
>>> 
>>> According to RFC 8200:
>>> 
>>> "If, while processing a received packet, a node encounters a Routing
>> header with an unrecognized Routing Type value, the required behavior of
>> the node depends on the value of the Segments Left field, as follows:
>>> 
>>> -  If Segments Left is zero, the node must ignore the Routing header and
>> proceed to process the next header in the packet, whose type is identified
>> by the Next Header field in the Routing header.
>>> 
>>> -  If Segments Left is non-zero, the node must discard the packet and send
>> an ICMP Parameter Problem, Code 0, message to the packet's Source
>> Address, pointing to the unrecognized Routing Type."
>>> 
>>> This is safe, so long as all Routing Extension Types use SL == 0  to indicate
>> that the Routing Extension Header has been completely processed. It is may
>> not be safe when SL == 0 means that one more segment needs to be
>> processed.
>>> 
>>> In the SRH, SL == 0 indicates that one more segment needs to be
>> processed.
>> 
>> 
>> sorry, I don’t understand.
>> 
>> Can you point me the text in draft-ietf-6man-segment-routing-header that
>> states that ?
>> 
>> If it’s the case it should be obviously corrected.
>> 
>> SL==0 means the packet is traveling within the last segment.
>> 
>> draft-ietf-6man-segment-routing-header does not modify the semantic of
>> “Segments Left”.
>> 
>> It does modify the way segment list is encoded (that’s one of the reason it’s
>> a different routing header type) but not the "Segments Left” field semantic.
>> 
>> s.
>> 
>> 
>> 
>> 
>