The MPLS WG Archive

[Curtis Villamizar <curtis@avici.com>]

In message <38E28A7D.134BD731@fore.com>, David Charlap writes:
> "Abes, Andi" wrote:
> > 
> > Now my question is, why can't this model be followed under traffic
> > engineering conditions ?
> > 
> > Router Ax will learn from BGP what is the local AS egress point
> > towards D.  It will then consult the IGP-TE database and construct an
> > explicit route to that router, and tuck at the end a loose route to D.
> > It is then the egress router's job to "fix" the explicit route such
> > that the ERO now reflects the route to the next AS. The Ingress router
> > in transit AS's will do just the same - it will change the ERO (that
> > now contains 2 entries - one that indicates the current AS, and one
> > for the end destination) such that it contains a strict route accross
> > the new current AS and a loose route to the destination.  and so on
> > till the destination AS.
> 
> Actually, you should be able to do better than this (if RSVP-TE is used,
> anyway.  I don't know about CR-LDP)
> 
> According to draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, the explicit route
> object supports an AS-number subobject.
> 
> So, the ingress router should be able to get (from BGP) an explicit
> route of AS numbers from source to destination.  It can make an ERO that
> begins with the hops through the local net, and ends with the list of AS
> numbers for ASes beyond the local network.
> 
> Upon arrival in the next AS, the router there can replace the
> AS-subobject for itself with a per-hop route to the next AS on the list.
> 
> And so on.
> 
> So the ingress router can't specify the complete path, but it can
> specify which ASes it wants the path to go through on its way to the
> destination AS.
> 
> > Each BGP router can consult what ever TE constraits it has to deceid
> > what BGP next hop to use, but it will only construct a strict route
> > through the local AS and append a loose route to the final
> > destination.
> 
> It could do this also.
> 
> A loose route from the last local router to the final destination could
> work, but that means the actual path chosen is left completely up to the
> routers in other ASes.
> 
> A route that explicitly lists ASes may be better.  There is still some
> looseness, since each AS will determine its own route through, but you
> can keep the route going through the ASes you want.
> 
> The first way would definitely be easier to implement, but the second
> way might also be desirable under certain circumstances.
> 
> -- David


This would work on a smaller scale such as a single provider.  AFAIK
none of the current implementations from major router vendors support
AS in the ERO mostly because no one actually building an ISP backbone
wants it.

End to end LSPs across AS boundaries just isn't going to happen.  Each
ingress might have to originate 10,000s of LSPs.  In the core there
could potentially be 70,000 * 70,000 LSPs.  Even with these LSPs
inside of aggregated traffic engineered LSPs and backbone LSRs that
could handle that amount of state, the 20 bit label number space could
be exceeded.  End-to-end LSPs is true connection oriented QoS routing
which doesn't work.  It isn't what MPLS was designed for and for good
reason.

End-to-end QoS across providers is still acheivable but the solution
won't involve end-to-end LSPs.

Curtis