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]). 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],
[I-D.dawra-bgp-srv6-vpn] and [I-D.bashandy-isis-srv6-extensions].On Mar 31, 2017 13:08, "Suresh Krishnan" <suresh.krishnan@xxxxxxxxxxxx> wrote:
Hi Robert,On Mar 31, 2017, at 12:56 PM, Robert Raszuk <robert@xxxxxxxxxx> 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 that would be contrary to this text in RFC2460bis.ThanksSureshP.S.: I am assuming you are using the word option to mean a choice and not an IPv6 option. If not, please clarify.ThxR.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.ThanksSuresh