The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

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

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

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