Hi Uma, Thanks for your comment, please some mine inline.
-----Message d'origine----- De : rtgwg [mailto:[email protected]] De la part de Uma Chunduri Envoyé : jeudi 23 janvier 2014 22:24 À : [email protected]; [email protected] Cc : [email protected] Objet : RE: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt Dear Authors, I have given some comments to you only, on the earlier version of this draft few months back and I see some of them are taken care. Thx. After re-reading this version, I felt this is indeed addressing the important aspect and the value of policy based selection of alternatives As opposed to the alternatives with best protection. This document brings out lot of use cases and the configuration knobs to achieve the goal of the "policy" based preference on possible LFAs. However, I see some of the sections documented are not directly related to the uses cases presented in Section 2, which in principle shows how and why the best protection is not good (excluding the IS-IS overload case) in all cases. For example: 1. Section 3.1, which suggests the activation granularity requirement of the LFAs from Context, instance to address-family and per-prefix. Here some of the choices are natural but I don't think this addresses any of the problems documented in Section 2. "..This means that if a specific prefix must be protected due to a configuration request, LFA must be computed and installed for this prefix even if the primary outgoing interface is not configured for protection." Could you clarify the must (2) in the sentence? Do you intend to say "MUST" there? [SLI] "must" is not RFC2119 "MUST" :) The idea is just, as mentioned in the previous sentence that "per prefix protection" overrides "per interface protection" configuration. Also I feel, for example, having per-prefix granularity for provisioning LFA or not is an implementation choice than an interoperability issue while deployment. [SLI] Agree ... 2. Section 4.3, "Required local information" Says - "MUST provide coverage information per activation domain of LFA (area, level, topology, instance, virtual router, address family ...)." To me this is good to have information and be very helpful for the operator but I am not sure mandating the coverage information granularity is addressing any of the issues presented in Section 2. [SLI] When deploying LFA, coverage information is mandatory for the SP as coverage may change as topology is changing. Maybe we can mention this in section 2. What do you feel ? 3. Similarly Section 4.4 coverage monitoring guidelines for the vendor implementations are good ones but these are neither addressing any issues presented in Section 2 nor helping solve any interoperability issue. The problem I see with this is lot of implementations may quickly become non-compliant from customers point of view once this becomes RFC. Do you see that way? [SLI] As mentionned in previous comment, coverage informations are mandatory to be able to maintain LFA deployment (SP experience speaking ...). As proposed, I can add something in section 2 to detail the need. Specific review Comments: ===================== 1. Section 2.1 When the core link R8-R7 fails, R8 switches all traffic destined to all the PEx towards the edge node PE2. What is "all the PEx"?? [SLI] PEx is a set a PE. 2. Section 2.2 "In the figure 2, let us consider the traffic coming from PE1 to PEx. Nominal path is R9-R8-R7-R6-PEx." You might mean to say R9-R8-R7-R10-R6-PEx ? Can you clarify? [SLI] Right this is a mistake, I will fix it. Thanks 3. Section 2.3 Though it's not important to illustrate your point of using sub-optimal core links as LFA, it's good to mention the link costs of R3-PE1 and PE1-R4. Otherwise PE1 could become another potential node protecting alternative via non-core or whatever.. (at least can avoid confusion for the reader). [SLI] Agree, will fix it. 4. For IGPs what exactly you meant when you say "topology" and how this is different than first bullet "Per address-family"? [SLI] Topology refers to multitopology IGP (MT extensions), this may be different from address family (OSPF for IPv6 is not a multitopology OSPF case) 5. Section 3.2.1 "Especially, computation of PQ set ([I-D.ietf-rtgwg-remote-lfa]) SHOULD to be performed before best alternate selection." SHOULD to be ==> SHOULD be [SLI] will fix it. Also, say you might have a legacy node to deal with and you are not able to establish TLDP with PQ here in that case, you might look for a knob to choose the policy (remote or local policy). [SLI] This may be managed by "neighbor exclude" policy statement. 6. "3.2.5. Details on criterions" Didn't understand the title and all sub-sections listed under should instead be 3.2.x level? I am saying this because I lost where I was while reading. I would suggest to re-organize better [SLI] Why not ... the idea is to give details on how each attribute should be retrieved. So do you prefer to move all subsections to 3.2.x ? I'm ok with that. 7. 3.2.5.1. LFA and ECMP It should have been "ECMP LFAs" [SLI] Ok And.. "As mentioned in [RFC5286] Section 3.4., protecting a link within an ECMP by another primary nexthop is not a MUST. Moreover, we already presented in this document, that maximizing the coverage of the failure case may not be the right approach and policy based choice of alternate may be preferred." If you just want to prevent one of the other ECMP link as LFA then you can provision "local" SRLGs. Then in this case you might get L3 or L4 but you are seeking both as LFAs. I see the current text put Lot of emphasis on the point of not using one of the primary ECMP paths as alternatives with citation on RFC 5286. However, you are *also* seeking for an ECMP LFA (if available, instead of tie breaking and give one LFA eventually from the non-bundle). Also I didn't fully understand how can one enforce this as one can have another equal cost alternate (non-bundled) path from PE1 to PE2 via P2 or some Px node. It seems in this case you are looking for all non-ECMP LFAs to be installed as alternatives? [SLI] You are right. 8. Section 3.2.5.5 "Rather than tagging interface on each node (using link color) to identify neighbor node type (as example), it would be helpful if routers could be identified in the IGP. " a) After this it completely talks IS-IS language. Probably this should be revisited to make it generic or applicable to the other IGP. b) Coming to IS-IS, you referred I-D.psarkar-isis-node-admin-tag but the text suggests, its own algorithm to identify the neighbor with TLV135 and is not complete in many fronts. I would suggest revisit this section completely to focus on the point your of "neighbor preference" rather than incomplete IGP details. [SLI] Agree, will fix it 9. Section 4.5 "4.5. Deterministic and documents LFA selection behavior" The title didn't sound correct. [SLI] Ok will fix it -- Uma C. -----Original Message----- From: rtgwg [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, January 22, 2014 5:02 AM To: [email protected] Cc: [email protected] Subject: I-D Action: draft-ietf-rtgwg-lfa-manageability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Operational management of Loop Free Alternates Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Martin Horneffer Pushpasis Sarkar Filename : draft-ietf-rtgwg-lfa-manageability-01.txt Pages : 21 Date : 2014-01-22 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lfa-manageability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-lfa-manageability-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg _________________________________________________________________________________________________________________________ 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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
