Subject: RE: FEC next hop when FEC has multiple elements

From: Shahram Davari <[email-masked]>
Date: Wed, 2 May 2001 12:02:56 -0700

Hi Chris,

All FEC elements in an FEC-TLV, must have the same next hop. 

Yours,
-Shahram

> -----Original Message-----
> From: Chris Kuszmaul [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 1:45 PM
> To: [email-masked]
> Subject: FEC next hop when FEC has multiple elements
> 
> 
> 
>  Having studied the LDP spec., some code that attempts to implement
> the LDP spec, and several previous threads on the subject of FEC
> aggregation
> and deaggragation, I have formulated a little question, for which I am
> almost certain of the answer, but there is this nagging doubt.
> 
> 
>  In the LDP spec, in appendix A for the receive label mapping
> procedure, section A.1.2, page 101, we have:
> 
> LMp.11 Determine the next hop for the FEC
> 
> 
>  Suppose FEC1 is a set of n FEC elements: F1 and F2 ... Fn.
>  Suppose the next hop for F1 is the MsgSource, but for F2 ... Fn it
> is something else.
>  Suppose (for sake of specificity) we are in downstream unsolicited
> ordered
> advertisement mode.
> 
>  My take is that the next hop for FEC1 is NO ROUTE, and that the
> label being mapped is not used for switching/forwarding *at all*.
> 
> 
>  If my take is right, then
> 
> 
> 
> label_map(label, FEC, otherargs);
> 
>  Is not at all like:
> 
> for each ELEMENT in FEC:
>   label_map(label, ELEMENT, otherargs)
> 
>  Unless the next hop for each (or no) ELEMENT is MsgSource.
> 
> 
> 
>   So, is my take right?
> 
> 
>  Thanks to any who can respond!
> 
> CLK
> 
>

---

From: Chris Kuszmaul <[email-masked]>
Date: Wed, 02 May 2001 13:07:26 -0700

Hi Shahram,

 Thanks. Just to be clear: You are saying that the LSR that receives the
label mapping must check to see whether all the elements in the FEC-TLV have
the same next hop, since the LSR that advertised the label has no way of
knowing the next hop for the receiver of the mapping.

  In particular, the receiver of the mapping cannot simply compute the next
hop for the first FEC element in the FEC-TLV, and use that as the next hop,
relying on the assertion that all FEC elements in the TLV must have the same
next hop the guarantee must come from the receiver, not the sender.

  Is this correct?

 Thanks

CLK

---

From: David Charlap <[email-masked]>
Date: Wed, 02 May 2001 16:14:47 -0400

> All FEC elements in an FEC-TLV, must have the same next hop.

This is obvious, but I think the question is a little more involved than
this.

It is possible for a router to see a single next-hop for two different
prefixes, but its upstream router may see these prefixes as having two
different next-hops.  (I have worked out some topologies where this is
true, but they don't easily lend themselves to ASCII-art.)

The downstream router decides to aggregate the prefixes into a single
FEC and sends out a label mapping.  As far as the downstream router is
concerned, this is fine - if it receives packets for either prefix, it
will handle them identically.

The upstream router, upon receiving this label mapping realizes that the
sender is only next-hop for one of the prefixes, but someone else is a
closer next-hop for the other.

The question is what it should do with this.

IMO, the upstream router should reject the FEC (send back a label
release).  The FEC is malformed from its point of view, because the
prefixes don't all share a common next-hop.

Upon receiving the label release, the downstream router should realize
that the aggregation is improper, and should then send out two separate
mappings - one for each prefix.  The upstream router can then use one,
and either reject or hold on to the other (depending on the label
retention mode.)

Appendix A, however, is silent on what should happen in this situation.

-- David

---

From: Chris Kuszmaul <[email-masked]>
Date: Wed, 02 May 2001 15:17:54 -0700

Hi David,

 I am delighted to see we are thinking along the same lines. I agree with
your opinion of what ought to happen, but I feel that the spec, while
*unclear* is actually also unambiguous (and the spec also, largely, agrees
with what you think should happen). I think that a strict reading of the LDP
spec gives your basic interpretation (in the case of conservative label
retention the label is released, but in the case of liberal retention, I do
not think that anything in particular is required of the receiver of the
'bad' FEC in terms of notifying the sender). The 'strict' reading depends on
an interpretation of what a 'next hop' is for an FEC with multiple FEC
elements: That is: the next hop for FEC  F1 will be the same as for  FEC F2
if  they each represent the same 'packet set'.

 An FEC identifies the set of IP packets which may be mapped to the LSP
associated with the FEC. Suppose that the set of packets that F1 maps to its
LSP is the same set of packets that F2 maps to the same LSP. I submit that
the two FECs are 'equal'. In particular, that their next hop on a given
router always resolves to the same value.

 Now, I am hoping everyone is sort of twitching their fingers towards the
delete button thinking 'that's obvious' or 'that's circular' Hold on:

 Let F1 = { 1.1.1.0/24} (The set of FEC elements consisting of the single
prefix 1.1.1.x)
 Let F2 = {1.1.1.0, 1.1.1.1, 1.1.1.2,....,1.1.1.255} (The set of 256 FEC
elements that enumerate every possible address in 1.1.1.x)

 Now, obviously, these two are "equal" FECs, in terms of the set of packets
that get mapped to the LSP.

 Now, suppose LSR "N" receives a label mapping from LSR "E": <F1, Label1>
 Also, suppose that the next hop for 1.1.1.0 is "E", but the next hop for
every other element is "Q".
 As I understand it, this means that 'obviously' the next hop for 1.1.1.0/24
is a NOROUTE.
 Thus, by *definition*, on "E",  the next hop for F2  is NOROUTE as well.

 But some of my imaginary friends have intimated  that "N" should advertise
F3 = {1.1.1.0} to its peers. (In fact, I think this is not a bad intent, but
it seems contrary to the LDP spec)

CLK

---

From: Jack Brennen <[email-masked]>
Date: Wed, 02 May 2001 18:37:24 -0400

> that get mapped to the LSP.

Um, this may be intuitively "obvious" to some, but it's not really
correct
according to section 2.1 of RFC 3036 :-)

Let there be a third FEC in the picture:  F3 = { 1.1.1.16/28 }

Assume that the next hop for the entire 1.1.1.0/24 range is router R2.

If R2 sends me these label mappings:

       F1 -> Label A
       F3 -> Label C

then I forward anything in the F3 range using Label C, and the rest of
the
1.1.1.x range using Label A.

On the other hand, if R2 sends me these label mappings:

       F2 -> Label B
       F3 -> Label C

then I forward anything in the 1.1.1.x range using Label B.

This is because section 2.1 of the RFC calls for using the longest
prefix match.  1.1.1.16/28 is favored over 1.1.1.0/24, but
1.1.1.16/32 beats them both.

   Jack

---

From: Chris Kuszmaul <[email-masked]>
Date: Wed, 02 May 2001 16:32:18 -0700

Thanks Jack, I overlooked that point. But I do not think it alters the
conclusion about what the next hop should be for an FEC with multiple elements.

  F1 and F2 (below) are not fully equal, in the sense of 'substitution' in the
presence of competition. Indeed, they are not equal when in the presence of one
another, since F2 would get all the packets.  In fact, there is a whole raft of
senses in which they are not equal.

  However in the sense defined in, oh, say section 2.1 of RFC 3036 (;-)) they
