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

[Ron Bonica <[e-mail]>]

Stephano,

This entire conversation is muddied by that fact that a segment identifier is a 128-bit entity that represents either:

- An IPv6 interface (i.e., an attachment to a network link, as defined in [RFC 4291])
- A locator:instruction:parameter structure

When the Destination Address / Segment Identifier represents a locator:instruction:parameter structure:

- the locator (high-order bits) represent a node to which the packet should be delivered
- the instruction (low-order bits) represents how the packet should be processed once it arrives at that node
- the parameter (lowest-order bits)  constrains the instruction

As with any Routing Extension Header, we swap segment identifiers in and out of the Destination Address field of the basic IPv6 header.

So, when the packet arrives at a locator and SL==0, it is questionable as to whether the SRH has been completely processed. At very least, the node needs to execute the instruction that is encoded within the IP Destination Address and Segment List[0]. The node may even need to examine the SRH to execute that instruction.

I am pretty sure that the required procedures can be specified unambiguously. But since we are playing a little fast-and-loose with the semantics of an IP Destination Address, our specification needs to be extremely well crafted.

                                                       Ron

> -----Original Message-----
> From: stefano previdi <[e-mail]>
> Sent: Monday, April 9, 2018 4:09 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>
> 
> 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.
> >>
> >>
> >>
> >>
> >