The MPLS WG Archive

["Tiruveedhula, Kishore" <kishore@tenornetworks.com>]

  There is no way to configure targeted adjacency only for VC fecs.

I do agree that negotiating a session capability can be useful.

Regards,
Kishore

-----Original Message-----
From: Rahul Aggarwal [mailto:rahul@redback.com]
Sent: Thursday, June 06, 2002 9:16 PM
To: Vach Kompella
Cc: Mpls-wg
Subject: Re: Hello adjacency creation


The announcement of prefix FECs or VC FECs to a particular peer
is really driven by the information that the peer is interested in :

a) For prefix FECs, typically the existance of a LDP link level
hello adjancency with a peer implies that prefix FECs are to be
exchanged with that peer. However for certain reasons one may
explictly configure a targeted adjancency with a peer to exchange
prefix FECs. Eg : When a LDP session is being tunnelled.

b) For VC FECs, if a VC (Pseudo wire) is configured to a 
particular peer all that should matter is whether there is an 
adjacency to that peer. For directly connected LSRs this could well
be a link level adjacency. 

IMO this would be the driving factor of prefix FEC /VC FEC announcements.

Some more comments inline :

On Thu, Jun 06, 2002 at 12:47:48PM -0700, Vach Kompella wrote:
> Suppose there are two adjacent LSRs A and B which try to set up both
regular
> link-level LDP, as well as targeted LDP.
> 
>    -----         -----
>    | A |---------| B |
>    -----         -----
> 
> Only a single LDP session/TCP connection is established, but are two hello
> adjacencies set up?  Having only a single one would mean that if the
interface
> was brought down, the session would terminate.

Two hello adjancencies should be set up as per rfc3036.

> 
> Also, the existence of a targeted adjacency is typically for VC label
exchange
> or for tunneled next hop resolution, whereas link adjacency is typically
used
> for LSPs following the IGP.
> 
> Does one exchange VC labels over a session over which link adjacency only
has
> been set up?  That seems silly.  E.g., A and B exchange VC labels over a
> targeted session, but X and B have a (link) adjacency and an LDP session.
You
> wouldn't want B and X to exchange labels for martini VCs.

For directly connected LSRs if someone wants to do this, I don't see why it 
should be disallowed. For exchanging Martini labels one should only be 
interested in seeing if there is a peering session with the peer in
question.

> 
>    -----         -----          -----
>    | A |---------| X |----------| B |
>    -----         -----          -----
> 
> Finally, in the upper configuration, if A and B only have a targeted
adjacency,
> then shouldn't B avoid sending address FECs to A which doesn't really care
for
> them?

Only if A and B are not explicitly configured to exchange prefix FECs over
the
targeted session.

> 
> Since I couldn't find this behavior described in the RFCs, I propose a
default
> behavior for adjacency creation and scoping of FEC signaling so that:
> 1. parallel hello adjacencies are set up, even though only one session is
used
> to exchange labels, when both link and targeted adjacencies are requested
> 2. if only a link adjacency is established between a pair of LSRs, then
address
> FECs SHOULD be exchanged over the concomitant session, and no other FECs

> 3. if only a targeted adjacency is established between a pair of LSRs,
then
> non-address FECs SHOULD be exchanged over the session, and no other FECs

This doesn't sound right. One may be exchaning prefix FECs over a targeted 
session when a LDP session is being tunnelled for some reason.

> 4. if both adjacencies are set up, then all known FECs SHOULD be exchanged
> 
> Similarly, when adjacencies are torn down:
> 1. if no link adjacency exists, then all address FECs should be withdrawn
> 2. if no targeted adjacency exists, then all non-address FECs should be
> withdrawn
> 
> Does this make sense?  I have run across some behavior that doesn't quite
follow
> these rules, so if others are operating on other rules of behavior, could
we
> have some discussion on how to resolve this?  Thanks.
> 
> -Vach
>