*are* equal:

"The FEC defines the set of IP packets which may be mapped to that LSP."

 The FECs both represent the exact same set of packets that *may* be injected
into the LSP associated with the FEC.That is, if you take the largest possible
set of packets that could be injected into each (among all possible
configurations of other FECs), then you get the same largest possible set for
each. In such a situation, the next hop calculation for each FEC must be the
same.  Since the next hop calculation for an FEC ought not change as a function
of the presence of other competing FECs, this means that in all circumstances F1
and F2 must have the same next hop.

  But, I was indeed wrong when I said (without qualification) that the same set
of packets get mapped to the LSP (for F1 and F2). I owe you a (small) chocolate
mint.

CLK

---

From: Chris Kuszmaul <[email-masked]>
Date: Tue, 29 May 2001 15:44:38 -0700

Before a label can be mapped to an FEC that has already been mapped, the LSR
must release the old label (prompted perhaps by a withdrawal message). Thus, LDP
calls for a break-before-make on LSP updates.  It would seem a straightforward
matter for the protocol to include a withdraw-and-map message that performs this
sequence atomically, and so preserves a make-before-break condition.

  Is there some reason for not providing for this kind of functionality?

 Thanks for any comments.

CLK

PS: The careful reader will realize that I have mentioned this issue before in
the thread [Re: Receive Label Receive !!], but have not seen any reply. This is
an attempt to focus the question and broaden the pool of possible respondents.

---

From: Nagendra Singh Tomar <[email-masked]>
Date: Wed, 30 May 2001 09:35:05 +0530 (IST)

Hi!
   I cannot understand why an LSR (downstream) will need to withdraw  a
label mapping for a particular FEC from its upstream peer and send a new
mapping for the same FEC this time with a different label
(withdraw-and-map message). It can as well use the old (incoming) label
for whatever purpose it's planning to use the new label.
The only reason can be setting up of multiple equal-cost paths, which the
RFC says is not supported now.
I would like to know if there are any other implications.
 
-- tomar