The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Hello adjacency creation
Hi Vach, > >-----Original Message----- > >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vach > >Kompella > >Sent: Thursday, June 06, 2002 3:48 PM > >To: Mpls-wg > >Subject: Hello adjacency creation > > > > > >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, 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 > >was brought down, the session would terminate. right, and therefore we want to maintain targeted LDP so that we can prevent the removal of all the label space. > > > >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. > > > >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. > > > > ----- ----- ----- > > | 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. > > > >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 this is the case today. > >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. > >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 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
|
|