The MPLS WG Archive

[Ben Abarbanel <Benjamin.Abarbanel@adn.alcatel.com>]

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

"Abes, Andi" wrote:

> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>

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