ietf
[Top] [All Lists]

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

2017-03-17 12:07:18
All,

This is very interesting thread indeed.

I think header insertion at *any* network element be it host, router,
service chain device is highly desired. IPv6 deployments will be much more
successful if we clear any obstacles which otherwise prevent it from
delivering required by customers and operators functionality.

And I would state that this should be not only limited to one's own IGP or
BGP domain. It should be legal Internet wide.

Today Internet as a entire system lacks tools to accomplish path
engineering, fast connectivity restoration, p2mp delivery of content etc
... Some of those are possible with MPLS based tools however as we all know
MPLS has no NNI and does not really work across domains. Here we stand very
close to have a chance to fix it.

And if one would forbid by spec the header insertion performed by network
elements what's the alternative ... IPv6 in IPv6 encapsulation which may
suffer with even more overhead yet will still require IANA allocation of
SRH type as well as TLV codepoints as effectively encapsulating network
element will be acting as IPv6 sender.

Concluding I do hope that we can try to collectively make IPv6 protocol
flexible enough to satisfy customer and operator's requirements what in
turn will enrich and speed up IPv6 global adoption.

Kind regards,
Robert.


On Thu, Mar 16, 2017 at 1:40 PM, Leddy, John 
<John_Leddy(_at_)comcast(_dot_)com> wrote:

Thanks Stewart,

This really supports my point and hopefully not the intent or result of
the discussions here.

We are trying to work through the IETF process to come up with standards
and solutions that address real operational challenges faced in
deployments.  For operators, dealing with legacy and migrations are a big
challenge.

Wishing these issues away and as a result having non-standard
functionality in “middle boxes” that are ignored in the architecture is not
productive.  NATs are a way of life, dark space is being deployed by other
operators, “Cloud”/NFV/ServiceChaining are active areas; tunnels, tunnels
everywhere - PMTU is always an issue.  “Turtles and Tunnels all the way
down”.

We are very aggressively migrating to a V6 infrastructure, but there is a
large amount of old legacy systems/applications/services that need to be
addressed.  At the same time the allure of “Cloud” attracts systems that
should never be moved without being re-architected and the virtualization
environments fully supporting V6 (both Vendors and OpenSource) – but they
do move and vendors help make that possible.

Hopefully we can keep the discussions going and keep tools available until
we know we have solutions to deal all the activity happening outside a
clean end-to-end Architecture,

John



On 3/16/17, 6:44 AM, "Stewart Bryant" 
<stewart(_dot_)bryant(_at_)gmail(_dot_)com> wrote:

    > In another form, the answer to John is that there are no protocol
police,
    > so what consenting adults do inside their own networks simply isn't
an
    > issue that an Internet-wide spec can or should address.

    That is not quite true, the inability to gain an IANA allocated
    codepoint can make long
    term private deployments very difficult, either for the protocol
    squatting on a codepoint
    because they could not get one allocated, or to the deployment of a new
    protocol
    legitimately allocated a conflicting codepoint.

    - Stewart







--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>