Subject: several questions

From: "Navid Yazdani" <[email-masked]>
Date: Thu, 6 Sep 2001 13:05:13 -0400

I have a few questions regarding using MPLS with CR-LDP to DYNAMICALLY
setup LSPs.

1) Do I have to use CSPF (a constraint-based shortest path first algorithm)
rather than just normal OSPF?
2) Does that mean that I can't use the concept of areas in OSPF to
summarize routes?  How would a summary advertise the CR-LDP traffic
constraints?
3) If I can't use route summaries, is MPLS with dynamically setting up LSP
not scalable?

4) When an Edge LSR wants to setup an LSP using CR-LDP, does it look at the
traffic requirements, choose a path, and then mark that path as an explicit
route?  I want to know if the entire path is choosen by the Edge LSR and
the other LSRs just reserve the requested resources and forward the label
request message along the explicit route.
5) If the resources have changed for whatever reason at an intermediate LSR
and there are not enough resources to setup the LSP, is there any mechanism
for the intermediate LSR to find a new path from that point on that meets
the constraints and forward the label request message along that path?  Or
is that LSP setup completely abandoned and the edge LSR must try to setup
another LSP?

Thanks in advance
-Navid

---

From: "Mareline Sheldon" <[email-masked]>
Date: Fri, 7 Sep 2001 15:04:59 +0530

I disagree with Zhu Heqing on a few points .. and please correct me if i am
wrong :-)

> rather than just normal OSPF?

You have to use CSPF, if when computing the path at the source you want to
take into account not just some scalar metrics (minimizes administrative
metric, hop count)  but also a set of constraints which should not be
violated.

> summarize routes?  How would a summary advertise the CR-LDP traffic

Before answering this one, lets first understand how CSPF is really
different from OSPF.
Given the operations of SPF, what are the modifications which we need to
make to turn it into CSPF ?
All we need to do is to modify the step in the plain SPF algorithm that
handles addition/modifications of the candidate list. Whenever a node is
added to the shortest path tree, for each link attached to this node,
examine the nodes at the other end of this link. As we now examine links
attached to this node, we first check whether this link satisfies the
constraints. If and only if it does, then we examine the node at the other
end of the link. Thus only the links which satisfy the given constraints are
taken into consideration when forming the shortest path tree. Thus CSPF is
*not* really different from OSPF.

It just the links which it takes into consideration is different. Thus we
can get an entirely different shortest path tree by running OSPF over the
same topology. But this does not inhibit us from dividing the entire
topology into areas and so on.

The constraint-related information associated with the link is carried by
the OSPF opaque LSAs if thats what you wanted to ask. You have TLVs defined
in IS-IS to carry around all your TE related info.

> 3) If I can't use route summaries, is MPLS with dynamically setting up LSP

Explained above. You can use route summaries .. and hence proves that MPLS
is scalable ;-)

> request message along the explicit route.

No, I dont think it works that way. The PATH message sent by the ingress LSR
contains a LABEL_REQUEST object that asks the intermediate LSRs and the
egress LSR to provide a label binding for the particular path. If the
LABEL_REQUEST object is not supported by any  LSR along the path, the
ingress LSR is notified by the first LSR on the path that doesn't support
the LABEL_REQUEST object.

Please note that EXPLICIT_ROUTE object (ERO) is an optional objetc contained
in an RSVP PATH message. It is *only* when the ERO is present, the RSVP PATH
message is forwarded towards the egress LSR along the path specified by the
ERO, *independent* of the IGP shortest path.

Thus by default the path taken is the one guided by the IGP running !

> is that LSP setup completely abandoned and the edge LSR must try to setup

In such a case an existing tunnel is rerouted. Since we dont want the
traffic to get disrupted when a LSP is rerouted  a concept called "make
before break" is used in which the new LSP tunnel is established and the
traffic is transferred to it before the old LSP tunnel is torn down.

Comments/Queries are most welcome !
Mary

> -Navid

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Giles Heron <[email-masked]>
Date: Fri, 07 Sep 2001 11:54:23 +0100

Mareline Sheldon wrote:
[snip]
> topology into areas and so on.

But the opaque LSAs used for TE don't cross area boundaries.  So whilst
you can divide the network topology into areas you can't actually do TE
across those areas.  But there is ongoing work on multi-area TE to fix
this...

> Explained above. You can use route summaries .. and hence proves that MPLS

Well, sort of.  Like I say, CSPF won't work across area boundaries.

And if you are using LDP (not CR-LDP, that doesn't seem to exist in any
approximation of reality) to signal your LSPs then route summaries are a
bad idea, since you need the FECs to match prefixes in your IGP.

> Thus by default the path taken is the one guided by the IGP running !

But YMMV depending on the RSVP-TE implementation in your router.  Some
boxes always send an ERO I think?

