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

Mon Jun 22 07:06:24 UTC 2020

But MPLS can be made flow driven (it can be made whatever the policy dictates), for instance DSCP driven…

adam

From: NANOG <nanog-bounces+adamv0025=netconsultings.com at nanog.org> On Behalf Of Robert Raszuk
Sent: Saturday, June 20, 2020 4:13 PM
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Cc: North American Network Operators' Group <nanog at nanog.org>
Subject: Re: why am i in this handbasket? (was Devil's Advocate - Segment Routing, Why?)

The problem of MPLS, however, is that, it must also be flow driven,
because detailed route information at the destination is necessary
to prepare nested labels at the source, which costs a lot and should
be attempted only for detected flows.

MPLS is not flow driven. I sent some mail about it but perhaps it bounced. 

MPLS LDP or L3VPNs was NEVER flow driven. 

Since day one till today it was and still is purely destination based. 

Transport is using LSP to egress PE (dst IP). 

L3VPNs are using either per dst prefix, or per CE or per VRF labels. No implementation does anything upon "flow detection" - to prepare any nested labels. Even in FIBs all information is preprogrammed in hierarchical fashion well before any flow packet arrives. 

Thx,
R.

 > there is the argument that switching MPLS is faster than IP; when the
 > pressure points i see are more at routing (BGP/LDP/RSVP/whatever),
 > recovery, and convergence.

Routing table at IPv4 backbone today needs at most 16M entries to be
looked up by simple SRAM, which is as fast as MPLS look up, which is
one of a reason why we should obsolete IPv6.

Though resource reserved flows need their own routing table entries,
they should be charged proportional to duration of the reservation,
which can scale to afford the cost to have the entries.

                                                Masataka Ohta

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200622/190c95b6/attachment.html>