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> 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. The issue is not the size of the FIB, it's the complexity of the procedures used to maintain the FIB. 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? 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. 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. What we really want is a hierarchical solution, in which a third label is used to get the packets to a point where the second label is known. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
|
|