Subject: Re: Does MPLS Require L3 Routing Table ?

From: [email-masked]
Date: Sat, 14 Apr 2001 15:42:04 -0400

If a router uses MPLS labels to switch the packets, it is an LSR (Label 
Switching Router). If two LSR exchange the 'label/FEC binding 
information,' these two LSRs are known as 'label distribution peers.' 
LDP can be used to distribute the labels. 

During the LDP session setup, a 'basic discovery' procedure will be 
initiated to detect the adjacent nodes. 'Hello' messages are sent as 
UDP packets. At this time, no routing information is needed. However, 
you can only get the label/FEC binding information on the sub-network 
directly connected to you. 

Suppose you are the ingress of the LSP and the Egress LSR is more than 
one hop from you, you have to find the label/FEC binding to that 
destination. That means before the LSP is setup, you must first know 
from whom you can get the label/FEC binding. In this case, you must 
check in your L3 routing table based on the IP address and find the 
next hop so that you can send 'label request on demand' to your 
downstream node to get the binding information. 

Once the LSP is setup, you don't need the routing table for switching 
packets.

***********************
Shujia GONG (Frank)
Advanced Internet Lab
George Mason University
+1-703-993-3905
***********************

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 15 Apr 2001 10:00:44 +0300 (EEST)

> downstream node to get the binding information. 

or you can have labels to be setup automatically between all your edge
routers after which the routers can use inarp to figure out who is
behind each label.  in that mode there is no need for any l3 information
in the core lsrs.

-- juha

---

From: "Rajiv Papneja" <[email-masked]>
Date: Sun, 15 Apr 2001 11:48:05 -0400

----- Original Message -----
From: "Juha Heinanen" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, April 15, 2001 3:00 AM
Subject: Re: Does MPLS Require L3 Routing Table ?

> behind each label.  in that mode there is no need for any l3 information
Hi Juha,

 I was just wondering that if  this is a scalable approach. This might give
rise to a large number of inarps in a large mesh network.
Also, I am not really sure that anyone has yet implemented this feature over
the unidirectional virtual circuits (for eg. MPLS LSPs). If possible can you
provide some more insight into this topic, I will more than interested to
know about this. Thanks.

 -Rajiv

********************************
Rajiv Papneja (GRA)
Advanced Internet Laboratory
George Mason University,
G10, Johnson Center,
Fairfax, VA 22030-4444
Tel: 703.993.4703
email: [email-masked]
********************************

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 15 Apr 2001 19:11:09 +0300 (EEST)

> provide some more insight into this topic, I will more than interested to

see draft-heinanen-inarp-uni-01.txt,

-- juha

---

From: Eric Gray <[email-masked]>
Date: Mon, 16 Apr 2001 07:48:34 -0400

Juha,

    With LSPs being fundamentally unidirectional, how would
you make this work?  Would you slowly strobe all of the LSPs
going out and wait for a timeout on each INARP request, or
are you assuming some other way to tie incoming to outgoing
labels?

--
Eric Gray

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 17 Apr 2001 10:48:26 -0400

> see draft-heinanen-inarp-uni-01.txt,

Looks worse than NHRP.

Curtis

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 17 Apr 2001 19:51:33 +0300 (EEST)

> Looks worse than NHRP.

i'm not sure if you understod the inarp draft.  inarp is used over frame
relay all over the world and the draft describes similar function for
mpls.  it's not very useful to send a message with the above contents
without elaborating what is wrong with it.

-- juha

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Apr 2001 14:20:25 -0400

Juha,

The ATM LIS idea (rfc1577), NHRP, MPOA, are all poor choices for
scalability and reliability.  So is the FR LIS.  The reason an ATM LIS
or FR LIS is unreliable is that in practice one or more VC in the net
doesn't come up for some reason.  When this occurs, a persistent black
hole results.  Persistent black holes are best avoided.

Curtis

---

From: Eric Rosen <[email-masked]>
Date: Wed, 18 Apr 2001 14:57:33 -0400

Juha> or you can have labels to be setup automatically between all your edge
Juha> routers after  which the routers  can use inarp  to figure out  who is
Juha> behind  each  label.   in that  mode  there  is  no  need for  any  l3
Juha> information in the core lsrs.

How would you get the LSPs  to be setup "automatically between all your edge
routers" without having any L3 routing information in the core?

---

From: David Charlap <[email-masked]>
Date: Wed, 18 Apr 2001 15:05:10 -0400

