Subject: RE: prime time MPLS/fiber

From: Jeremy Lawrence <[email-masked]>
Date: Thu, 06 Jan 2000 10:16:23 +1100

Shahram,

At 10:06 01/05/2000 -0800, Shahram Davari wrote:
>Hi,
>
>MPLS at the access can also reduce the classification burden of the edge
>routers and make it distributed.

Agreed in principle, though the security of management of that could
be a problem. If a malicious person gained access to an edge LSR, it's
easy to imagine ways in which they could make the network unstable,
or otherwise cause trouble (e.g. by readvertising large numbers of
routes into the network core). If the CPE are edge LSRs, then the
scope for that sort of thing is very high.

I have been involved in network designs where edge LSRs are customer
located equipment, but that involved a requirement that the edge
LSRs were placed only in a physically secure environment, e.g.
a telco-controlled distribution room in a building.

Regards,

Jeremy Lawrence

> > -----Original Message-----
> > From: Grenville Armitage [mailto:[email-masked]]
> > Sent: Wednesday, January 05, 2000 1:05 PM
> > To: Jeremy Lawrence
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: prime time MPLS/fiber
> > 
> > 
> > 
> > 
> > Jeremy Lawrence wrote:
> >       [..]
> > 
> > > At the edge (between the home and the first SP router), I don't
> > > think MPLS makes sense. MPLS may well make sense in the network
> > > core, for the reasons just discussed, but the access just needs
> > > to be IP-over-anything. IP/x/fiber, where x is an appropriate
> > > data link layer (PPP, fast ethernet, gigabit ethernet, etc.),
> > > could certainly be used.
> > 
> > In principle MPLS might be useful in the access networks for the
> > same reasons ATM is sometimes used in access networks - a 'connection'
> > abstraction allows things like multiple provider selection over
> > single physical links. Each LSP can be a virtual access link.
> > 
> > cheers,
> > gja
> >

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 6 Jan 2000 09:57:54 +0200 (EET)

> a telco-controlled distribution room in a building.

why is that?  you can use soft permanent lsps (once we have got
them defined) between the cpe lsr and the operator lsr.  you could also
use real signaled lsps and install an access list in the operator lsr
that controls what kind of destination addresses can be used.

-- juha

---

From: Jeremy Lawrence <[email-masked]>
Date: Fri, 07 Jan 2000 11:51:47 +1100

Juha,

>that controls what kind of destination addresses can be used.

First, a clarification: the customer located edge LSR I mentioned was
an operator LSR, dealing with CPE from several different customers.
But on to the real issue, which is when/if it makes sense to turn
on MPLS on CPE...

Looking first at performance: using MPLS on CPE would seem to be of
performance benefit if the operator LSR was going to be able to
label-switch the packets without pushing extra labels, and without
looking into the IP headers of the packet. One requirement for this
would be for the routes as seen by the customer LSR to have
the same granularity of (a subset of) the operator's IGP routes.
(In other words, it is highly unlikely that the CPE could simply
point "default" at the operator router, which breaks a common
operational requirement.) In the unlikely event that this condition
could be met, then the operator LSR could then be, say, an ATM-LSR,
with the "router-like" edge functions offloaded to the CPE LSR.

In the more likely case that the routing granularity is different
for some reason, then the operator LSR would need to look into the
IP packets from the CPE LSR, and have to act as an edge LSR. (Also,
if TE or VPNs were used, the operator LSR might well have to push
and pop labels, which might also implies "edge LSR" function and
overhead.)

So, from a performance perspective, there would be little point
having the CPE router act as an edge LSR, as the extra work
required in the operator LSR for the CPE LSR to send unlabelled
IP packets would be marginal.

Having both the CPE router and the operator router act as edge
LSRs would make sense, though, if the goal was to use MPLS for
protection switching between the CPE LSR and the operator LSR.
(Which, I think, was one of your points?)

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Jan 2000 08:47:27 +0200 (EET)

jeremy,

i didn't understand anything you said about granularity of igp routes,
default route, etc.  i don't need any of that in order to use mpls in
the cpe router.  my model would be exactly the same as in case of using
atm in a cpe router (adsl or something else).

the cpe router simply sets up lsps to ip addresses of other cpe routers
or isp routers, or receives lsp setups from them or defines permanent
lsps that match operator defined soft permanent lsps.  if the cpe router
is not multihomed, there is no need to run any routing protocol between
it and the operator lsr.  the cpe router can learn the ip addresses of
the target routers for the lsp setups by any offline means.

