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

[Ron Bonica <[e-mail]>]

Darren,

Thanks! I am feeling much better than yesterday!

I think that we are getting to the bottom of that subtle difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing-header.

In RFC 8200, a node receives a packet that satisfies the following conditions:

- IPv6 Destination Address is local to the node
- Packet contains a Routing Extension Header
- Routing Extension Header SL value is equal to 0

The correct behavior is to skip over the Routing Extension Header and process the next header. The Routing Extension Header has already been completely processed by upstream nodes. In fact it doesn't even matter if the node recognizes the Routing Extension Type. The node will skip over it, regardless of its type.

In draft-ietf-6man-segment-routing-header, a node receives a packet that satisfies the same conditions.

The required behavior is to process the instruction in Segment List [0]. When I has done this, the Routing Extension Header will be completely processed. The node better recognize the SRH, because skipping the instruction might be dangerous.

The difference between SL in RFC 8200 and SL in draft-ietf-6man-segment-routing is subtle, but significant.

                                                                         Ron

> -----Original Message-----
> From: Darren Dukes (ddukes) <[e-mail]>
> Sent: Thursday, April 5, 2018 3:39 PM
> To: Ron Bonica <[e-mail]>
> Cc: stefano previdi <[e-mail]>; IPv6 List <[e-mail]>; Bob
> Hinden <[e-mail]>
> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-
> header-11.txt>
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=WmPR-
> DmQkiyFhWqdRohhiCg015eX46xGJmHofETXsM0&s=7bmAIXTGfcwjaJMMnP
> w7zYDgOQmzyIQ66CYofnt72Dw&e=
> 
> > --------------------------------------------------------------------
> 
>