Hi Jeff, *.
I am very supportive of i think what could be the spirit of this draft (and
similar
drafts that Stewart mentioned exist), but i am quite worried about some of the
current fundamentals:
This looks a lot like
"i have a point problem (MPLS fragmentation), but to sell it better, i will
give it a more
inclusive name, but i don't really care that much about the other 99%
opportunity/challenges".
(not that i am blaming you for trying, just wanting to point this out ;-)
Aka: before this type of draft can earn its ambitious name i think it needs to
support
a lot more use cases and include solutions for "generic" problems.
For example:
- If something claims to be "generic" but does not propose to apply it to what
is our
tier 1 protocol, IPv6, then its more like "generic for the leftover (non
IPv6)", and
we will continue to still have to provide (unnecessarily) multiple options to
do the
same thing. Aka: superceeding and replacing existing IPv6 extension options
would be
the most solid and important stake in the ground to claim "generic".
- If we want IEEE to use this, there needs to be a) more work on how to use it
with
ethernet,and b) a way to establish different code-point registries, so IEEE
could
define options for this header by themselves. At least IMHO to maximize the
opportunity
for IEEE to drive this forwrd.
I am saying this also because in my non-scientific opinion, the likelyhood
for better
QoS extension headers to be built are much better if we leave it up to IEEE
and then
inherit what they have done. Which could be helped by an extension header
that IEEE would
like to use and extend but that would also easily be able to be used with
MPLS and IP.
At least that's my somewhat frustrated opinion about IETFs progress on Qos
given
how we still think after 40 years "8 TOS bits are good enough forever", L4S
trying
to overload an ECN bit, and only MPLS having been able to partially catch up
in DetNet
with what TSN did in ethernet.
- We ultimately will have layers of header to which such a header could be
applied,
such as ethernet+mpls+ip, and quite frankly i think we need a way to be able
to have
such a header only once instead of replicating it three times, which is what
we typically
would do these days if we needed the processing at all three layers. Aka:
push up/down
the header whenever we push/pop one of the encapsulations. Just as one idea.
- Encoding and forwarding plane support requirements for future extensions.
Aka: i don't
want to see for any future extensions the typical never ending discussions
about what
would be an appropriate way to encode them so that all hardware can support
it. I think we
should have enough of that problem in the wake of SRH now in Spring. If we
want to call
something generic, it should define mandatory encoding rules to be supported
for any
future extensions. Of course, this doesn't say that any extension function
could be
supported by any hardware, but it gets us one step closer. FOr example by
codifying
a mandatory encoding for variable length / optional parameters.
Without any intent to work on such broader strategy aspects, the use of the word
"generic" is IMHO inappropriate.
Cheers
Toerless
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