Eric Rosen wrote:
> Juha Heinanen wrote:
>> 
>> or you can have labels to be setup automatically between all your
>> edge routers after which the routers can use inarp to figure out
>> who is behind each label.  in that mode there is no need for any
>> l3 information in the core lsrs.
> 
> How would you get the LSPs  to be setup "automatically between all
> your edge routers" without having any L3 routing information in the
> core?

I think Juha meant that the core doesn't need _global_ L3 routing
information (as it needs in a core using hop-by-hop routing).  It would
still need enough of an IGP to know how to get traffic to its own
routers.

If Juha actually meant no L3 information whatsoever, then I'll also be
interested to hear how this could possibly work.

-- David

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 19 Apr 2001 05:27:18 +0300 (EEST)

> hole results.  Persistent black holes are best avoided.

curtis,

fr pvcs have been used since 1991 to connect routers together.  there
are thousands of vpns build that way.  this is the first time i hear
about your black hole problem and i have been runnign these kind of vpns
for ten years now.  if a pvc doesn't come up, then there is a single
point of failure link down somewhere and the situation is no different
from a leased line between routers being down.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 19 Apr 2001 05:37:39 +0300 (EEST)

> interested to hear how this could possibly work.

i tried to answer this in the previous message, but i would like to add
that i don't advocate such a mode of operation and that that actually
has nothing to do with inarp over unidicational vcs.  the latter is used
when the provider has one way or another created plsps connecting ce
lsrs together.

this reminds me of another thing.  some time ago i proposed a way to
signal soft lsps. i didn't follow up on it, because i thought that the
generalized mpls thing would cover also that issue.  apparently it
didn't.  my question is, if it didn't is there now a way to do it or
should i come back with an enhanced proposal?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 19 Apr 2001 05:31:26 +0300 (EEST)

> routers" without having any L3 routing information in the core?

i'm not an ldp expert, but i assume that using the du mode, each egress
router can advertise an lsp to itself to all its neighbors and so on.
thus eventually every router in the system would have a path to every
egress router.  this assumes that each router adds itself to the
advertisement in order to cut the loops.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Thu, 19 Apr 2001 10:42:44 -0400

Juha> i'm  not an ldp  expert, but  i assume  that using  the du  mode, each
Juha> egress router can advertise an lsp  to itself to all its neighbors and
Juha> so on.  thus  eventually every router in the system  would have a path
Juha> to every egress router.  this  assumes that each router adds itself to
Juha> the advertisement in order to cut the loops.

Let me call your attention to section 3.5.7.1 of the LDP spec:

   An LSR receiving a Label Mapping message from a downstream LSR for a
   Prefix or Host Address FEC Element should not use the label for
   forwarding unless its routing table contains an entry that exactly
   matches the FEC Element.

So one can't really do things the way you suggest.  

In fact, if one did  distribution address prefix routing information in this
manner using LDP,  then LDP would be functioning as  a L3 routing algorithm,
so it  would in any case  be somewhat inaccurate  to say that MPLS  is being
used without the need to maintain any L3 routing information.

Juha> I would like to add that I don't advocate such a mode of operation and
Juha> that that  actually has  nothing to do  with inarp  over unidicational
Juha> vcs.  The  latter is  used when  the provider has  one way  or another
Juha> created plsps connecting ce lsrs together.

Given a  pre-existing LSP connecting  two CEs, it  might well make  sense to
have a procedure  for each to discover  who is at the other  end.  The prior
question  here  would  be  whether  there  is real  value  in  having  these
pre-existing LSPs connecting the two CEs.

I think what people have been objecting to is the suggestion (now apparently
disavowed)  that such a  procedure somehow  eliminates the  need to  have L3
routing in  the core.   That's what made  it seems  like there must  be some
MPOA-like stuff hiding beneath the surface.

---

From: David Charlap <[email-masked]>
Date: Thu, 19 Apr 2001 11:05:38 -0400

Juha Heinanen wrote:
>> your edge routers" without having any L3 routing information in
>> the core?
> 
> i'm not an ldp expert, but i assume that using the du mode, each
> egress router can advertise an lsp to itself to all its neighbors
> and so on.  thus eventually every router in the system would have a
> path to every egress router.  this assumes that each router adds
> itself to the advertisement in order to cut the loops.

The problem with this isn't loop detection.  LDP has two mechanisms for
this (the hop-count and path-vector TLVs).

The problem is that in some topologies, it will be possible (and even
likely) that you'll receive the labels same FEC on multiple interfaces.

