Re: Limited Domains:

[Jiayihao <[e-mail]>]

I figure Mark Smith and Stewart Bryant hit the point.

This discussion is around the topic of "how could we achieve a new function if it is not covered by existing protocols".
Usually, there are 2 potential directions:
1. design a brand new protocol to fulfil the function. This new protocol can either be A) transformed from/to an existing protocol as a parallel/replaced one; B) encapsulate an existing protocol as an overlay.
2. design an extension for an existing protocol which reserve code point for future use as forwarding capability.

Document draft-filsfils-6man-structured-flow-label seems heading to a third direction as follow:
3. rewrite an existing protocol and mandatorily re-scope the protocol to be used in a limited domain

Stewart give a good reason why direction 3 should not be adopted.
My understanding here is: limited domain is not the excuse for any potential compatibility risks.

This remind me of the draft draft-smith-6man-in-flight-eh-insertion-harmful. This draft argue that In-Flight IPv6 Extension Header Insertion Considered Harmful because:
a) it violate RFC 8200
b) Costly Troubleshooting
c) ... ...
Although there many reasons such action is considered to be harmful, I reckon that reason b) only is strong enough already.

So draft-filsfils-6man-structured-flow-label is facing similar situation. If a code field is designed to be unchanged during it's forwarding lifecycle, the in-flight modifying (targeted for limited domain use) can always leak to outside Internet by chance. Such leakage could be a disaster for troubleshooting.

In addition, IPv6 128 addressing space may be a good and the only space to place new semantic except the extension header as Toerless mentioned, but all that addressing should be encoded within ULA fc00::/7 so that all design is constricted in a limited domain. However, I am not sure it can solve the scenario/problem in draft-filsfils-6man-structured-flow-label.

Thanks,
Yihao