The MPLS WG Archive

["Vach Kompella" <vkompella@timetra.com>]

Thanks for the response.  One thing I want to clarify about the principle of my
initial question: in lieu of any other information (e.g., policies, new TLVs or
vendor-specific TLVs for identifying the nature of FECs to be disseminated),
what SHOULD the behavior be?

-Vach

> -----Original Message-----
> From: Jim Guichard [mailto:jguichar@cisco.com]
> Sent: Thursday, June 06, 2002 1:22 PM
> To: Vach Kompella; Mpls-wg
> Subject: RE: Hello adjacency creation
>
>
> Hi Vach,
>
> > >
> > >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.
>
> there is nothing to stop targeted LDP being used to maintain the LDP
> topology should a link failure occur.

Agreed, but is this the default (expected) behavior?

>
> > >
> > >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.
>
> perhaps not, but they will as there is nothing in LDP to tell the peer which
> types of labels you want to receive.

But we do want to limit this distribution of unnecessary FECs, don't we?

>
> > >
> > >   -----         -----          -----
> > >   | 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?
>
> imo yes, but currently B will send everything to A unless you filter.

Again, I'm asking if it is reasonable to impose some reasonable limits.

>
> > >
> > >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:

> > >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
>
> you cannot do this as it will break certain traffic engineering scenarios -
> you may want to exchange address FECs.

So make the TE scenarios driven by directives (either signaled or configured).

>
> > >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?
>
> yes and no :) I think that the way to deal with this is to add some kind of
> signaling during session setup so that two LSRs can indicate which type of
> FECs they wish to exchange .. Jim

My point exactly.  If we define a baseline behavior that we don't have to
signal, then we can add optional signaling to extend the signaling behavior over
the session.