Hi Mingui, Please find my comments inline [Bruno2]
>From: Mingui Zhang [mailto:[email protected]] >Sent: Monday, November 18, >2013 10:32 AM > >Hi Bruno, > >Please find my comments inline below [Mingui]. > [...] > >>[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. [Bruno2] Let's assume: - 5 PE in the group, hence sharing the same range of labels (e.g., 1~1100). - 5 VPNs in connect to this group of PE, 2 of which being dual-homed (VPN1 & VPN2). With label sharing: Label:1 2 3 4 5 PE1 VPN1 x x x x PE2 VPN1 VPN2 x x x PE3 x VPN2 x x x PE4 x x VPN3 x x PE5 x x x VPN4 VPN5 All labels marked as "x" are burned/lost because of the label sharing. Without label sharing: Label:1 2 3 4 5 PE1 VPN1 PE2 VPN1 VPN2 PE3 VPN2 VPN2 PE4 VPN3 PE5 VPN4 VPN5 Here no label is lost. So, in that specific example, 7 labels*PE are used out of 25 while 18 are lost. Hence you need/use a label space which is 3.5 times bigger. (25/7) > >>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. [Bruno2] I was referring to a different draft: draft-renwei-l3vpn-big-label-00 >>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. [Bruno2] ok, thanks. ><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. [Bruno2] not always. There is public/ietf example for this: draft-l3vpn-legacy-rtc-00 Bruno > 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
