Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

[Mark Townsley <[e-mail]>]

I think this is hitting on a very important point about protocol transition here, something that I think all of us should step back and consider from a very humble vantage point.

The transition from IPv4 to IPv6 has been hard, certainly much harder than I think the contributors to RFC2460 originally expected. We've had to go back after the fact to define and perfect things like NAT64 to sit at the boundary of IPv6-only networks, allowing communication between IPv6-only and IPv4-only endpoints by inserting and deleting IPv6 and IPv4 headers. 

The whole idea of an extension header is to extend the capabilities of IPv6. Extended functions naturally come with transition, and transition happens progressively. Inserting and deleting an extension header is analogous to a NAT64 function - not something we necessarily want, but something we have realized we need, to handle transition within the reality that wide spread flag days are impossible.

If I take IPv6 SR as an example of an extended IPv6 function, some endpoints will support IPv6 SR sooner than others. Some network domains will operate with IPv6 SR everywhere sooner than others. The ability to classify traffic and insert an SR header upon entry into an SR domain is important to transition, and is completely analogous to what, say, T-Mobile does with NAT64 and 464xlat.  

Suresh, I think this may be a tussle point (to refer to Dave Clark's presentation earlier this evening). 2460bis should not try to over-specify here. Instead, allow for a bit of flex while we truly get our heads around how to deploy and operate systems which use IPv6 extension headers.

- Mark




On Mar 29, 2017, at 9:59 PM, Leddy, John <[e-mail]> wrote:

>> On Mar 14, 2017, at 9:47 PM, Suresh Krishnan <[e-mail]> wrote:
>> 
>> NEW:
>> 
>> With one exception, extension headers are not examined, processed,
>> inserted, or deleted by any node along a packet's delivery path,
>> until the packet reaches the node (or each of the set of nodes, in
>> the case of multicast) identified in the Destination Address field of
>> the IPv6 header...
>> 
>> Please feel free to comment either privately or on list if you have any concerns with this resolution going forward.
> 
> 
> Suresh,
> 
> I still have concerns that we are eliminating a tool that may prove very helpful in migrations without understanding its value.
> 
> The Internet transition of IPV4 -> Dual Stack V4/V6 -> IPV6 Only; has been long, operationally complex and full of unexpected challenges.
> We are only now starting to make the transition from Dual Stack to IPV6 Only, there are still many unknowns on how to complete this migration.
> 
> As we contemplate finishing this major Network shift – We find ourselves in the early stages of another.
> 
> The transition from Physical to Virtual Infrastructure.  Again, the migration will be long, operationally complex and full of unexpected challenges.
> 
> In the old world with Servers running Applications in Physical locations designed for very predictable loads; using an encap/decap tunnel to emulate a physical circuit between locations has many attractive properties – but that is compared to actually ordering and provisioning real circuits between locations.
> 
> In the new world of dynamic resources spun up on demand in distributed environments across multiple providers, Applications having the Intelligence and State to bring up their own required connectivity is very natural.  This is where we are putting the majority of our efforts.  SRv6 enables very attractive solutions by Applications building their own headers.
> 
> The challenges come as we try to migrate and require these two infrastructures to Interoperate for a long time.
> Burdening the new Virtual world with Old, Static circuit paradigms is not optimal.
> Supplementing the legacy infrastructure with an assist function seems a reasonable solution.  (Ext Hdr insertion/deletion or encap/decap tunnels)
> 
> The preferred assist mechanism seems to be the one that allows the New World to operate in its final preferred state, sending and receiving packets with their own headers. (SRv6)
> But what does an Application in the new world due when it is attempting to communicate with an Application in the Old World?
> Shouldn’t it build an SRv6 header?  That would mean that the assist function would need to be the last SID in the Segment List and be capable of removing the SRH.
> Wouldn’t it make sense for the assist function to do the same thing in the reverse direction; an Old World Server talking to a New Virtual World Application?  Insert an SRH.
> 
> If this insert/delete of an SRH is prematurely prohibited;  What is a recommended solution to the Real World problem above.  Not use case, we are implementing.
> 
> Again; I’m worried we are eliminating a tool that may prove very helpful, preclude its use in future IETF work and shutdown a path for Innovation in Networking,
> 
> Thank you for asking and listening to my concerns,
> 
> John Leddy
> Comcast
> 
> 
> 
> 
> 
>