The MPLS WG Archive

[Eric W Gray <ewgray2k@netscape.net>]

Joel,

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

--
Eric

Joel M. Halpern wrote:

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

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