Subject: RE: [mpls] One LDP Implementation specific question of receive label mapping for prefix FECs

From: "Dutta, Pranjal" <[email-masked]>
Date: Tue, 11 Apr 2006 10:15:24 +0530

Hi Eric,
          As per RFC 3036 Label mapping receive procedures, when Ru
received a label mapping from Rd for a FEC x, Ru need to find an "exact"
match of the FEC x(IPv4/V6 prefix) in its route table. In Inter-IGP-area
or inter-AS case the routes from Rd would be summarized to Ru and in
such a case Ru MAY not find the exact match for such FEC x. In terms of
RFC 3036 then Ru MAY not find exact match for the FEC received from Rd
in its route table and no further action at Ru. My question was why Ru
can't we do a longest prefix match for the FEC x as LPM means it can be
reached by a downstream Rd? 

Thanks,
Pranjal

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]] 
Sent: Monday, 10 April, 2006 11:39 PM
To: Dutta, Pranjal
Cc: [email-masked]
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs 

> When Ru receives a label mapping for a FEC of type IPv4/v6 prefix from
Rd,
> the next hop  for the FEC can be determined after  route lookup. Now
here,
> for looking  up the  FEC at Ru  do we  need to do  exact match  or
Longest
> prefix match? It is quite possible that the prefix as FEC mapped by Rd
may
> be within a supernetted prefix at Ru. 

It's a  little hard  to understand what  you're asking.  By  definition,
one
cannot change the FEC in mid-LSP.  If  the FEC is an address prefix, and
you
reach a  point where that address prefix  is not in the  routing table,
then
the LSP terminates. 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Eric W Gray <[email-masked]>
Date: Tue, 11 Apr 2006 07:02:00 -0400

The implementation MUST do an exact match, as downstream LSRs will 
forward based
only on the label.  Because they do not (typically) perform a route 
look-up on the label
encapsulated inner IP packet, there is no reason to expect a downstream 
LSR to be able
to separate a flow based on longest match when the routes further 
downstream are distinct
for "longer matches".

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Apr 2006 10:22:53 -0400

I think that there may be a better way to explain this.  There are 
several different factors at work:

1) A received LDP label MUST NOT be used if the neighbor sending the 
label is not the next hop for the FEC.  This condition does not 
require an exact match in the forwarding table.
2) A Received label MUST NOT be used for packets which do not match 
the received FEC.  This condition requires an exact match in the 
forwarding table.

This does allow an implementation to create an exact match entry in 
the forwarding table to select packets that use the label, even if 
routing provided a shorter prefix.  This does allow one to use /32 
entries without injecting those /32s into the actual routing 
protocol.  However, the most common uses of .LDP (even with /32s) 
will result in the entries being in the forwarding table anyway.

Another way to look at the condition above is that condition 1 is a 
restriction on the use of a received label advertisement.  LPM check 
is suitable.  Condition 2 is a restriction on the contents of the 
Forwarding-Table-to-Next-hop-label-forwarding-entry that one 
creates.  That must be an exact match.

Yours,
Joel M. Halpern

At 07:02 AM 4/11/2006, Eric W Gray wrote:
>encapsulated inner IP packet, there is no reason to expect a 
>downstream LSR to be able

---

From: Eric Rosen <[email-masked]>
Date: Tue, 11 Apr 2006 13:50:04 -0400

> In Inter-IGP-area or inter-AS case  the routes from Rd would be summarized
> to Ru and in such a case Ru MAY not find the exact match for such FEC x

If I  understand your  example, Ru has  the summary  route, Rd has  the more
specific routes, and  Rd is sending Ru label bindings  for the more specific
routes  but not  for the  summary route.   You don't  say anything  about Ru
itself  distributing  labels  bindings  for  the more  specific  routes,  so
presumably the only thing  at issue is Ru should label an  IP packet that it
receives.  What will happen is that  the IP packet gets sent unlabeled to Rd
which then labels it according to the specific route which is the best match
to the packet's IP destination address.

The label imposition procedure here is: 

- get the IP destination address
- find  the prefix  in the routing  table which  is the best  match (longest
  match) for that destination address
- use the label  which was assigned to that prefix by  the LSR which routing
  says is the next hop for that prefix. 

It  doesn't make sense  for Rd  to bind  labels to  prefixes which  are more
specific  than  the  one in  the  routing  table,  as the  label  imposition
procedure will never make use of such labels. 

I don't think we want to allow  LDP to put prefixes in the routing table, or
else we'd  have to  treat it as  a second  routing algorithm and  that would
raise all kinds of issues.

It is possible though to imagine a different imposition procedure: 

- get the IP destination address, A

- find the prefix, P, in the routing table which is the best match (longest
  match) for that destination address

- get the next hop, N, for P, as specified by routing

- if N has distributed any label bindings for prefixes which are longer than
  P but begin with the same sequence of  bits as P, and if any of these, say
  Q, is a better match for A than  P, then use the label which N assigned to
  Q. 

This is a complicated procedure, though.   You can't just match A against Q,
because there might be some prefix  R in the routing table, with a different
next hop, which is  a better match for A than P is, but  not as good a match
as Q.  The above imposition procedure  says that the next hop for the packet
is determined  by the  route to  R not  by the route  to P  (or Q).   It's a
complex matter  to keep  the forwarding tables  in proper shape,  given that
prefixes like Q can come and go asynchronously. 

There are other  complications as well.  For example, what do  you do if you
get a packet  which is labeled for Q,  but the next hop has  changed and the
new next hop has not distributed a label for Q?  

I suppose we could figure all this out if there were an actual problem which
didn't have a better solution.

---

From: Eric W Gray <[email-masked]>
Date: Wed, 12 Apr 2006 07:44:36 -0400

Joel,

    What you're saying is true, but it is the answer to a different 
question.

--
Eric

Joel M. Halpern wrote:

> protocol.  However, the most common uses of .LDP (even with /32s) will 
> result in the entries being in the forwarding table anyway.
>
> Forwarding-Table-to-Next-hop-label-forwarding-entry that one creates.  
> That must be an exact match.
>
> Yours,
> Joel M. Halpern
>