-- juha

---

From: Jeremy Lawrence <[email-masked]>
Date: Sat, 08 Jan 2000 18:09:48 +1100

Juha,

>the target routers for the lsp setups by any offline means.

Yes, MPLS can be run on the CPE. I'm addressing a somewhat different
issue, which is whether any benefit is derived by running MPLS on
the CPE.

Unless the CPE knows routing information with the same granularity
as the operator LSR, there is little or no performance benefit
to the operator LSR if the CPE is an LSR. If the granularities
are different, then the operator LSR must look at the IP address
in the packets from the CPE, in order to re-label then with a
label corresponding to the correct address-prefix.

In general, the CPE may know routing information with a different
granularity to the operator LSR (e.g. it would often know exactly
two routes: one customer network, and a default route through
the operator LSR). 

Let's look an example.

20.0.0.0/8---CPE-----Operator LSR
             x     y

Let's look a the case where the Operator LSR is an ATM-LSR.
The operator LSR might have thousands of entries in its
forwarding table, e.g.
0.0.0.0/0
10.0.0.0/8
10.1.0.0/16
10.1.1.0/24
10.1.1.1/32
10.2.0.0/16
20.0.0.0/8
...

On the other hand the CPE probably has a table like
0.0.0.0/0 y
20.0.0.0/8 x

Now assume that the CPE wants to send a packet to 10.1.1.2.
It would label it to be sent to 0.0.0.0/0. There is no
way that the operator LSR could forward this correctly. So there
is no point running a network in this configuration, unless
the CPE knows the same thousands of routes as the operator LSR,
which would imply the running of a routing protocol to the CPE.
This may well be unacceptable.

If the Operator LSR is a frame-based LSR, then it would advertise
thousands of labels to the CPE. Assuming that the CPE has enough
memory to deal with all the labels (it's expected to deal
with thousands of labels even though it has only two routes),
then it could label the packet so that it can be forwarded
correctly by the operator LSR.