The RFC states that the one you use must be the one that your local
routing table says came from the next-hop to that FEC.

You can't use any LDP-based metrics to determine this, because
topologies can change over time, and label mappings are not periodically
refreshed.  If the shortest path to a FEC changes, LDP will have to
start using the interface and label for the new next-hop.  The IGP will
know when this happens, LDP will not.

-- David

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Apr 2001 12:22:25 -0400

> from a leased line between routers being down.

Since this came up on the "Does MPLS Require L3 Routing Table" I was
assuming that you want to run without an IGP.

The FR PVC must be configured as point to point or as NBMA for a
partial mesh to exist.  In NBMA, all of the PVC to the DR must come up
or traffic to an address on the subnet with no PVC is blackholed
rather than sent some other way if there is an alternate route.

Misfeatures have been used in the past.  Just because proxy-arp was
used heavily in the late 1980s doesn't mean its a good replacement for
an IGP either.

Curtis

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 19 Apr 2001 19:17:00 +0300 (EEST)

> So one can't really do things the way you suggest.  

"should not" is not the same as "must not".  i was just trying to point
out what CAN be done and not that it would be a good idea to do so.

 > pre-existing LSPs connecting the two CEs.

there is a huge installed base of frame relay that is almost 100% based
on the pvc paradigm.  the fact is that operators don't like the idea of
customers signaling dynamically frame relay svcs in their networks and
the same will hold for mpls lsps.

 > MPOA-like stuff hiding beneath the surface. 

the soft permanent lsps are setup using l3 routing protocol.  there is
no mpsl like stuff anywhere.  frame pvcs connecting routers have been
used years before mpoa appeared.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Thu, 19 Apr 2001 12:40:01 -0400

Juha> there is  a huge  installed base  of frame relay  that is  almost 100%
Juha> based on the pvc paradigm.  the  fact is that operators don't like the
Juha> idea  of customers  signaling dynamically  frame relay  svcs  in their
Juha> networks and the same will hold for mpls lsps.

I didn't mean to suggest that the SVC paradigm is better for CE-CE LSPs than
the PVC  paradigm; the  question is whether  MPLS as  a CE-CE link  layer is
valuable.   Of course,  this  is really  far  afield of  the  topic of  this
thread.

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 20 Apr 2001 00:56:35 +0300 (EEST)

> valuable.   Of course,  this  is really  far  afield of  the  topic of  this

mpls as ce-ce link has many advantages over frame relay, e.g., exp field
for diffserv support and label stacking.  if mpsl is used in the middle,
it is always a good idea to avoid interworking and run mpls all the way.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Fri, 20 Apr 2001 10:09:15 -0400

Juha> mpls as ce-ce link has many advantages over frame relay, e.g., exp field
Juha> for diffserv support

I think  the IP header already  contains a field  which the user can  set to
signal diffserv support to the service  provider.  Or are you saying that it
is important to be able to  signal diffserv on a per-packet basis for non-IP
packets?

Juha> and label stacking. 

This suggests  that the backbone should  run MPLS, rather  than Frame Relay,
and I'd  certainly agree with  that, but  I don't see  why this is  an issue
vis. a vis. CE-CE LSPs.  Of course,  if two CEs want to send each other MPLS
packets, they can send them over any data link whatsoever.

Juha> if mpls  is used  in the  middle, it is  always a  good idea  to avoid
Juha> interworking and run mpls all the way.

I don't see why this is the case.

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 21 Apr 2001 11:20:59 +0300 (EEST)

> is important to be able to  signal diffserv on a per-packet basis for non-IP

i as a service provider don't have any idea what packets my customer is
carrying over the l2 circuits between their sites.  it is beneficial for
the customer if it can tell in the exp field how it wants the packets to
be treated when they cross my network.

 > packets, they can send them over any data link whatsoever.

if the customer uses mpls for its internal stuff and has an lsr ce
device, it would be very stupid if i as the provided would need to ask
the customer to encapsulate their mpls packets into frame relay packets
when they are send to other sites.

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Mon, 23 Apr 2001 11:22:03 -0400

Eric> I think the IP header already  contains a field which the user can set
Eric> to signal diffserv support to the service provider.  Or are you saying
Eric> that it  is important to  be able to  signal diffserv on  a per-packet
Eric> basis for non-IP packets?

