Robert, Actually this was thoroughly discussed (mainly with Stefano I think) and these texts in draft-ietf-6man-segment-routing-header-06 were carefully designed to be compatible with both RFC2460 and RFC2460bis: Section 2.3.1: > The outer header with the SRH is no different from any other > tunneling encapsulation mechanism and allows a network operator to > implement traffic engineering mechanisms so to efficiently steer > traffic across his infrastructure. Section 5.1: > A Source SR Node can be any node originating an IPv6 packet with its > IPv6 and Segment Routing Headers. 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. I suppose we need expert review of the routing header itself, but for me there is simply no issue about compatibility with 2460(bis). (draft-voyer-6man-extension-header-insertion is a quite different conversation and we should not confuse the two. That would be FUD.) Regards Brian On 01/04/2017 06:56, Robert Raszuk wrote: > Even if we treat encapsulation in new IPv6 header as only an option ? > > Thx > R. > > > > On Mar 31, 2017 12:46, "Suresh Krishnan" <suresh.krishnan@xxxxxxxxxxxx> > wrote: > >> Hi Robert, >> >> On Mar 31, 2017, at 12:01 PM, Robert Raszuk <robert@xxxxxxxxxx> 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 >> >> >