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

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

> Bruno> A subsequent issue, is that  to continue the LSP further
upstream, Ru
> Bruno> should allocate a  new label and advertise the  specific FEC
upstream
> Bruno> to Ruu.
> 
> How does Ru know whether Ruu wants or needs this?

[Bruno D:] 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.
 
> Bruno> what is the  difference, from the FIB point of  view, between
one /30
> Bruno> pointing  to Rd  and four  /32 pointing  to Rd?   I believe
some FIB
> Bruno> implementation already represent a /30 as four /32
> 
> Do they also represent a /8 as 16,777,216 /32s?  ;-) I'm not sure we
want to
> require such an implementation.

[Bruno D:] No they don't ;-)  They can even handle a /8 and a more
specific /32 without de-aggregating 16,777,216 /32s !
However, regarding our proposition, there is no change compared to using
RFC 3036 and performing route leaking on ABR. In both cases, in the FIB,
you have an aggregated prefix and more specific ones.
 
> The issue is not the size of  the FIB, it's the complexity of the
procedures
> used to maintain the FIB.

[Bruno D:] Agreed. And the point of the discussion is to balance the
additional LDP implementation cost with the IGP protocol gain of not
carrying the specific prefixes.
Regarding the implementation cost, I suppose this may be implementation
dependant and I would welcome any information from people implementing
/having implemented LDP (either privately or publicly on the mailing
list).
Regarding the protocol gain, basically, instead of advertising the
specific prefixes once in the IGP and once in the LDP, we would only
advertise it once (in LDP, and LDP seems the good choice because MPLS
does need the specific FEC whereas IP can handle and benefit from
aggregation.). So the gain is globally a factor 2 in the control plane
(...with no gain for LDP and all the gain for the IGP, which makes it
more difficult to defend on the MPLS side ;-) ).
 
> Bruno> if populating the  FTN with specific FEC is found to  be an
issue, we
> Bruno> can only populate the ILM on all P routers.
> 
> I don't think the issues are any different.
 
> Bruno> For PE/ingress router, all we really need is BGP to be aware of
these
> Bruno> LSPs and be able to use them to reach the BGP Next Hops
> 
> I don't think that's a simplification.  But if that's what you want,
why not
> use RSVP-TE to create a tunnel to each potential BGP next hop?

 [Bruno D:] LDP creates multipoint to point LSP so scales in o(N).
RSVP-TE creates point to point LSP so scales in o(N^2).
But the point now is not whether we should have one or two protocols to
set-up LSPs. We have both and I believe we could equally extend both
protocols to be IGP area friendly.

> The underlying  issue in the L3VPN  application is, I  think, the
following.
> The  bottom label of  an L3VPN  data packet  has to  correspond to  a
VPN-IP
> route.  The  label above that has to  correspond to the router  which
is the
> BGP next  hop for that VPN-IP  route, i.e., it  has to correspond to
a /32.

[Bruno D:] Agreed. That is the case with our proposition: the /32 FEC is
advertised all the way from egress to ingress, and the /32 FEC exactly
matches the BGP next-hop which advertised the VPN route.

> Typically the IGP is made to carry /32 routes for anything that could
be the
> BGP next hop of  a VPN-IP route.  The worry is that  ultimately there
may be
> so many of  these that the IGP does  not scale well enough to  put all
these
> /32s in the FIBs of the P routers.  In that case, I don't think the
solution
> is to find some  other, more complex way to put all the  /32s in the
FIBs of
> the P routers.   I don't think that having a more  complicated way to
handle
> the same amount of information is going  to get us very far.  

 [Bruno D:] Indeed, if the limiting factor is the size of the FIB, our
proposition does not solve this. Otherwise, our proposition improves the
control plane scalability with -from the LDP specification point a view-
a very limited modification. 

> What we really want is a hierarchical  solution

[Bruno D:] I suppose it depends who you mean by "we" ;-)

> in which a third label is  used to get the
> packets to a point where the second label is known.

[Bruno D:] The hierarchical solution has its own pro & con.
FIB scaling (especially on the P routers) is indeed a key advantage. One
disadvantage is that if some kind of a LDP/IP FRR solution is
implemented, the intermediate point is difficult to fast protect.

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

---

From: Eric Rosen <[email-masked]>
Date: Fri, 14 Apr 2006 12:51:45 -0400

> In Downstream Unsolicited label advertisement mode, Ru does

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. 

> there is no change compared to using RFC 3036 and performing route leaking
> on ABR. In both cases, in the  FIB, you have an aggregated prefix and more
> specific ones. 

I didn't say that your proposal adds  more prefixes to the FIB than it would
have if the  the /32s were carried  by OSPF.  I said that  the management of
the forwarding table  is made more complicated, because  we now have entries
which are  jointly managed by two  different protocols which  have a complex
relationship with each other.

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

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.   I also
don't see that this is yields  a better set of tradeoffs than a hierarchical
soltuion.

---

From: Eric W Gray <[email-masked]>
Date: Mon, 17 Apr 2006 17:16:58 -0400

I think Eric Rosen sums this up nicely.

--
Eric Gray