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(_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