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@xxxxxxxxxxx> 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.bryant@xxxxxxxxx> 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@xxxxxxxx
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
------------------------------------------------------------ --------