Subject: RE: Finding the Egress Point in the MPSL Domain for the specific Destination

From: Jim Sullivan <[email-masked]>
Date: Thu, 27 Apr 2000 05:13:04 -0400

Jeremy, 

At 06:47 PM 04/26/2000 +1000, Jeremy Lawrence wrote:
>At 17:39 04/25/2000 -0700, Bora Akyol wrote:
>>I presume you are not familiar with how MPLS is actually used in
providers networks.
>
>I presume you are not familiar with how MPLS is actually used in providers'
>ATM networks. :)
>
>>FEC to LSP binding is almost historical now.
>
>That's arguably true in router-based networks, because of the
>predominance of TE as an application of MPLS in those networks.
>However, FEC to LSP binding is very much alive in ATM MPLS
>networks. 
I'm not sure I completely follow this thread. I make the assumption
that Bora believes all packets that do not get forwarded on 
TE LSPs can be efficiently forwarded as unlabeled packets. 
Is the point your raising that ATM-LSRs in general can not
be expected to forward unlabeled traffic efficiently ? 

Also, at least one MPLS-based VPN scheme relies on
>hop-by-hop routed MPLS (which may, in turn, be over-ridden by
>TE) in network cores of any type.
>
>Regards,
>
>Jeremy Larence
>
>
>
>
>>At 10:55 AM 4/25/00 +0530, Manish R. Shah. wrote:
>>
>>>Hi !!!
>>>
>>>Once the LSP's are created, the ingress router looks for the matching
FEC, and attaches
>>>a label corresponding to that FEC on to the data packet. Further
forwarding is done using
>>>the label switching.
>>>
>>>In an MPLS domain the LDP has already taken care of mapping
>>>FEC's with the incoming and outgoing Labels and efficient distribution
of Labels.
>>>
>>>Look at the following draft for furthur details.
draft-ietf-mpls-ldp-06.txt
>>>
>>>Cheers !!!
>>>
>>>Manish R. Shah.
>>>Senior Software Engineer,
>>>Future Software Pvt Ltd.
>>>480-481, Anna Salai, Nandanam
>>>Chennai 600035.
>>>Phone: +91-(44)-433-0550 Xten 294.
>>>
>>>
>>>-----Original Message-----
>>>From:   Neetu Gupta [SMTP:[email-masked]]
>>>Sent:   Tuesday, April 25, 2000 10:28 AM
>>>To:     [email-masked]
>>>Subject:        Finding the Egress Point in the MPSL Domain for the
specific Destination
>>>
>>>Hello,
>>>     Suppose the LSPs are created among the Edge Routers in the MPLS
>>>Domain with specific class of services. Now the data packet comes at the
>>>Ingress LER, the IP Header contains the Destination Address and TOS
>>>byte.
>>>
>>>Since there are labels to Egress Router, to which Egress LER the data
>>>packet will be forwarded that will route to the Destination?
>>>
>>>I've heard of the draft that specifies how to treat LSP tunnel end node
>>>like LSP egress edge as next node for route calculations.
>>>Please give some reference.
>>>Neetu
>>
>>
>>
>>
>
>

---

From: Jeremy Lawrence <[email-masked]>
Date: Thu, 27 Apr 2000 09:35:02 +1000

Jim,

> >At 17:39 04/25/2000 -0700, Bora Akyol wrote:

[...]
>be expected to forward unlabeled traffic efficiently ? 

Exactly right. ATM-LSRs do not necessarily have any capability
of forwarding unlabelled packets. Most, but not all, ATM-LSRs 
have some capacity to forward unlabelled packets, but (in all
cases I'm aware of) this is limited compared to their capacity
for labelled packet forwarding.

So, where the 'default' forwarding mechanism in a router network
using MPLS TE can sometimes be ordinary IP packet forwarding (see
also the next paragraph), the default mechanism in an ATM MPLS
network normally must be hop-by-hop routed MPLS.

There are also several VPN schemes that require labelled packet
forwarding as the default in any type of MPLS network over which
they operate.

Regards,

Jeremy Lawrence

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 10:01:37 -0400

In message <[email-masked]>, Jeremy Lawrence wr

Jeremy,

Some ISPs have considered running MPLS-RSVP backbones in which the
interior nodes do run an IGP but do not run IBGP.  In such a network,
any router which has one or more EBGP peers must run IBGP and have a
tunnel to any other router with one or more EBGP peer.  The IGP
carries only internal routes and is used for the MPLS signaling plus
management of the network.

This design does not forward external IP traffic hop by hop and does
not use LDP either.  A similar approach could be taken for MPLS-ATM.

Curtis

---

From: "James R. Leu" <[email-masked]>
Date: Thu, 27 Apr 2000 10:17:28 -0500

> not use LDP either.  A similar approach could be taken for MPLS-ATM.

I had a design built around an ATM network that did just this.  A real
plus to this idea is if the tunnels to the others EBGP speakers were
created dynamically as soon at they were learned. (ie each time a new
BGP next hop is learned a tunnel is created to that BGP next hop)

Is this a new idea or is this the same idea as BGP short cuts?

-- 
James R. Leu

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 27 Apr 2000 11:28:05 -0400

> Is this a new idea or is this the same idea as BGP short cuts?

James,

In implementations that I am aware of, the tunnel goes to the peer and
is intended to be configured according to a historic bandwidth
statistic, typically 95 percentile originally suggested by Awduche.
There seems to be some interest in using CR with the greater of a
configured value and a measured value (filtered, of course), but I
have not seem strong interest in using a measured value only and
automatically setting up LSPs to either IBGP peers or as new IBGP next
hops are learned (though I personally like the idea a lot, but more
likely using IBGP peers rather than learned next hops).

Curtis

---

From: "James R. Leu" <[email-masked]>
Date: Thu, 27 Apr 2000 12:06:33 -0500

> likely using IBGP peers rather than learned next hops).

The reason for using the BGP next hop is to solve the case when you use a
route reflector.  In which case each IBGP speaker only has one peer, but
many BGP next hops.

I agree that most "real" TE uses historical bandwidth to a particular node
when setting up a static tunnel.  In my design I envisioned categorizing the
next hops that a particular ingress will use.  An example of these categories
may be:

-High Density Customer POP
-Low Density Customer POP
-Major Exit Point
-Minor Exit Point

Each category would have a template associated with it.  The template would
have many generic parameters specified.  Each BGP next hop would be assigned
to one of these categories (by use of access lists configured by the admin).
Creation of tunnels to these next hops would be dynamic.

Any next hops that can not be classified into one of the categories would have
to be provisioned as static tunnels.

Any thoughts on this?

Jim
-- 
James R. Leu

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Apr 2000 14:40:01 -0400

> route reflector.  In which case each IBGP speaker only has one peer, but

To further clarify current practice as described by ISPs using
MPLS-TE, the LSP generally terminates at the router ID and the next
hop is associated with the LSP for the router ID of the LSR adjacent
in the IGP to the next hop (and closest in TE terms, which is again
advertised by the IGP).  The next hop is preserved across route
reflectors and confederations and the IGP is also unaffected.

Curtis