> traffic is transferred to it before the old LSP tunnel is torn down.

I'm not sure that you have answered the question here?

The question is what happens if during LSP setup the intermediate LSR
discovers that there aren't actually enough resources to set up the LSP
(this may happen because the TED isn't necessarily up-to-date - there is
a tradeoff here between resources consumed if you signal any change of
TE resource vs allowing the TED to get slightly out of sync.)

AFAIK if the intermediate LSR knows that there are insufficient
resources to set up the LSP along the specified ERO then it will fail
the LSP setup.  So the head end will have to try again...

Giles

--
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: "Mareline Sheldon" <[email-masked]>
Date: Fri, 7 Sep 2001 17:59:58 +0530

Please find my comments inline ..

----- Original Message -----
From: "Giles Heron" <[email-masked]>

> across those areas.  But there is ongoing work on multi-area TE to fix

Don't we use opaque LSAs of link-state-type 11 in TE which are flooded
throughout the AS ?

> bad idea, since you need the FECs to match prefixes in your IGP.

I am not really sure if CR-LDP doesn't seem to exist any more .. Nokia,
Nortel Networks and a lot of other giants are still actively involved in the
development of CR-LDP. But then i may be wrong !

> boxes always send an ERO I think?

I am not so sure if the boxes always send an ERO .. and i dont think Juniper
does that .. atleast they dont claim to do so !
btw whats YMMV ??

> I'm not sure that you have answered the question here?

Hmmm .. if there are no resources available at a *particular* LSR then why
can rerouting be done ??
I'm confused ..

Regards,
Mary

---

From: Giles Heron <[email-masked]>
Date: Fri, 07 Sep 2001 13:45:39 +0100

> Don't we use opaque LSAs of link-state-type 11 in TE which are flooded

TE is carried in type 10 LSAs.  So only flooded through the area.

> development of CR-LDP. But then i may be wrong !

When was the last time you saw a router built by Nokia or Nortel?

They are hardly "giants" in the TCP/IP world.

For better or worse CR-LDP is dead (at least wrt MPLS.)  Can't speak for
GMPLS.

> does that .. atleast they dont claim to do so !

Your Mileage May Vary.

From what I remember a certain other big router vendor always sends an
ERO.  But since I don't have one in front of me to test on I can't be
definitive right now :)

> Hmmm .. if there are no resources available at a *particular* LSR then why

But his question wasn't about re-routing?

It was about an LSP setup which hits a problem at an LSR which has
insufficient resources to complete the request.   In that case the LSP
setup fails, and the head-end LSR has to re-signal.

Giles

---

From: "Dave Humphrey" <[email-masked]>
Date: Fri, 7 Sep 2001 14:51:25 +0100

Juniper computes the ERO from the Traffic engineering database
the path signalled follows exactly that created by the ERO. If
it can't create it the LSP won't get set-up. JUNOS thus does
use the ERO.

Dave Humphrey

- -----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: 07 September 2001 13:46
To: Mareline Sheldon
Cc: [email-masked]
Subject: Re: several questions

Mareline Sheldon wrote:
> > you can divide the network topology into areas you can't actually
> > do 
TE
> > across those areas.  But there is ongoing work on multi-area TE
> > to 
fix
> > this...
> 
> Don't we use opaque LSAs of link-state-type 11 in TE which are
> flooded throughout the AS ?

> > > Explained above. You can use route summaries .. and hence
> > > proves 
that
> MPLS
> > And if you are using LDP (not CR-LDP, that doesn't seem to exist
> > in 
any
> > approximation of reality) to signal your LSPs then route
> > summaries 
are a
> Nortel Networks and a lot of other giants are still actively
> involved 
in the

For better or worse CR-LDP is dead (at least wrt MPLS.)  Can't speak
for
GMPLS.

> > > Please note that EXPLICIT_ROUTE object (ERO) is an optional
> > > objetc 
> contained
> > > in an RSVP PATH message. It is *only* when the ERO is present,
> > > the 
RSVP
> PATH
> > > message is forwarded towards the egress LSR along the path
specified by
> the
> I am not so sure if the boxes always send an ERO .. and i dont
> think 
Juniper

Your Mileage May Vary.

- From what I remember a certain other big router vendor always sends
an
ERO.  But since I don't have one in front of me to test on I can't be
definitive right now :)

> Hmmm .. if there are no resources available at a *particular* LSR
> then 
why

It was about an LSP setup which hits a problem at an LSR which has
insufficient resources to complete the request.   In that case the
LSP
setup fails, and the head-end LSR has to re-signal.

Giles

- --

---

From: "Mareline Sheldon" <[email-masked]>
Date: Fri, 7 Sep 2001 20:02:46 +0530

