On 01/04/2017 07:14, Robert Raszuk wrote:
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
Sure, any tunnel needs a decapsulator as well as an encapsulator. That's
not news, so what is the problem here? I assume you'd decapsulate in
the last hop router. I don't claim to understand segment routing, so
I can't actually understand the above text. But the text elsewhere
is clear enough that either the original source or the encapsulator
builds the routing header, and that's all we need to know for
2460(bis) compatibility. So why are we still discussing?
Brian
(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