Hi Bruno, Please find my comments inline below [Mingui].
>You have added pwe in cc. I'm not sure why as I'm following up on your >presentation during L3 VPN WG on L3 VPN PE protection. [Mingui] Sorry that I didn't explain the reason every time. There was a companion draft presented in pwe3 for this l3vpn-PE-protection draft. Pwe3 WG determined they also need know the progress of this l3vpn draft. >[Bruno] First, consider that in a "POP" there may be multiple PE, i.e. more >than >the 2 required for the dual homing. Let's say 5 PE. >The number of RG is flexible, but this also comes with drawbacks. >One option is to have a single RG. In this case, you indeed need a single vNH >but >you require global label allocation for the perimeter of those 5 PE. Which >roughly >divide the available label space by 5. [Mingui] That is a misinterpretation. Actually, all 5 PEs share the same label range (e.g., 1~1100) rather than dividing the label space. There is no scaling issue. >Then if this represents a scaling issue, I >guess you can call for bigger labels, e.g. by stacking 2 labels. But this >requires >more lookup work in the forwarding plane. [Mingui] As explained above, it does not need multiple lookup. Remember, we do not want to change the forwarding plane. >Roughly equivalent to the label >context space that you did not want in the first time... >Another option is to have one RG per couple of PE. In this case you need 10 vNH >(IINM). That's roughly the number of PE but that's still *3 the number of >states >in the IGP so I think the document should talk about this. [Mingui] On one hand, the above extreme case happens only in theory. The reason we scope the document to talk about 2 PEs is that duel homing is the BCP. Think about the real deployment, I believe most POPs will use two PEs for the redundant connection. On the other hand, even if you have 5 PEs in one POP, just put them into one RG. Therefore, the increase of the number of states in the IGP is not so big. [Mingui] But I agree with your advice that we can spend some words to address this scaling issue in the document. <snip> >>[Mingui] All in all, if customers really want the resilience, those >>routes via the primary PE SHOULD NOT be installed in the FIBs of backup PEs. > >[Bruno] Good point. So you probably should add this to the document. [Mingui] Sure. >>[Mingui] By the way, the scenario you designed may suffer from >>transient loop issue. Imagine that the more specific routes fails on >>the primary PE, the primary PE will resort to the backup PE. At that >>time, it's probably that the backup PE is unaware of the failure. It >>will send packet back to the primary PE. Oops, loop occurs. Following >>the above "SHOULD NOT be installed" requirement, such kind of loops can be >avoided. > >[Bruno] You are right. I suspect that RFC 4364 implies that a PE should not >reflect back to the core, a VPN packet received from the core. But I haven't >checked. [Mingui] OK. How about the local-repair and label-retention technique? With that technique, the primary PE may cache the route advertised by the backup PE and use it when the route it learns from the CE fails. I guess this issue is kind of off the track. We can talk more about it between us two. >[Bruno] Sure. But the solution relies on global VPN labels which is not what is >deployed today. So it all depends on whether you will be able to deploy such >change before. Which will requires all implementations to do it while draft >minto >has no such dependency. [Mingui] The solution does not rely on *global* VPN labels. They are still locally assigned in the scope of the RG. >> If customers want this feature, I promise you will see this feature >>supported by products in several months. > >[Bruno] Ok. But I guess you mean a subset of the products currently deployed. >There may be multiple vendors/implementations in a given network. And some >implementations are sometimes even considered as legacy (by the vendor). [Mingui] For those legacy products, operators can update their software. If bare legacy PEs and label-sharing PEs are interconnected, ICCP connection will not be established. It allows PEs falls back to the non-redundant connection. For those label-sharing PEs from different vendors, if they implement the same RFC, they are supposed to be interoperable. >>[Mingui] c. The delegation of protector is topology dependent. I guess the >>number of possible alternative paths held by the protector is a much >>smaller set of all possible alternative paths. > >#Bruno: Indeed, currently the location of the protector is topology >independent. >Simply because this relies on the existing FRR mechanism used in the core and >this FRR may have coverage limitations (e.g. LFA). There are plans to remove >this limitation. >I'm not sure to understand your second point (second sentence). [Mingui] The central protector is delegated as the PLR, right? This further reduces the coverage of LFA. As we know, a free LFA can have any router as the PLR. Thanks, Mingui
