Subject: Re: Address Message in LDP

From: Bob Thomas <[email-masked]>
Date: Tue, 06 Jun 2000 08:54:59 -0400

Santosh,

>     In draft-ietf-mpls-ldp-06.txt, there is an Address Message and =
> Address Withdraw Message. I am not able to figure out what purpose does =
> it serve. In the Hello packet that an LSR sends, it can send the =
> Interface IP Address optionally. If it doesnt send then the receiving =
> LSR can make out when it receives from the particular socket. And what =
> do we gain if an LSR advertizes IP Addresses of other interfaces also ? =
> The connection between 2 LSRs is anyway thru some particular interface =
> and knowing the IP Address of other interfaces will be of no use.

See Section "LDP Identifiers and Next Hop Addresses".

Bob

---

From: "Surekha Gupta" <[email-masked]>
Date: Tue, 6 Jun 2000 19:30:19 +0530

Hello Bob
    I have gone thru the section but still have a doubt. Even in DownStream
unsolicited Mode of label distribution, according to the draft each LSR
keeps a list of address prefix and their associated  (LDP Identifier, label)

LDP Identifier = Interface IP Address : Label Space.

Actually the Next hop address in the routing table will exactly match the
"Interface IP Address" specified in the LDP Identifier. This "Interface IP
Address" is the one directly connected to the peer.
This is depicted below.

                                            C
                                      /
                                A   -----  | B |
                                      \
                                            D

If B,C,D are directly connected to A then the "Interface IP Address" that
will be specified in the Address Message will be the same as the Interface
which A concludes from the HELLO message exchange. So what is the need for a
seperate "Address Message" altogether ?

One more thing, what is the use of specifying some other "Interace IP
Address" to A by B (say the interface of B with C ) if that is not the
directly connected interface to A?

---

From: Bob Thomas <[email-masked]>
Date: Tue, 06 Jun 2000 10:07:54 -0400

Santosh,

> LDP Identifier = Interface IP Address : Label Space.

There is no guarantee/requirement that the first 4 octects of the
LDP Id is the IP address of the "Interface".

> "Interface IP Address" specified in the LDP Identifier. This "Interface IP

I think you cannot guarantee that this is always true.

> seperate "Address Message" altogether ?

Please see comments above.

Bob

---

From: "Santosh Gupta" <[email-masked]>
Date: Tue, 6 Jun 2000 18:06:04 +0530

Hello
    In draft-ietf-mpls-ldp-06.txt, there is an Address Message and Address Withdraw Message. I am not able to figure out what purpose does it serve. In the Hello packet that an LSR sends, it can send the Interface IP Address optionally. If it doesnt send then the receiving LSR can make out when it receives from the particular socket. And what do we gain if an LSR advertizes IP Addresses of other interfaces also ? The connection between 2 LSRs is anyway thru some particular interface and knowing the IP Address of other interfaces will be of no use.

santosh

---

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

My understanding is that the list of addresses messages given to me by a
peer will allow me to answer the question if this peer "is the nexthop" for
a particular route.  This allow me to know whether or not I should install
a mapping the peer has given me.  What if ... the address that I match
(which was given to me by the peer) is from a differnt labelspace then the
label he has allocated to me?  Maybe a picture will help.

   ---------                 ---------
  |         |A11---------A21|         |
  |   R1    |               |    R2   |------ FEC
  |         |A12---------A22|         |
   ---------                 ---------

-A21 means R2's 1st address.
-each interface has a labelspace that matches the address number
 (thus R2 has 2 labelspaces it allocates from 21,22)
-R1 and R2 have two LDP sessions
-R1 session with R2:21 has A22,A21 for an address list
-R1 session with R2:22 has A21,A22 for an address list

-R1 has a routing table of:
 Prefix     outif      nexthop
 FEC        A11        A21

R2:22 allocates a label(L1) in labelspace 22 and send the mapping to R1.
R1 gets the mapping and searches the address list for R2:22 and finds that
the next hop of A21 is in R2:22 address list, so it installs the label out
A12 for FEC.

-R1 now has a FTN that looks like:
 Prefix     outif      nexthop   label
 FEC        A12        A22       L1

I can see avoiding this problem if the check for "is the nexthop" also takes
into consideration the outgoing if.  How would that work in targeted mode?

I think this can be solved for both modes by limiting the address messages 
R2:22 gave to R1. Why not only give out the addresses of the interfaces that
match the labelspace you are advertising?

Jim
-- 
James R. Leu

---

From: Bob Thomas <[email-masked]>
Date: Wed, 07 Jun 2000 11:33:26 -0400

Jim,

> label he has allocated to me?  Maybe a picture will help.

I think you are making this more complicated that it need be.

The purpose of the Address Message is to make it possible for an LSR
to establish a mapping between the first 4 octets of a peer's LDP Id
and addresses bound to the peer.

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

Bob

---

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

On Wed, Jun 07, 2000 at 11:33:26AM -0400, Bob Thomas wrote:

<snip>

> hop for a particular prefix.

I understand your second statement (the first about me making it more
complicated then it need be is always true :-).  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?

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.

If I have LDP sessions over parallel links and a particular prefix is
preferred over only one link, the peer closer to egress may provide mappings for
this prefix via both sessions.  If I use the address list as my definitive
source for which session is the next hop, both sessions will match.

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?

Jim
-- 
James R. Leu

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 08 Jun 2000 07:35:34 -0400

Jim,

From: "James R. Leu" <[email-masked]>
Subject: Re: Address Message in LDP
Date: Wed, 7 Jun 2000 13:14:29 -0500

> a particular session is ACTUALLY the next hop for a particular prefix?

In the case of parallel links between directly connected LDP peers,
there is another method to obtain the correct mapping between the next
hop and a session:

1. Find an interface that matches the next hop.

2. Find an LDP peer that matches the interface found in step 1.
   Since the interface is on a point-to-point link, at most one LDP
   peer will match that interface.  Note that the mapping between
   an LDP peer and an interface is determined during LDP Link Hello
   message exchange.

I think this method is useful in the case where there is a possibility
that two or more LDP peers on the same neighboring LSR may advertise
overlapping address lists in their Address messages.  Of course, this
is not necessaly if the implementation is good (or complicated?) 
enough to advertise non-overlapping address lists.

Yoshihiro Ohba