<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The problem of MPLS, however, is that, it must also be flow driven,<br>
because detailed route information at the destination is necessary<br>
to prepare nested labels at the source, which costs a lot and should<br>
be attempted only for detected flows.<br></blockquote><div><br></div><div>MPLS is not flow driven. I sent some mail about it but perhaps it bounced. </div><div><br></div><div>MPLS LDP or L3VPNs was NEVER flow driven. </div><div><br></div><div>Since day one till today it was and still is purely destination based. </div><div><br></div><div>Transport is using LSP to egress PE (dst IP). </div><div><br></div><div>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. </div><div><br></div><div>Thx,<br>R.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
 > there is the argument that switching MPLS is faster than IP; when the<br>
 > pressure points i see are more at routing (BGP/LDP/RSVP/whatever),<br>
 > recovery, and convergence.<br>
<br>
Routing table at IPv4 backbone today needs at most 16M entries to be<br>
looked up by simple SRAM, which is as fast as MPLS look up, which is<br>
one of a reason why we should obsolete IPv6.<br>
<br>
Though resource reserved flows need their own routing table entries,<br>
they should be charged proportional to duration of the reservation,<br>
which can scale to afford the cost to have the entries.<br>
<br>
                                                Masataka Ohta<br>
<br>
</blockquote></div></div>