The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] One LDP Implementation specific question of receivelabelmapping for prefix FECs
> > 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 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|