The MPLS WG Archive

["Jim Guichard" <jguichar@cisco.com>]

> >-----Original Message-----
> >From: Vach Kompella [mailto:vkompella@timetra.com]
> >Sent: Thursday, June 06, 2002 4:33 PM
> >To: Jim Guichard; Mpls-wg
> >Subject: RE: Hello adjacency creation
> >
> >
> >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?

do you mean what do I think the behavior should be ? or what the behavior
should be based on what the RFC says ?

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

a targeted LDP session will only be established if specifically configured
so the default behavior is no targeted session. If a targeted session is
configured then the default behavior is to send hello's across the adjacency
and maintain the LDP session should the link between the two LSRs fail (and
an alternate path be available).

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

imo I would say so

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

It would seem reasonable to only exchange the label space that is relevant
to the adjacent peer, but this is my opinion and not what the RFC says.

> >>
> >> > >
> >> > >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).

I am not sure what you mean - if you have a TE tunnel in the core of the
network and you have to maintain an LSP between two edge devices then you
must run LDP on the TE tunnel so that the packets can be corrected switched
when exiting the tunnel - my point was that you cannot dictate that targeted
LDP carries non-address FECs only. Jim

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