On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri <[email protected]> wrote: > Tom, > > >I think the terminology being used in the draft might be making this > seem complicated than it actually is. AFAICT, SRv6 traditional mode is > nothing more than IP in IP encapsulation, so the requirement of the underlay > is that it > >forwards IPv6 and intermediate nodes treat the traffic as > "normal IPv6 traffic". There is no segment routing involved, no extension > headers needed, and the only upgrade for the network is to support IPv6. > > I am not sure that is the case. Please re-read Section 5.1 (and 5.1.3) > " This 1-for-1 mapping is > replicated here to replace the GTP encaps with the SRv6 > encaps, while > not changing anything else." > Uma,
Right, there is where the terminology of the draft is confusing. SRv6 defines a routing extension header not an encapsulation protocol. "SRv6 encaps" here means IP packets (presumably either IPv4 or IPv6) are encapsulated in IPv6 using standard IP/IP encpasulation. Concurrent with that encapsulation, a segment routing header or other extension headers may be added to the outer IP header (this is consistent with RFC8200 requirement that only source nodes can set extension headers). So there is really no such thing as SRv6 encapsulation, and in the text above replacing SRv6 with IP-in-IP would be much clearer as to how the protocol works. Tom > -- > Uma C. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