However the operator LSR can probably deal with unlabelled IP
packets with similar performance to labelled packets (this is
true for all the frame-based LSRs with which I'm familiar).

So, in general, there is little performance benefit to running
MPLS on the CPE. There may be other benefits.

Regards,

Jeremy

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 8 Jan 2000 09:29:56 +0200 (EET)

yes, looks like we are not talking about the same thing at all.  in my
model, the operator lsr would not announce any labels to the cpe lsr.
all labels that the cpe lsr would know of are those that it had got back
as responses to its own label request messages and it would send label
request messages only for those destinations that it is interested in
sending packets to, e.g., an isp lsr and an lsr of another site of the
same company.

-- juha

---

From: "Thomas Wolfram" <[email-masked]>
Date: Sat, 8 Jan 2000 13:05:03 +0100

> The operator LSR might have thousands of entries in its

I think that depends. In the scenario you're describing it
probably wouldn't make a lot of sense.
But I think if you would want to use framed MPLS to replace
cell ATM in an xDSL access network extending MPLS to the CPE
could make sense. There the CPE isn't connected directly to the
operator LSR having all the internet routes anyway. Perhaps
several hundred CPEs are connected to DSLAMs and you have
perhaps the LERs of several ISPs connected to the PoP. You
could also have other service gateways connected to the
PoP. All these ISP LERs route into the internet, i.e. to the
same set of destinations. You wouldn't use MPLS on the local
loop to pre-label the packets for transport through the core
network but through the access network. By using different labels
the customer could even choose to send different traffic to
the same destination via different ISPs though he has only
one physical xDSL link.
I.e. I think you could use MPLS for the same purpose ATM is
used in the access networks today.

---

From: Jeremy Lawrence <[email-masked]>
Date: Mon, 10 Jan 2000 13:17:08 +1100

Juha,

>sending packets to, e.g., an isp lsr and an lsr of another site of the

What are the semantics of the label request message? If it is
a normal LDP message saying "give me a label for address
prefix a.b.c.d/x", then there is a problem for which the only
obvious solution is for the operator LSR to respond by announcing
many labels in general, perhaps labels for all the addresses it
knows. (On the other hand, if the semantics are different, there
may be no such problem.)

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jan 2000 09:02:35 +0200 (EET)

Jeremy Lawrence writes:

 > knows.

yes, the cpe router asks for a label for a single address a.b.c.d/32
which is the address the the peer router (e.g. isp or corporate) to
which it wants to setup an lsp and gets back a single label.  the
operator lsp never advertises any labels to the cpe router that the cpe
router has not been asked for.

-- juha

---

From: Jeremy Lawrence <[email-masked]>
Date: Mon, 10 Jan 2000 19:14:41 +1100

Juha,

>router has not been asked for.

That will work if and only if the operator LSR knows a route for
a.b.c.d/32 specifically, and not just a less specific route like
a.b.0.0/16. Otherwise, there are problems, and the current LDP spec
prohibits issuing a binding.

One clarification: in the other case you mentioned, which was where
the CPE is getting access to/through a specific ISP, are you assuming
that it also needs a label for a /32 only?

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jan 2000 10:34:16 +0200 (EET)

> prohibits issuing a binding.

i sent a message about this a month ago, but there was no discussion.
the question was, how should an lsr advertise its interfaces (or cpe
lsrs behind those interfaces).  one obvious (but not good) solution is
to advertise a host route for each interface separately. a better
solution would be to advertise a single prefix, for example a /28 one,
if the lsr has a maximum of 16 interfaces, where the interface would
then be selected locally using the last 4 bits of the prefix.

i'm not an ldp expert, but if you say that only the host route solution
would be consistent with the current ldp spec, then there is something
seriously wrong with the spec.

 > that it also needs a label for a /32 only?

yes, juha

---

From: Jeremy Lawrence <[email-masked]>
Date: Mon, 10 Jan 2000 23:15:43 +1100

Juha,

>seriously wrong with the spec.

That's not necessarily the case. It could be argued that to change
the LDP spec on this issue would be to change the MPLS architecture.

The current situation was a generally agreed solution to a messy
problem. In short, things get extremely complicated when two
adjacent LSRs don't run a routing protocol between each other, and
hence have different granularities of routing knowledge

(My previous example of routing tables was getting at some of the
issues; there are others.)

There was no consensus on a number of issues related to this, but
consensus was reached to assume that adjacent LSRs either do run a
routing protocol between each other, or otherwise have exactly
corresponding routing knowledge for the addresses of interest.

This resulted in two restrictions in the LDP spec:

- For Label Request Message processing, which occurs in Downstream
   on demand mode:
     "Unless its routing table includes an entry that exactly
      matches the requested Prefix or Host Address, the LSR must
      respond with a No Route Notification message."
      [draft-ietf-mpls-ldp-06.txt, 3.5.8.1]

- For Label mapping Message processing:
     "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.
      [draft-ietf-mpls-ldp-06.txt, 3.5.7.1]

It is might possible to change LDP to remove this assumption, but
this would involve a lot of work and debate, on both LDP itself,
and on the architectural issues. LDP is currently designed to
work in close conjunction with a routing protocol.

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 10 Jan 2000 14:26:15 +0200 (EET)

> work in close conjunction with a routing protocol.

ok, in that case an lsr that wishes to terminate label requests to
itself, needs to advertise its ip address(es) as /32 routes.  i assume
that an actual routing protocol is not needed, but that the advertisement
can be staticly configured.

regarding the architectural issues, if a network is only interested to
run ldp in downstream on demand/ordered control mode, then it is not
clear to me what the architectural and prototol problems would be that
would prevent an lsr from forwarding a label request based on longest
match.

-- juha

---

From: Jeremy Lawrence <[email-masked]>
Date: Tue, 11 Jan 2000 10:02:51 +1100

Juha,

>would prevent an lsr from forwarding a label request based on longest

Assume that the CPE uses LDP to ask for a label for a.b.c.d/32, and
the operator LSR knows a route only for a.b.0.0/16, and LDP is modified
to allow it to respond. There are many issues with this that are
not addressed in the LDP spec:
- Does the operator LSR respond with a binding for
   a. a.b.c.d/32, or
   b. a.b.0.0/16?
- If (b), then either:
   i. The CPE must not assume that it can use the binding for
      any address in a.b.0.0/16. It must ask again for each address,
      in case the operator LSR knows a more specific route for some
      of the addresses.
   ii. If the operator LSR knows more specific routes in a.b.0.0/16,
       (e.g. a.b.e.0/24) it must return bindings for those routes at
       the same time that it returns the binding for a.b.0.0/16.
- In (a) or (b.i), then if the CPE asks for bindings for other
   addresses for which a.b.0.0/16 is the best match, then the operator
   LSR should return the same label value. (Or should it?)
- What are the procedures if the route for a.b.0.0/16 goes away?
   (Observe that there might be other valid routes to a.b.c.d,
   e.g. a.0.0.0/8, or 0.0.0.0/0. What should the operator LSR
   automatically do?)
- What are the procedures if a new route in a.b.0.0/16 is learnt,
   e.g. a.b.f.0/24?

The last two points suggest that with either (a) or (b.i), the
operator LSR must remember the requested prefixes for all binding
requests, even though it will respond with a duplicate label to
many of them. This is so it can make the correct changes to the
labels if the routing information ever changes.

Now assume that the CPE can ask for addresses other than /32s.
This will work ok with (b.ii), but it's not obvious how to
make this work with (a) or (b.i), except to make them work
like (b.ii) in this case.

Note that with (b.ii), if the CPE ever asks for a binding for
0.0.0.0/0, then the LDP peering will then (effectively) start
to run in downstream mode.

Curtis has just pointed out that the problem can be dealt with
by using an explicitly routed LSP rather than LDP. That seems
more sensible than modifying LDP to deal with all this mess.

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 11 Jan 2000 10:41:25 +0200 (EET)

> - Does the operator LSR respond with a binding for

it should respond with (a) since that is what the user asked for.

 >    LSR should return the same label value. (Or should it?)

it should return a new label for the other destination.

 >    e.g. a.0.0.0/8, or 0.0.0.0/0. What should the operator LSR

nothing as long the lsp stays up.

 > - What are the procedures if a new route in a.b.0.0/16 is learnt,

again, new routes only affect new lsps, not the ones that already exist
as long as they stay up.  an operator can of course have a policy to
reroute also existing lsps if the new routes are "much" better than the
old ones and tell when that can happen.

 > labels if the routing information ever changes.

i don't see how the labels could be duplicate for different
destinations.

 > like (b.ii) in this case.

in the application that i have been talking about, the cpe lsr would not
ASK labels for addresses other than /32, but the lsrs would ADVERTISE
addresses with prefixes other than /32.

 > more sensible than modifying LDP to deal with all this mess.

it doesn't sound realistic to me that the cpe lsr would know or care
about any explicit routes.

-- juha

---

From: "Antti Kankkunen" <[email-masked]>
Date: Tue, 11 Jan 2000 17:18:47 -0500

Thomas and others,

a related comment below.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Thomas
> Wolfram
> Sent: Saturday, January 08, 2000 7:05 AM
> To: [email-masked]; [email-masked]
> Subject: RE: prime time MPLS/fiber
>

> used in the access networks today.

There is already some effort in progress to address the kinds of applications
you describe above.

In their Paris meeting early February, the DSL Forum will hold a BOF session on
MPLS and its relevance to the DSL/DSLAM architectures being addressed in the DSL
Forum set of recommendations. Please see
http://www.adsl.com/adsl_forum.html (Click on Meetings & Events / Meeting
Information)

