Hi Mingui, Please see comments inlined. #Bruno
Plus some comments below on the draft: 1) The document does not describe the scaling impact on the core as it creates, in the core IGP, states on a per CE (customers'site) basis. For large SP, this will represent a significant impact on the IGP and will degrade the IGP convergence time. ( o(number of important IGP prefixes to rewrite) ) 2) > A master PE is elected in the same way the DR is selected (see section 7.3 of [RFC2328]<http://tools.ietf.org/html/rfc2328#section-7.3>), or the DIS is selected [ISIS<http://tools.ietf.org/html/draft-zhang-l3vpn-label-sharing-01#ref-ISIS>]. I don't think that this is directly applicable. You may need to elaborate on this and specify the corner cases (e.g. CE starts and advertise its routes to both PE at the same time. Hence both PE believes they are the first one and hence are the master.) Also in BGP VPN or IGP there is no advertisement of "Router Priority". I guess that this can always be specified, but this remains to be done. 3) " Suppose PE3 fails and the packet with VPN route label 1100 is redirected to PE4. PE4 can recognize this shared label. It simply looks up the packet's destination address in the VRF identified by this label. As specified in Section 5 of [RFC4364]<http://tools.ietf.org/html/rfc4364#section-5>, PE4 will be able to determine, the attachment circuit over which the packet should be transmitted (to the CE) as well as the data link layer header for that interface. In this way, the failed egress PE is smoothly protected. > "It simply looks up the packet's destination address in the VRF identified by this label". IMHO additional elaboration may be required as the nominal PE may be the nominal because it has advertised a more specific route. Hence a look up in the VRF will match the more specific route from the nominal/failed PE. Not sure how a vanilia PE implementation would react. The issue is that when receiving the packet, the backup PE does not know whether the nominal is dead or not. In contrast to draft-minto for which the PE know whether it's used as backup or not, thanks to the contextual label. Regards, Bruno From: Mingui Zhang Sent: Thursday, November 07, 2013 8:40 PM Hi, As a choice of fast PE protection, 1. This solution is simple and light-weight. We need not introduce the complex context label table in PE routers. #Bruno: draft-minto-2547-egress-node-fast-protection<http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02> is simple and light-weight ;-) More seriously: - Draft minto does not need to define a new protocol (ICCP) in order to learn the labels of the backup PE. BGP already provides this. While ICCP is a 79 pages draft, plus 11 for the extension. - Draft zhang relies on the having the same label on redundant PE. While this is doable, this is a significant change compared to the existing deployed model. - regarding context label tabel - From a standardization standpoint, context-specific label space is already defined in RFC 5331, so nothing new. - From an implementation standpoint, I agree that this requires some additional resources in the forwarding plane. But draft minto does not require that all PE support this. This can be performed by a protector PE if some PE do not support it. So label table need not be stored repeatedly on RG members. #Bruno: agreed. 2. Also, it's easy to be deployed. It does not bring any change to P routers (control plane & data plane). It even does not change the data plane of PE routers. #Bruno: It's not easy to deploy as it mandates to update all PE routers, both nominal and backup. While with draft-minto-2547-egress-node-fast-protection<http://tools.ietf.org/html/draft-minto-2547-egress-node-fast-protection-02> the deployment of a single protector PE can fast protect all PE of the AS with no change on existing PE. 3. In addition, it does not bear the restriction of "no penultimate-hop-popping". #Bruno: ultimate hop poping is only required for the label associated with the context table of the backup PE. This is required to identify the context-specific label space. This is not an additional argument compared to 1 (context label table). 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.