Juha> i as a service provider don't have any idea what packets my customer is
Juha> carrying over the l2 circuits between their sites.  it is beneficial for
Juha> the customer if it can tell in the exp field how it wants the packets to
Juha> be treated when they cross my network. 

What is the customer application for  which the customer is likely to have a
CE  device   that  will  mark   individual  non-IP  packets   with  diffserv
information?

Eric> This suggests  that the  backbone should run  MPLS, rather  than Frame
Eric> Relay, and I'd certainly agree with  that, but I don't see why this is
Eric> an issue vis. a  vis. CE-CE LSPs.  Of course, if two  CEs want to send
Eric> each  other  MPLS packets,  they  can send  them  over  any data  link
Eric> whatsoever.

Juha> if the  customer uses mpls  for its internal  stuff and has an  lsr ce
Juha> device, it would be very stupid if i as the provided would need to ask
Juha> the  customer  to encapsulate  their  mpls  packets  into frame  relay
Juha> packets when they are send to other sites.

Not many  customers use  MPLS for  their internal stuff.   Do you  foresee a
significant migration of  MPLS into the enterprise?  Or  are you thinking of
other service providers as the customers. 

In any  event, if two routers are  connected by a serial  link, MPLS packets
between the  routers get encapsulated into  (most likely )  PPP packets.  If
two  routers are connected  by an  ethernet link,  MPLS packets  between the
routes get encapsulated into ethernet  frames.  If two routers are connected
by a  frame relay  link, MPLS packets  between the routers  get encapsulated
into frame relay frames.  If two  routers are connected by an ATM link, MPLS
packets between  the routers get encapsulated  in AAL5 frames.   In fact, it
looks like in all the common  cases, MPLS packets get encapsulated in a data
link frame when being sent from one system to another. 

Are all these cases "very stupid"?  If not, how do they differ from the case
you are considering?

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 23 Apr 2001 18:51:00 +0300 (EEST)

Eric Rosen writes:

 >  What is the customer application for which the customer is likely to
 > have a CE device that will mark individual non-IP packets with
 > diffserv information?

for example, bridging ethernet over mpls.

 >  Not many customers use MPLS for their internal stuff.  Do you
 > foresee a significant migration of MPLS into the enterprise?  Or are
 > you thinking of other service providers as the customers.

mpls may not be used that much inside the enterprise (apart from the
ces), but we have all kinds of other customers that do plan to use mpls,
such as other isps and mobile network operators.

 >  Are all these cases "very stupid"?  If not, how do they differ from
 > the case you are considering?

no, i was refering as "stupid" a case there the customer wants to send
mpls packets over my mpls backbone and must encapsulate them into frame
relay over local loop.

eric,  i haven't understod what you are driving at.  are you suggesting
that it doesn't make sense to replace frame relay with mlps as a logical
link service even when the backbone is mpls and the ces are mpls
capable?

-- juha

---

From: Eric Rosen <[email-masked]>
Date: Mon, 23 Apr 2001 13:06:39 -0400

Juha> are you suggesting  that it doesn't make sense  to replace frame relay
Juha> with mpls as a logical link service even when the backbone is mpls and
Juha> the ces are mpls capable?

I've just  been asking for an  explanation of the advantages  of doing this.
You've suggested two advantages:

1. The CE  can set the EXP  bits, allowing it to  signal per-packet diffserv
   handling for  non-IP packets.  This might  be an advantage,  if there are
   situations  in which  it is  important for  the CE  to  signal per-packet
   diffserv handling  for packets,  without the PE  having to  know anything
   at  all about the  encapsulated packets.   On the  other hand,  any other
   encapsulation  which has  three available  bits would  do as  well.  This
   might be worth more discussion.

2. If  one CE  is  sending  MPLS packets  to  a second  CE,  over a  service
   provider's MPLS  backbone, then this  eliminates the need  to encapsulate
   the MPLS packets in a data link layer.

   This one I  don't see at all.  Since in  every existing application, MPLS
   packets  are encapsulated  in a  data link  layer, avoiding  the  need to
   encapsulate them in a data  link layer in one particular scenario doesn't
   seem that important.   And why would the CE care  anyway whether it wraps
   the MPLS packet in a frame relay  header with a DLCI field, or whether it
   pushes a  new (statically  configured, I guess,  since you  dislike SVCs)
   MPLS label on the packet? 

   If the purpose of  using MPLS on the access link is  just to have the top
   label  identify a  particular virtual  circuit, I  don't really  see that
   there  is  a  significant  advantage  over  any  other  data  link  layer
   multiplexing technique.