Subject: RE: Question about interfacing Routing and LDP in MPLS systems?

From: Bora Akyol <[email-masked]>
Date: Thu, 9 Dec 1999 20:40:30 -0800

Zhong,

Unless labels are piggy backed in BGP, then the FECs that are associated
with LSPs are usually determined by configuration. A long long time ago,
Ipsilon's IP switch did this association dynamically.

Bora Akyol, Pluris
http://www.pluris.com/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 09, 1999 6:33 PM
To: [email-masked]
Subject: Question about interfacing Routing and LDP in MPLS systems?

Hello, everyone:

If a system is supporting routing protocols RIP, OSPF, and BGP all, how to
associate the routing information with the label in MPLS (the interface
between
the routing and LDP)?  For BGP, someone suggest using piggyback method. But
what
about OSPF? So far, I could not find any document on that. How to converting
the
routing information between those routing protocols?

Any suggestions will be appreciated.

Zhong Hu

Comsat Labs

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Dec 1999 07:57:10 -0500

Bora,

	Actually, there's absolutely no reason why it
can't be more dynamic than this.  Irregardless of the
routing protocols used to derive them, entries in a
route table should map very nicely to FECs as defined
in LDP.  Within a particular domain, most routers will
also have very similar route table entries - in terms 
of the address and prefix length (or mask) used to map
an entry to an MPLS FEC.

	Consequently, in DoD mode (for example), when
I derive a new route table entry, I would go to the 
next hop for that entry (if it is an LSR with which I
have an established LDP peer session) with a Label
Request - requesting a label for the FEC derived from 
the route table entry).  In the event that the route
table is fully populated prior to an implementation's
having established an LDP session with its peers, the
implementation can use the successful establishment of
the peer session as a trigger to go through the route
table looking for routes with this next hop, determine
if there is a label for this entry and request one if
there is not.  A DoD implementation should do this in
any case.

	In the DU mode, it's quite a bit simpler.  Any
time such an implementation derives a new route table
entry, it sends a Label Mapping to all but the next hop
for that route entry.

	In either mode, if a route entry is deleted,
the implementation sends a Label Withdraw to any of
it's peers that have an outstanding Label Mapping
(meaning one was sent and not yet released).

	This is considerably more dynamic than would
be the case if configuration was required.

---

From: [email-masked]
Date: Mon, 13 Dec 1999 12:21:29 +0100

Eric,

You have described a way to associate dynamically a FEC with LSP.

The method you have described fits well with the topology-driven 
scheme but not so well with the data-driven scheme (no need to go
through the route table when an LDP session has just been established).

Nevertheless, you say "A DoD implementation should do this in
any case".
Do you mean that the topology-driven scheme for label
assignment is mandatory in LDP ?

Regards.

Marie-Helene.

---

From: Eric Gray <[email-masked]>
Date: Mon, 13 Dec 1999 07:56:17 -0500

Marie-Helene,

	An underlying assumption in using basic LDP is
that topology drives LSP setup.  There is not a mode or
capability negotiation for topology verses flow driven
LSP setup.  Hence - while it is possible to support flow
driven LSP setup as an augmentation of the protocol - it
is not permissible to rely on it.

	What this means is that when two LSRs are using
DoD mode between themselves, the upstream peer must ask
for labels from the downstream peer rather than expect
the downstream peer to notice that it does not appear to
have them.

--
Eric Gray