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

[Toerless Eckert <[e-mail]>]

Thanks, Jeff, inline.

On Tue, Feb 23, 2021 at 02:01:11PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> "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 just reads that way though.

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.

Nice.

One of my thoughts on the very same topic is that we should have
just build IPv6 with variable length addresses so thart we could have
added BIER semantics to a subtree of a larger address length space in the
same way as we managed to add IP Multicast semantics to existing IPv4
(and later IPv6) but just luckily because the IP Multicast semantic
allowed to rely on 32 bit long multicast addresses, whereas BIER
isn't even (IMHO) very happy with only 128 bit.

Of course, the benefit if we had BIER inside of IP would be huge because
like IP multicast it would jus be there, leaking through existing APIs
(like IP Multicast did initially), putting a lot more effort on all
communities to make the new, added semantic work - as opposed to
(if i may sound depressed) continue to ignore it like what i think happens
in many dependencies (API etc.) for BIER.

Simply being able to reuse existing forwarding plan functions that
have maybe been defined for IPv6 is just IMHO a second best approach
to actually having a more extensible network layer in the first place.

And IP did survive IP Multicast. IMHO building a superset of IPv6
wih additional address semantics that could also support BIER or
MPLS addresses would not kill IPv6 as it exists today either.

Sorry for the rant...

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

I certainly would like to see a lot of the thoughts around all of this
to be reflected by more of the community coming together and thinking
how to build these things for better long-term benefit. In comparison:
We managed to show enough solid archicture and impleemntation
functionality for BIER to move it from experimental to standard
after how many years ? 4 ? I think for any of the changes we're talking
here, that are meant to span multiple nework protocols, i really would love
to see a long experimental time frame in which research or other
experimental network collect experience and hopfully improve and integrate
the stuff better. 

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

You're not saying why you don't think existing IPv6 services should move to GDF,
but i would assume you want to avoid unnecessary churn. But there is also unnecessary
churn to keep to parallel solutions for the same thing alive.

Of course there is always a migration isue, but unless we develop stragies
for those better, we're dead in the water evolving the value propositions of this
industry anyhow. A simple one of course is "accept old, generate new" or the like.

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

To me, the big elephant in he room is that IETF work is loosing relevance in many
markets compared to IEEE, because IP routing is just replaced by ethernet switching,
and it could become as bad as IP routing only happening at any form of administrative
or bolicy border. So it should be in the interest of the IETF to figure out what
it should do about that (if people agree this is happening). I for once think that
decoupling as many forwarding plane functions that IETF can offer from "IP routing"
and making them applicable for any forwarding protocol could be a big part of this.
But i do obviously fear that IEEE might have more to offer for IP routing.

But yeah. Reusing technologies across SDO this way would be very new, and control
has often been a driving force in SDO decisions, and this is unexplored territory
(sharing).

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

Whenever i have a customer packet entering a PE getting encapsulated into th SP transport
(MPLS, SRv6), i would today have to figure out what services header to add to that
encap.  With that services heder reuseable across protocols i could duplicate+filter the
CE header. Thats obvious. But if th services heder becomes larger (think a lot more iOAM
or DetNet stuff), i may not want to duplicate but just use the one existing header. Just
figure out how to build the packet header chain to ensure that on the "decap side" it
ges put back.

Remember how MPLS for steering is also a lot more lightweight than classical encap-tunnels.
Likewise, these approaches could make services other than steering be similarily more
lightweight.

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

Not sure if "generic" is noble ;-) Its great if it ambitious. Its not great
if the goals are not as ambitious as the name implies ;-)

Cheers
    Toerless

> Zzh> Thanks!
> Zzh> Jeffrey
> 
> Cheers
>     Toerless
> 
> Juniper Business Use Only

-- 
---
[e-mail]