Re: draft-zzhang-intarea-generic-delivery-functions

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