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

Hi,

> On 30 Mar 2017, at 03:59, Leddy, John <John_Leddy(_at_)comcast(_dot_)com> 
> wrote:
>
> > On Mar 14, 2017, at 9:47 PM, Suresh Krishnan 
> > <suresh(_dot_)krishnan(_at_)ericsson(_dot_)com> 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,
Understood, but why do you require direct insertion rather than using encap as 
per 2460bis?

Tim

> John Leddy
> Comcast