Subject: RE: Address Message in LDP

From: Eric Gray <[email-masked]>
Date: Wed, 7 Jun 2000 12:30:54 -0700

Jim,

> -----Original Message-----
> From: James R. Leu [mailto:[email-masked]]
> Sent: Wednesday, June 07, 2000 11:14 AM
> To: Bob Thomas
> Cc: [email-masked]
> Subject: Re: Address Message in LDP
> 
> 
> On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:
> 
> <snip>
> 

... <more snip> ...

> > 
> > This mapping is useful in determining whether the peer is the next
> > hop for a particular prefix.
> 

... <and more snip> ...

> With respect to the third statement, are you saying 
> that this mapping is or is not the ONLY way to figure 
> out if a peer is the next hop for a particular prefix?

Of course it is not the only way.  For one thing,
it is possible to configure this information.

(Bob does not have my warped sense of humor - if 
he meant "required" he would not have said "useful")

> 
> My goal is to get an answer about "non-Directly Connected 
> LSRs" and how they guarantee that they are distributing 
> labels and installing them on the correct interfaces.
> 
> The way to get the above answer may involve or mimic the way 
> we deal with mappings over parallel links between two 
> directly connected LDP peers.

There are numerous issues with this.  One of them is
the assumption of multiple parallel links between two
LDP peers - which necessarily implies the use of the
platform wide label space (as Shahram points out).

A second issue is that there is an element of risk if 
you stack a label provided by an indirectly connected 
LSR peer and you are not able to detect when the LSP 
over which you will forward the label-stacked packets 
is not a continuous LSP.  This implies that you should
signal the LSP between the two indirectly connected 
LSR peers using some approach that will A) not allow
the LSP to be established except as a continuous LSP
and B) indicate to the LSR establishing the LSP when
the LSP is broken.

A third issue is - if the label is platform wide - 
how do you prevent this label from being misused?

I'm sure there are other issues as well.

> 
> ...
>
> What other information do we use in this case to decide 
> whether or not a particular session is ACTUALLY the next 
> hop for a particular prefix?

I sense that this is an area in which many people
are still confused.

I think it will clear things up a little if it is
understood that the Address and Address Withdraw
messages would not be as useful if it were possible
to use the IGP to piggy-back labels.  But, then, we
would not be defining LDP as stand-alone signaling
protocol (or at least not for the same reasons).

Because LDP label distributions are not carried in
the routing advertisements to which they might be
said to apply, we need some way to associate labels
and route advertisements.  Since a next hop address
given in a route advertisement may not be the same
as the address that we know the associated LDP peer
by, we can benefit from use of Address and Address
Withdraw messages.  These messages allow us to know
what next hop address(es) might appear in route
advertisements that apply to an LSR peer and the
labels it distributes.

Does this help?

> Jim
> -- 
> James R. Leu

---

From: "James R. Leu" <[email-masked]>
Date: Wed, 7 Jun 2000 17:13:11 -0500

On Wed, Jun 07, 2000 at 12:30:54PM -0700, Eric Gray wrote:

<snip>

> platform wide label space (as Shahram points out).

Even though the downstream sessions uses a plateform wide label space that
STILL doesn't solve the problem when one of the upstream session receives a
mapping.  The upstream needs to decide if the downstream session that it
received the label from is running over the link that corresponds to the TRUE
next hop.

Jim
-- 
James R. Leu

---

From: "Santosh Gupta" <[email-masked]>
Date: Thu, 8 Jun 2000 17:29:21 +0530

Jim,

> received the label from is running over the link that corresponds to the
TRUE

If the TRUE next hop is one of the 2 interfaces, then it should be the TRUE
one. But in case if it is not one of the 2 interfaces which are not directly
connected then you can choose any one of the 2 and it will work. You install
the
Incoming interface/label ---------> Outgoing Interface/Label
into the switch. Once data starts coming, it doesnt matter if it goes to the
peer on link1 or link 2 if you have seperate LDP sessions on both, though
one of the paths might be less costly.

santosh