The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Apr> msg00039



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs

  • From: "Dutta, Pranjal" <pdutta@riverstonenet.com>
  • Date: Wed, 12 Apr 2006 02:15:06 +0530
  • Cc: mpls@ietf.org
  • Thread-Index: AcZdc4SPjqaNm3wITr+NR0K1ZKa/7wAMEhwA
  • Thread-Topic: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id k3BKkwH26423

Thanks for the explanation on this.

Let me elaborate a scenario based on the rules that you mentioned.

For the procedure of label_map_received we have to apply both the rules
1) and 2) right. For rule one, If Ru gets a label from Rd and Rd is NOT
the next hop for the FEC. How Ru decides that the FEC is not next hop
are 
a) FEC exactly matches a route entry but next hop is another LSR or b)
As per your rule one FEC matches LPM to a shorter prefix P, and Rd is
not next hop for the matched prefix P. Lets say we hit issue b) and due
to liberal retention at Ru it retains the label but will not be used for
forwarding.

Now let's say that routing at Ru changes and now Rd becomes next hop for
Prefix P. So now Ru should introduce an entry for the FEC into
forwarding table and install the NHLFE entry right? But that violates
your Rule 2 then
as the exact match condition should be met. If we apply rule 2 now, then
we shouldn't use the label from Rd although Rd has become the next hop
for Prefix P. Please correct me if I am wrong in this.

Regards,
Pranjal

-----Original Message-----
From: Joel M. Halpern [mailto:joel@stevecrocker.com] 
Sent: Tuesday, 11 April, 2006 7:53 PM
To: Dutta, Pranjal
Cc: mpls@ietf.org
Subject: Re: [mpls] One LDP Implementation specific question of receive
label mapping for prefix FECs

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:
>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".
>
>Dutta, Pranjal wrote:
>
>>
>>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
>



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls