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