Subject: RE: MPLS routing accross AS boundaries

From: Atsushi Iwata <[email-masked]>
Date: Wed, 29 Mar 2000 23:09:42 +0900

Hi, all

The draft that peter mentioned is our following draft.

draft-fujita-ospf-te-summary-00.txt

This approach assumes a hierarchical QoS path computation that PNNI routing 
protocol does in the ATM world.

I would like to get any opinion or any suggestions (Pros and Cons) on this 
approach.

Regards,

At 08:36 00/03/29 -0500, Peter Ashwood-Smith wrote:

>Currently the MPLS working group has not addressed this subject in any 
>depth although there was a draft presented in the routing area group today 
>in Adelaide that started to talk about solutions.
>
>As far as I know there are basically two ways to attack this problem, or 
>at least two general flavors.
>
>piecewise source routing. In this approach you compute a gateway based on 
>the destination address and then do normal flat source routing to that 
>gateway. Go through the gateway and repeat. In other words you are doing 
>piecewise traffic engineering but letting the exterior gateway protocols 
>figure out which gateway you should be going to next. Obviously there are 
>problems with this approach since it puts everything though the same 
>gateway. I actually helped built a piecewise solution like this a while 
>ago. It has some good advantages in that local (at least local to an AS) 
>repair is natural to do as are local modification etc.
>
>hierarchical source routing. This is what ATM does, you compute a hop list 
>hierarchically against a hierarchical topology database etc. etc. I'm not 
>sure this approach is appropriate for the Internet due to the massive size 
>of the problem but I'm really not an ATM hierarchical routing guy.
>
>I would hope that the MPLS working group or the Traffic Engineering 
>working group can start looking at these issues, possibly with some 
>simulations of the different approaches against a set of real AS 
>topologies. Some of the PNNI architects and BGP architects are active 
>members  of the MPLS working group so you can be sure that it will cause 
>some heated debate ... should be extremely interesting and challenging.
>
>Cheers,
>
>Peter
>
>-----Original Message-----  From:   Andrzej Czerczak 
>[SMTP:Andrzej_Czerczak/[email-masked]]  Sent:   Tuesday, March 28, 2000 
>6:04 AM  To:     [email-masked]  Subject:        MPLS routing accross AS 
>boundaries
>
>Hi,   Where can I get information on the subject of MPLS QoS routing 
>accross  Autonomous System boundaries?
>
>Thanks  Andrzej

----------------------------------------------------------------
Atsushi Iwata
Assistant Manager
Network System TG, C&C Media Research Labs, NEC Corporation
4-1-1 Miyazaki Miyamae-ku, Kawasaki, Japan 216-8555
TEL: +81-44-856-2123 (Direct), Fax: +81-44-856-2230 (Direct)
NEC-internal TEL: 8-272-3281, NEC-internal FAX: 8-272-3299
E-mail: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 29 Mar 2000 13:27:23 -0500

In message <[email-masked]>, Atsush
> I would like to get any opinion or any suggestions (Pros and Cons) on this 

Someone needed to do this.  You are missing some key parameters like
reservable bandwidth at each of the 8 priority levels.  There is no
good way to specify colr since we're not talking about a link.

This is not interprovider, but rather inter-area in OSPF.

Besides advertising this information a LSR also needs to do something
with it when forming an ERO.  You should have some sort of usage
section.  For example, if a BGP route has a next hop covered by the
area, then the ERO would contain a router to an ABR ending with a
loose hop to the BGP next hop address.  The ABR may either replace the
loose hop with a set of strict hops, or put the LSP into an existing
aggregate tunnel.

In this case the aggregate tunnel may go from the ABR all the way to
the network edge.  The PSC in draft-kompella-mpls-optical-00.txt
serves a similar purpose when the endpoints of the aggregate tunnel
are not the ABR and the area edge.  In the former case there is no
signaling of a PSC required within the area.

Curtis