Re: [Pals] [Int-area] draft-zzhang-intarea-generic-delivery-functions

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Toerless,

Thank you for your comments.
Please see zzh> below.

-----Original Message-----
From: Toerless Eckert <[e-mail]>
Sent: Monday, February 22, 2021 7:30 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]; mpls <[e-mail]>; [e-mail]; Kireeti Kompella <[e-mail]>; Ron Bonica <[e-mail]>
Subject: Re: [Int-area] draft-zzhang-intarea-generic-delivery-functions

[External Email. Be cautious of content]


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 ;-)

Zzh> To the contrary, this did not start as an MPLS fragmentation point problem (though almost everything starts with something small and the key is to make the solution generic w/o making it unmanageable). It actually started in BIER - we realize that some functions at IP layer could be abstracted out from IP and apply at BIER layer directly; then we realize that the same can be applied to mpls, and even Ethernet (if IEEE do care about it). That's on the dimension of different lower layers.
Zzh> Now IOAM comes into the picture; while we have not come to consensus yet, but it seems that IOAM could also use the GDF header. That's on the dimension of different functions that can be supported.
Zzh> Yet another example is a *by-product* of this. Believe it or not, we did not do this so to be able to tell the payload type after MPLS, but Stewart pointed it out this may give a backdoor way of indicating MPLS payload type. If MPLS WG concludes that is good, it can certainly be standardized, but it is really not our hidden agenda 😊

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.

Zzh> The above mentioned some examples. More use cases could come up, and more importantly, unless it is proven that this is not generic, then why can't it be called so 😊

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".

Zzh> For existing IP functions that could be abstracted out to GDF, it certainly does not make sense to switching them to GDF, but it is good to be able to apply them to other layers; for future functions that may be applicable to both IPv6 and other layers, if they are done via GDF, it would be preferred, and more importantly the "next header" in IPv6 could be a GDFH.

- 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.

Zzh> Agree. It has already been discussed to start talking to IEEE folks; of course, if this can't even take off in IETF, then it probably won't go well in IEEE.

  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.

Zzh> This is a very good point for start working with IEEE early; of course the precondition is that IETF itself is open to the proposal.

- 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.

Zzh> If you need the same *type of* functions done different layers (which likely would be at different nodes), different GDFHs (of the same type) would be put into different places of the headers chain.
Zzh> If you're referring to the *same function* done at different layers, and push up/down the *same header* whenever you push/pop of the encapsulations, I can't think of a concrete example now, but maybe it can be worked out.

- 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.

Zzh> For all the lessons we've learned, we can evaluate if they can be applied to the GDF. We can start with looking at the current GDFH proposals to see if addresses known problems that we want/need to address.

Without any intent to work on such broader strategy aspects, the use of the word
"generic" is IMHO inappropriate.

Zzh> Of course we want to consider all those broader strategy aspects and make it truely as generic as possible. I don't think we should be so hung up on the "generic" name. Can we start with this, and rename it down the road to something more appropriate if we conclude that it does not deserve the noble name?
Zzh> Thanks!
Zzh> Jeffrey

Cheers
    Toerless

Juniper Business Use Only