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

[Robert Raszuk <[e-mail]>]

Michael,

Right on the spot.

SRv6 is a first serious consideration why number of enterprise networks
would benefit from and could consider IPv6 rollout.

Otherwise all discussions so far end up with "no need" as all services are
available with zoo of different protocols over v4 and amount of v4
addresses owned by given company are of no concern of depletion any time
soon.

Best,
R.

On Mar 30, 2017 11:54, "Ackermann, Michael" <[e-mail]> wrote:

This is something I tried to say at the mic today, but I was too late.
If we put potentially valuable use cases into the bucket of "Exceptions",
this becomes yet another excuse to delay or avoid adoption of IPv6 by the
very large percentage of Enterprises who have yet to do so (and have no
serious plans) today.

I am hopeful that work in the IETF will provide features and hence
motivation for us sadly delinquent Enterprises to begin actually using
IPv6.    I am concerned that perception of solutions being "Exceptions" or
non standard, will cause consternation (warranted or not) and avoidance.


-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Suresh Krishnan
Sent: Thursday, March 30, 2017 9:30 AM
To: Leddy, John <[e-mail]>
Cc: [e-mail]; 6man WG <[e-mail]>;
[e-mail]
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

Hi John,
  Thanks for chiming in. I recognize that you might have use cases that
might be better off with header insertion but I think they should be
handled as and when they come up for consideration (e.g. in the SRv6
discussions). Holding up this document is not going to help in any way in
reinterpreting what RFC2460 intended. My suggestion for proponents of safe
header insertion to write up how it is expected to work and have the
discussion then.

Thanks
Suresh

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



The information contained in this communication is highly confidential and
is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you are
hereby notified that any viewing, copying, disclosure or distribution of
this information is prohibited. Please notify the sender, by electronic
mail or telephone, of any unintended receipt and delete the original
message without making any copies.

 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and Blue
Shield Association.