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 14:10:46 +0200

Hi Bob,
 
> Hi Bruno,
> 
> > 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.
> 
> I think you meant exact match.

[Bruno D:] Indeed. Thanks for the rectification.

>   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
> > 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,
> > =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
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mpls
> >

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

---

From: "David Allan" <[email-masked]>
Date: Wed, 12 Apr 2006 13:12:58 -0400

Hi Eric:

Agree that it is not a situation that should ever arise in a persistent fashion....

Looked at this a few years ago and concluded that with independent mode label distribution, you could get scenarios where there were mismatches in how specific a FEC was vs. what was in the routing LSAs, but that would be a race condition and hooking any mismatches together would be a bad idea....e.g. FECs had to be exact match in order to hook FTN/ILM to NHLFE, and you needed specific routing information to install NHLFE in the first place...

So I agree that implementation wise, if there is a mismatch, then waiting is the ideal response, the condition would go away...

cheers
Dave

> -----Original Message-----
> From: Eric W Gray [mailto:[email-masked]] 
> Sent: Wednesday, April 12, 2006 12:48 PM
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: [mpls] One LDP Implementation specific question 
> of receive labelmapping for prefix FECs
> 
> 
> If I understand the problem under discussion correctly, this is the 
> basic scenario:
> 
>          LSR-1 (Ru) -----> LSR-2 (Rd)
> 
> The initial question was related to how LSR-1 handles a label mapping 
> received
> (presumably in downstream unsolicited label advertisement 
> mode) from LSR-2, for a FEC corresponding to an aggregate 
> route (e.g. - 10.1.0.0/16) - if  
> LSR-1
> does not have an exact match route entry.
> 
> Assuming that both LSRs are functioning properly and LSR-2 is 
> using LDP 
> to send
> unsolicited label mappings for FECs that correspond to routes it has 
> advertised, it
> is unlikely that this situation will arise.  LSR-1 would only receive 
> label mappings -
> from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 
> - at least).
> 
> An implementor might decide to incorporate a delay prior to 
> making this 
> check, in
> order to eliminate some potential race conditions.  And 
> implementors may 
> disagree
> as to what it means for LSR-1 to have an entry.  But - bottom 
> line - if 
> the check
> for an exact match between FEC and route entry finds that 
> such an entry 
> does not
> exist in an LSR, the corresponding label must not be used.
> 
> The procedures for handling label mappings are - in part - 
> intended to 
> provide for
> robustness in the event that another LSR is not functioning properly.
> 
> Much of the discussion surrounding this question has been 
> about complex 
> things
> an implementation might do.  None of these things are fundamentally 
> incompatible
> with the procedures as written.
> 
> --
> Eric
> 
> Joel M. Halpern wrote:
> 
> > The basic question is how much complication an implementation wishes
> > to undertake to allow for the mismatch.
> > Note that such mismatches are rare.
> >
> > As a local matter, an implementation can chose to create 
> the FTN entry
> > for the exact match, and keep track of the relationship 
> between that 
> > entry and the actual routing entry.  Eric has argued that such is 
> > undesirable complication.  I would tend to agree with him in the 
> > abstract.  What you choose to do in your implementation may depend 
> > upon your structures and on what problems you confront in 
> the field.  
> > Creating the local entries and using them is legal.  Such entries 
> > would not affect routing advertisements.  They probably don't even 
> > effect label advertisements.
> >
> > Yours,
> > Joel M. Halpern
> >
> > At 04:45 PM 4/11/2006, Dutta, Pranjal wrote:
> >
> >> 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:[email-masked]]
> >> Sent: Tuesday, 11 April, 2006 7:53 PM
> >> To: Dutta, Pranjal
> >> Cc: [email-masked]
> >> 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
> >> >
> >
> >
> >
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mpls
> >
> >
> >
>

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Wed, 12 Apr 2006 19:18:14 +0200

Eric,

> (presumably in downstream unsolicited label advertisement mode) from
LSR-2,
> for a FEC corresponding to an aggregate route (e.g. - 10.1.0.0/16) -
if
> Assuming that both LSRs are functioning properly and LSR-2 is using
LDP
> is unlikely that this situation will arise.

[Bruno D:] That is correct if Ru and Rd are in the same IGP area.
Otherwise, if IP aggregation is performed between areas, Ru and Rd may
not have the same IP route knowledge. In particular, if Rd is an Area
Border Router, it may aggregate IP reachability information send to Ru.
Therefore, Rd will not advertise the specific IP route to Ru. You may
also have a look at section 4.1 of
draft-decraene-mpls-ldp-interarea-01.txt for more details on this use
case.

