why am i in this handbasket? (was Devil's Advocate - Segment Routing, Why?)

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Mon Jun 22 07:43:15 UTC 2020


> Masataka Ohta
> Sent: Sunday, June 21, 2020 1:37 PM
> 
> > Whether you do it manually or use a label distribution protocol, FEC's
> > are pre-computed ahead of time.
> >
> > What am I missing?
> 
> If all the link-wise (or, worse, host-wise) information of possible
destinations
> is distributed in advance to all the possible sources, it is not
hierarchical but
> flat (host) routing, which scales poorly.
> 
> Right?
> 
On the Internet yes in controlled environments no, as in these environments
the set of possible destinations is well scoped. 

Take an MPLS enabled DC for instance, every VM does need to talk to only a
small subset of all the VMs hosted in a DC. 
Hence each VM gets flow transport labels programmed via centralized
end-to-end flow controllers on a need to know bases (not everything to
everyone).
(E.g. dear vm1 this is how you get your EF/BE flows via load-balancer and FW
to backend VMs in your local pod, this is how you get via local pod fw to
internet gw, etc..., done)
Now that you have these neat "pipes" all over the place connecting VMs it's
easy for the switching fabric controller to shuffle elephant and mice flows
around in order to avoid any link saturation. 

And now imagine a bit further doing the same as above but with CPEs on a
Service Provider network... yep, no PEs acting as chokepoints for MPLS label
switch paths to flow assignment, needing massive FIBs and even bigger, just
dumb MPLS switch fabric, all the "hard-work" is offloaded to centralized
controllers (and CPEs for label stack imposition) -but only on a need to
know bases (not everything to everyone).

Now in both cases you're free to choose to what extent should the MPLS
switch fabric be involved with the end-to-end flows by imposing hierarchies
to the MPLS stack.  

In light of the above, does it suck to have just 20bits of MPLS label space?
Absolutely.
 
Adam

    




More information about the NANOG mailing list