You need to be a DSL Forum member to attend the BOF session. The session is held
on the evening of either 2/9 or 2/10.

Below please find a quote from an e-mail from Greg Wetzel of Covad describing
the BOF session.

===Beginning of quote from Greg Wetzel==
The technical committee chair, Gavin Young, agreed just last week to hold a
BoF on MPLS at the technical committee meeting in Paris.  It will be chaired
by Martin Jackson, a member of the DSL Forum board of directors.  The BoF
will be either Wed or Thu evening from 5:30-7:30pm.  An agenda will be
forthcoming shortly, but will include a 45 min MPLS tutorial from David
Allan, Nortel, chair of the Architecture Working Group, and an hour on the
discussion of how MPLS fits into the DSL Forum set of recommendations.
===End of quote====================

Best regards,

Antti K.

---

From: Jeremy Lawrence <[email-masked]>
Date: Wed, 12 Jan 2000 10:20:44 +1100

Juha,

I agree with some of your responses about LDP procedures, and disagree
with others. However I think the key point is this:

>Jeremy Lawrence writes:
[...]
>about any explicit routes.

It isn't, but the mechanisms for explicit routing do exactly what
is required here. A loose source routed LSP from the CPE to a.b.c.d/32
(so "loose" that no intermediate hops are specified at all) does
exactly what is required, without requiring any modification to LDP,
and without requiring any information at the CPE other than the
address a.b.c.d/32.

Regards,

Jeremy Lawrence

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 12 Jan 2000 08:35:39 +0200 (EET)

> and without requiring any information at the CPE other than the

this is fine with me.

-- juha