Pl. refer to the white paper by Chuck Semeria "RSVP Signaling Extensions for
MPLS Traffic Engineering" by Juniper Networks.
There in Pg. 11 it says very clearly under the section "Establishing an LSP
Tunnel" that "In addition to the LABEL_REQUEST object, an RSVP path message
can also contain a number of *optional* objects:" and there it mentions as
the first item "ERO-Can be added to specify the predetermined .. "

Pl. clarify

Regards,
Mary

----- Original Message -----
From: "Dave Humphrey" <[email-masked]>
To: <[email-masked]>; "Mareline Sheldon" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 07, 2001 7:21 PM
Subject: RE: several questions

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.0.4
>
> iQA/AwUBO5jQ3NDzf3p4iWAnEQIYaACfXATZC0bNAJxtxPwp+wuMBEiGIdMAn3LX
> i2R663upubi/2odETJMGyWmV
> =bAuS
> -----END PGP SIGNATURE-----

---

From: "Mareline Sheldon" <[email-masked]>
Date: Fri, 7 Sep 2001 20:12:00 +0530

> TE is carried in type 10 LSAs.  So only flooded through the area.

Previous work on TE support using the OSPF protocol has restricted the focus
to within an OSPF area. There is a draft by Venkatachalam which proposes a
new opaque LSA called the "TE Summary LSA" that helps propagate the traffic
engineering metric information across areas. For more details refer to
draft-venkatachalam-ospf-traffic-01.txt.

Mary

---

From: Giles Heron <[email-masked]>
Date: Fri, 07 Sep 2001 15:55:18 +0100

> draft-venkatachalam-ospf-traffic-01.txt.

Sure, as I said, there is work going on wrt multi-area TE.

But coming back to shipping code rather than unimplemented drafts, the
fact remains that type 10 LSAs are used to flood TE info, and that CSPF
is intra-area only...

Giles

---

From: "Dave Humphrey" <[email-masked]>
Date: Fri, 7 Sep 2001 16:07:58 +0100

As I understand it with nocspf specified the path is worked
out on a hop by hop basis at each transit router. With cspf
enabled a fully computed ERO is handed to RSVP in order for it'
to signal an exact path and no other.

Dave Humphrey

- -----Original Message-----
From: Mareline Sheldon [mailto:[email-masked]]
Sent: 07 September 2001 15:33
To: Dave Humphrey; [email-masked]
Cc: [email-masked]
Subject: Re: several questions

Pl. refer to the white paper by Chuck Semeria "RSVP Signaling
Extensions
for
MPLS Traffic Engineering" by Juniper Networks.
There in Pg. 11 it says very clearly under the section "Establishing
an
LSP
Tunnel" that "In addition to the LABEL_REQUEST object, an RSVP path
message
can also contain a number of *optional* objects:" and there it
mentions
as
the first item "ERO-Can be added to specify the predetermined .. "

Pl. clarify

Regards,
Mary

- ----- Original Message -----
From: "Dave Humphrey" <[email-masked]>
To: <[email-masked]>; "Mareline Sheldon"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 07, 2001 7:21 PM
Subject: RE: several questions

> > > But the opaque LSAs used for TE don't cross area boundaries. 
> > > So 
> whilst
> > > you can divide the network topology into areas you can't
> > > actually do
> TE
> > > And if you are using LDP (not CR-LDP, that doesn't seem to
> > > exist in
> any
> > > > in an RSVP PATH message. It is *only* when the ERO is
> > > > present, the
> RSVP
> > PATH
> > > But YMMV depending on the RSVP-TE implementation in your
> > > router. 
> Some
> - From what I remember a certain other big router vendor always
> sends an
> ERO.  But since I don't have one in front of me to test on I can't
> be definitive right now :)
>
> > > > traffic is transferred to it before the old LSP tunnel is
> > > > torn 
> down.
> > >

---

From: "Mareline Sheldon" <[email-masked]>
Date: Fri, 7 Sep 2001 21:23:28 +0530

I was talking of no cspf .. the question was a general one without involving
cspf !
Mary

----- Original Message -----
From: "Dave Humphrey" <[email-masked]>
To: "Mareline Sheldon" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 07, 2001 8:37 PM
Subject: RE: several questions

> iQA/AwUBO5jizdDzf3p4iWAnEQLVkQCfSZltW5SNSWgLmi1cMxb71oh1PN4AoJCW
> rPhBx0wa3KvDlb88FsfWWVaH
> =V8Ws

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 7 Sep 2001 09:34:48 -0700 (PDT)

Hi,

> it can't create it the LSP won't get set-up. JUNOS thus does

Assuming that how vendors implement stuff is of interest, it
behooves me to clarify: on Junipers, if CSPF is requested for
an LSP, what David said is true.

> > think Juniper

However, LSPs can be specified *not* to use CSPF, in which case
an ERO *may* be configured; if not, the Path message will not
have an ERO.

Kireeti.