Subject: RE: Hello adjacency creation

From: "Jim Guichard" <[email-masked]>
Date: Thu, 6 Jun 2002 16:45:36 -0400

> >-----Original Message-----
> >From: Vach Kompella [mailto:[email-masked]]
> >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:[email-masked]]
> >> 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.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 6 Jun 2002 13:16:02 -0700

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

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.

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

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 6 Jun 2002 13:33:27 -0700

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

> perhaps not, but they will as there is nothing in LDP to tell the peer which

> you cannot do this as it will break certain traffic engineering scenarios -

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

> 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

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.

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 6 Jun 2002 13:53:18 -0700

Hi Jim/Vach,

[snipped]

> FECs they wish to exchange .. Jim

I am not sure if this is needed to solve this case. A targeted adjacency
is used to send either VC FECs (if a pseudo wire is configured to a peer)
or for tunneling a regular LDP session (eg. for TE). Both these cases
are driven by some configuration. By default prefix FECs should not be
exchanged over a targeted session.

As far as exchanging VC FECs over a link adjancency is concerned, if two
peers are directly connected, I don't see a problem with this. Else ofcourse
one needs a targeted adjancency.

On the other hand I do agree that exchanging a session capability can be 
useful.

> 
>   I have run across some behavior that
> > >doesn't quite follow

---

From: "Jim Guichard" <[email-masked]>
Date: Thu, 6 Jun 2002 16:22:21 -0400

Hi Vach,

> >From: [email-masked] [mailto:[email-masked]]On Behalf Of Vach
> >Kompella
> >Sent: Thursday, June 06, 2002 3:48 PM
> >To: Mpls-wg
> >Subject: Hello adjacency creation
> >
> >
> >Only a single LDP session/TCP connection is established,

this is correct.

 but are
> >two hello
> >adjacencies set up?

yes - hello's will be sent across each adjacency.

  Having only a single one would mean that if
> >the interface

right, and therefore we want to maintain targeted LDP so that we can prevent
the removal of all the label space.

> >to exchange labels, when both link and targeted adjacencies are requested

this is the case today.

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 6 Jun 2002 12:47:48 -0700

-----         -----
   | A |---------| B |
   -----         -----

   -----         -----          -----

-Vach