Subject: RE: MPLS routing accross AS boundaries

From: "Abes, Andi" <[email-masked]>
Date: Wed, 29 Mar 2000 17:28:00 -0500

Hi,
 
I'm probably out of my league here so please correct me.
 
One of the rules of BGP, and in general inter-domain routing protocols
is to advertise reachability to other AS's, while hiding as much as possible

the local AS's topology.
 
Such that when route Ax (AS A, route x) needs to send a packet to an address
D, the only thing it will learn from BGP is that there's a route to the
destination D, that travels through some AS's along the way. It will also
learn the egress router in his own AS that needs to get the packet.
How he needs to get to the egress router is a matter for an IGP to resolve.
 
Any of this correct ?
 
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.
 
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.
 
Please let me know if this makes some sense.

---

From: David Charlap <[email-masked]>
Date: Wed, 29 Mar 2000 17:58:05 -0500

"Abes, Andi" wrote:
> 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

---

From: Ben Abarbanel <[email-masked]>
Date: Wed, 29 Mar 2000 18:01:00 -0500

Perhaps maybe  the gentlemen was looking at the traffic engineering level from a
much higher view and
is considering a virtual tunnel that treats each AS as a node. The AS-Path
attribute in BGP route is  used
to define the AS path a route is propagated through. Maybe additional attribute
information can be piggybacked to each AS-PATH entry, which would allow for
traffic engineering steering of these tunnels. Maybe some sort of traffic
engineering modeling can be done at this higher plane?

I will agree that the current model of a strict tunnel formed between the
Ingress and Egress IBGP routers will take us from one end of the AS to the
other, then applying loose routes between ASs, then strict again within the
other transient ASs. This will work, but requires a more AS to AS traffic
engineering tuning. The overall path that is formed by a series of strict and
loose tunnels may not be optimal for traffic engineering
the entire Internet.

The example I mentioned above treats all the ASs as one entity and thereby
allows for a more global view of traffic engineering management.

Regards,
Ben

--
Remember
========
"Don't be afraid to try something new. Amateurs built the Arc, professionals
built Titanic"

---

From: "Phani Koganti" <[email-masked]>
Date: Wed, 29 Mar 2000 18:52:47 -0500

Yes i indeed was looking at traffic engineering across ASs from a very high level.
By propagating TE attributes along with AS_PATH for a BGP route,  another dimension
will be added to route selection across AS boundaries. This will find a optimised
path for the required QoS/Bandwidth from say AS x and AS y provided there are
multiple paths present. Surely when signalling a MPLS LSP the ingress LSR of each AS
specified will calculate a explicit route based on the constraints.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 30 Mar 2000 12:18:02 -0500

> way might also be desirable under certain circumstances.

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

---

From: "James R. Leu" <[email-masked]>
Date: Fri, 31 Mar 2000 15:03:37 -0600

My ideas within may be old, naive, or impractical.  If so, just say so and
I'll go back to lurking.

> > > Now my question is, why can't this model be followed under traffic

[snip]

> which doesn't work.  It isn't what MPLS was designed for and for good

I agree that true end to end LSPs across AS bounds will not scale on the
Internet.  BGP is a great example of why the piece by piece model is a
"good thing" (TM).

By using piece by piece LSPs with end to end label stacking (forming logical
end to end LSPs) we could achieve a good approximation of a true end to end
LSP.  A corollary to this would be that the more signalling you introduce to
this process, the closer the approximation.

Low level of signalling, low level of confidence
------------------------------------------------
Using existing BGP info each ingress node would form a deep label stack solely
on the existing BGP info.  The nodes in the path of course would have to
support this form of labeling, but this could be advertised via BGP as well.

High level of signalling, high level of confidence
--------------------------------------------------
Using a request oriented model in which each AS allocates a mapping across
peering links which are pushed on to intra AS LSPs resulting in relatively
shallow label stacks.  This would require an end to end signalling protocol.

Compromise
----------
A mix of these would be that via BGP each AS would advertise what levels of
CoS it will support across it's core.  The ingress node would then try to choose
a deep label stack that would carry it through AS's that support the correct
CoS.  This has the benefit of not requiring end to end signalling, but would
attempt to reach the level of confidence that the end to end signalling would
offer.

-- 
James R. Leu

---

From: Ben Abarbanel <[email-masked]>
Date: Fri, 31 Mar 2000 18:07:09 -0500

James:

  From my perspective, if you stack LSPs end to end from one AS to the next. You
will end
up with less than perfect path from one source to a destination many AS away. Once
you
forward into one LSP you are stuck because you have to pickup the best next LSP to
your
ultimate destination. This will lead to inaccurate routing and poor traffic
management as whole
in the Internet. I say we need a mechanism that has total picture view of the entire
Internet
at the source or Ingress router of the first LSP. Thereby, it could choose the right
LSP that
will be considered with all the others down the path to the destination. I have a
solution for
that with BGP.

Regards,
Ben

--
Remember
========
"Don't be afraid to try something new. Amateurs built the Arc, professionals built
Titanic"