>  LSR-1 would only receive
> label mappings -
> from LSR-2 - for routes it (LSR-1) knows of (also from LSR-2 - at
least).
> 
> An implementor might decide to incorporate a delay prior to making
this
> check, in
> order to eliminate some potential race conditions.  And implementors
may
> disagree
> as to what it means for LSR-1 to have an entry.  But - bottom line -
if
> the check
> for an exact match between FEC and route entry finds that such an
entry
> The procedures for handling label mappings are - in part - intended to
> provide for
> Much of the discussion surrounding this question has been about
complex
> > As a local matter, an implementation can chose to create the FTN
entry
> > for the exact match, and keep track of the relationship between that
> > upon your structures and on what problems you confront in the field.
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
> >>
receive
> >> label mapping for prefix FECs
> >>
> >> 1) A received LDP label MUST NOT be used if the neighbor sending
the
> >> 2) A Received label MUST NOT be used for packets which do not match
> >> This does allow an implementation to create an exact match entry in
> >> 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
> >> Forwarding-Table-to-Next-hop-label-forwarding-entry that one
> >> creates.  That must be an exact match.
> >>
> >> Yours,
> >> Joel M. Halpern
> >>
> >> >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
> >> >>           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"
> >> >>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

---

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Fri, 14 Apr 2006 20:16:16 +0200

> > In Downstream Unsolicited label advertisement mode, Ru does
> > not know what Ruu wants or needs. Ru always propagates the FEC
upstream
> > and Ruu uses it if needed.
> 
> So once some node decides to  do this "LDP de-summarization", there's
no way
> to stop  it until you  reach the  border of the  MPLS domain?  I
think we'd
> probably  end  up  with  a  bunch of  configuration  knobs
controlling  LDP
> desummarization, similar to the knobs controlling IGP summarization.

[Bruno D:] In most implementation, there is already the ability to use
route-map to control the advertisement of LDP FEC. We are using them in
our networks to restrict the advertisements.
Besides, the proposed modification would be optional. If you don't turn
it on, you still have the current behavior (FEC gets stop at area
boundaries).
 
> > instead of advertising  the specific prefixes once in the  IGP and
once in
> > the LDP, we would only advertise it once
> 
> I  don't think  this is  a meaningful  comparison.  LDP  does  not
currently
> advertise  prefixes, it advertises  label bindings.   In your
proposal, new
> functionality is added so that LDP does advertise prefixes.  Thus the
number
> of "prefix advertisements"  stays the same.  You're merely  shifting
some of
> the prefix  advertisement burden  from one protocol  to the other.
And the
> work  of   managing  those  prefixes   in  the  forwarding  table   is
more
> complicated. All  that really gets saved  is the work required  to
parse the
> OSPF messages.

[Bruno D:] OK, I should have use exact terms. My mistake. As an example,

In one hand you advertise 1000 specific prefixes in the IGP and 1000 FEC
& labels in LDP.
On the other hand you advertise 1 to 10 aggregated prefixes in the IGP
and 1000 FEC & labels in LDP.

There is definitely a gain for the IGP (especially for the ABRs which
need to redistribute all the prefixes in a single LSA/LSP). But there is
no gain plus an additional complexity for LDP.

> I guess my problem is that I  see the additional complexity, but I
don't see
> the data showing that, as a result  of adding this complexity, we gain
a big
> improvement in  the number of  /32s to which  we can assign labels.   

Thanks for raising this additional complexity which is indeed not
described in the current version of the draft. 
I agree that this is difficult to evaluate the overall scalability gain
without measurement on a prototype or by simulations.
Two others points can be taken into consideration and are pertinent for
our deployment:
- in some areas, especially in the edge/backhaul, not all router may
need MPLS. For them the gain is easy to measure.
- in some areas, the network may already be running and the point is to
add inter-area MPLS for additional services. Without the proposed
modification, the impact on the IGP (and potentially to weaker
equipment) is certain and significant. Not to mention the need to change
the IP routing policy (currently, aggregation is performed on ABR)

> I also don't see that this is yields  a better set of tradeoffs than a
hierarchical
> soltuion.

[Bruno D:] I would say that this yields to a different set of tradeoffs,
which may better fit in some deployments.

Regards,
Bruno