Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi Suresh,

The fact that encapsulation in new v6 header is optional to me is clearly
stated in section 4.1 of that document:

 By default, a local SID bound to the End function does not allow
      the decapsulation of an outer header.  As a consequence, an End
      SID cannot be the last SID of an SRH and cannot be the DA of a
      packet without SRH.

   o  If the decapsulation is desired, then another function must be
      bound to the SID (e.g., End.DX6 defined in
      [I-D.filsfils-spring-srv6-network-programming
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.filsfils-spring-srv6-network-programming>]).
This prevents
      any unintentional decapsulation by the segment endpoint node.  The
      details of the advertisement of a SID in the control plane are
      outside the scope of this document (e.g.,
      [I-D.previdi-idr-segment-routing-te-policy
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.previdi-idr-segment-routing-te-policy>],
      [I-D.dawra-bgp-srv6-vpn
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.dawra-bgp-srv6-vpn>]
and [I-D.bashandy-isis-srv6-extensions
<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06#ref-I-D.bashandy-isis-srv6-extensions>].


On Mar 31, 2017 13:08, "Suresh Krishnan" 
<suresh(_dot_)krishnan(_at_)ericsson(_dot_)com>
wrote:

> Hi Robert,
>
> On Mar 31, 2017, at 12:56 PM, Robert Raszuk <robert(_at_)raszuk(_dot_)net> 
> wrote:
>
> Even if we treat encapsulation in new IPv6 header as only an option ?
>
>
> There are two options listed in the draft with the “either” clause quoted
> below. Both of them are compliant. In fact, in my not so careful reading, I
> do not see any text in draft-ietf-6man-segment-routing-header-06
> <https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06> that
> would be contrary to this text in RFC2460bis.
>
> Thanks
> Suresh
>
> P.S.: I am assuming you are using the word option to mean a choice and not
> an IPv6 option. If not, please clarify.
>
>
> Thx
> R.
>
>
>
> On Mar 31, 2017 12:46, "Suresh Krishnan" 
> <suresh(_dot_)krishnan(_at_)ericsson(_dot_)com>
> wrote:
>
> > Hi Robert,
> >
> > On Mar 31, 2017, at 12:01 PM, Robert Raszuk <robert(_at_)raszuk(_dot_)net> 
> > wrote:
> >
> > Hi Suresh,
> >
> > As you requested one of many quotes from the draft which your
> > clarification to 2460bis directly contradicts with:
> >
> > This include either:
> >
> >       A host originating an IPv6 packet.
> >
> >       *An SR domain ingress router encapsulating a received IPv6 packet
> >       into an outer IPv6 header followed by an SRH.*
> >
> >
> > Excellent. Thanks for pointing out the exact text. I can confirm that
> > this text  *is compliant* with the RFC2460bis text.
> >
> > Thanks
> > Suresh