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
> 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 mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|