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

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 10 Apr 2006 11:25:40 +0200

Hi Pranjal, all,

That's a good question; thanks for asking ;-)

Currently, as per RFC 3036 section 3.5.7.1, Ru should perform a longest match.
But we believe that in some situation (eg use of IGP areas), we could benefit from doing a longest match as this would relax the need for leaking in the IGP all the /32 prefixes across area boundaries. To initiate discussion on this point, we've written draft-decraene-mpls-ldp-interarea-01.txt and presented it in Vancouver ( http://www3.ietf.org/proceedings/05nov/slides/mpls-4.pdf )

Right after this presentation, it was suggested to gather feed-back on the usefulness of this ID before moving forward. 

Pranjal, all, could you please tell us whether you think that it is worth being pursed?

Best regards,
Bruno

________________________________________
From: Dutta, Pranjal [mailto:[email-masked]] 
Sent: Saturday, April 08, 2006 10:11 PM
To: [email-masked]
Subject: [mpls] One LDP Implementation specific question of receive labelmapping for prefix FECs

Hi,
               I have a basic confusion on the "Label Mapping Receive Procedure" explained in the appendix of RFC 3036. One step says "Find the FEC next hop". 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. The reason why I am asking is I guess the implications could be different based on whether LSR is merge capable or non-merge capable.

Thanks in advance,
Pranjal

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

---

From: Bob Thomas <[email-masked]>
Date: Mon, 10 Apr 2006 07:19:25 -0400

Hi Bruno,

> Currently, as per RFC 3036 section 3.5.7.1, Ru should perform a longest =
> match.

I think you meant exact match.

  draft-ietf-mpls-rfc3036bis-03.txt:

   An LSR receiving a Label Mapping message from a downstream LSR for a
   Prefix SHOULD NOT use the label for forwarding unless its routing ta-
   ble contains an entry that exactly matches the FEC Element.
                              ***************

Bob

> But we believe that in some situation (eg use of IGP areas), we could =
> benefit from doing a longest match as this would relax the need for =
> leaking in the IGP all the /32 prefixes across area boundaries. To =
> initiate discussion on this point, we've written =
> draft-decraene-mpls-ldp-interarea-01.txt and presented it in Vancouver ( =
> http://www3.ietf.org/proceedings/05nov/slides/mpls-4.pdf )
> 
> Right after this presentation, it was suggested to gather feed-back on =
> the usefulness of this ID before moving forward.=20
> 
> Pranjal, all, could you please tell us whether you think that it is =
> worth being pursed?
> 
> 
> Best regards,
> Bruno
> 
> 
> 
> From: Dutta, Pranjal [mailto:[email-masked]]=20
> Subject: [mpls] One LDP Implementation specific question of receive =
> labelmapping for prefix FECs
> 
> Hi,
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I have a basic confusion on =
> the "Label Mapping Receive Procedure" explained in the appendix of RFC =
> 3036. One step says "Find the FEC next hop". 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 =A0prefix at Ru. The reason why I am asking is I guess the =
> implications could be different based on whether LSR is merge capable or =
> non-merge capable.
> 
> Thanks in advance,
> Pranjal
> 
>