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

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Ron, I’m glad you’re feeling a bit better.

Your analysis of SL is not correct.  Both 2460, 8200 and SRH say the same thing for SL==0 but you’re getting stuck on what 'the index, in the Segment List, of the next segment to inspect’ means.

Using the same example from 2460 section 4.4 but modifying for the Segment List[] defined in SRH.

 As the packet travels from S to I1:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
   As the packet travels from I1 to I2:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
  As the packet travels from I2 to I3:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
   As the packet travels from I3 to D:
        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Segment List[0] = D
                                            Segment List[1] = I3
                                            Segment List[2] = I2
                                            Segment List[3] = I1
SL always points to the "next segment to inspect", that segment is also in the Destination Address. 
For example between I1 and I2, the next segment to inspect is I2, the SL==2 which is the index in Segment List of I2.  
The same is true for I3 to D where SL==0, the next segment to inspect is D, but the SRH need not be processed because SL==0.

Section 4.1 of SRH shows this quite clearly in its description of the END function where SL is decremented then the Segment at SRH[SL] is used to update the Destination Address.
1. IF SegmentsLeft > 0 THEN
2.    decrement SL
3.    update the IPv6 DA with SRH[SL]
4.    FIB lookup on updated DA
5.    forward accordingly to the matched entry
8.  ELSE
7.    drop the packet


I hope this clears up the confusion.

Darren

> On Apr 5, 2018, at 2: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
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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
> - 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?
> 
>                                                             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.
>> 
>> 
>> 
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------