Comments on draft-psarkar-rtgwg-rlfa-node-protection-03
Uma Chunduri <uma.chunduri@ericsson.com> Fri, 28 March 2014 17:51 UTC
Return-Path: <uma.chunduri@ericsson.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04F01A097A for <rtgwg@ietfa.amsl.com>; Fri, 28 Mar 2014 10:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE40Bzz96j9g for <rtgwg@ietfa.amsl.com>; Fri, 28 Mar 2014 10:50:58 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3911A0970 for <rtgwg@ietf.org>; Fri, 28 Mar 2014 10:50:58 -0700 (PDT)
X-AuditID: c6180641-b7f2f8e000002cdc-48-5335b398644e
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0C.D1.11484.893B5335; Fri, 28 Mar 2014 18:38:33 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Fri, 28 Mar 2014 13:50:55 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03
Thread-Topic: Comments on draft-psarkar-rtgwg-rlfa-node-protection-03
Thread-Index: Ac9KrcDA735FKnU5Tr2dhjVMzaaMzA==
Date: Fri, 28 Mar 2014 17:50:55 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F23168E@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F23168Eeusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyuXRPlO7MzabBBjtvclpcePOb2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGVN6rjEWbD/GWPHg5WKWBsbGlYxdjJwcEgImEu/n74CyxSQu 3FvP1sXIxSEkcIRR4l7jUnaQhJDAckaJb9NSQGw2AT2Jj1N/gsVFBFQleme1soHYwgIOEmsm LmaGiLtKfDx+nAnC1pPYsfo1WD0LUP3t559Yuxg5OHgFfCVWrPcACTMC7f1+ag1YObOAuMSt J/OZIO4RkFiy5zwzhC0q8fLxP1YIW1FiX/90dpAxzAL5EpuuiICEeQUEJU7OfMIygVFoFpJJ sxCqZiGpgijRkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbmIEhv0xCTbH HYwLPlkeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PSkUvShYaZ4Rck ns+MvrO6QkTpa+evA0HWNyZa/f3/Llog4eiv9SnPnS4suZH7oGhn2bbVi7TnXJ4ToP6xP/v+ qhyt2++Pzbhx6/zlDdtmd+a7ZC/OuBXgesHYqjpTfwnP9Ky6JUrFrx7wH57CXjXxb33PJOdT 3iVvl0hIdzj6be6LrvcRqFJUYinOSDTUYi4qTgQAUP797kkCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtgwg/eBiCYMlAHTHmO6RdTUwvWVfSeFA
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Mar 2014 17:51:06 -0000
Dear Authors, These are some specific comments - ============= 1. Abstract - "The document also shows how the same procedure can be utilised for collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate path is precursory to apply operator defined policy for eliminating paths not fitting constraints." Why we need this for NP only? ... 2. Introduction " Also, the LFA Manageability [I-D.ietf-rtgwg-lfa-manageability] document, requires a computing router to find all possible (including all possible Remote-LFA) alternate nexthops, collect the complete set of path characteristics for each alternate path, run a alternate- selection policy (configured by the operator), and find the best alternate path. This will require the Remote-LFA implementation to gather all the required path characteristics along each link on the entire Remote-LFA alternate path." Why do we need to collect path characteristics of all alternatives before alternate policy ? This is not what is represented in I-D.ietf-rtgwg-lfa-manageability (it's prune then run alternate selection policy) 3. Section 2.1 " A closer look at Table 1 shows that, while the PQ-node R2 provides link-protection for all the destinations, it does not provide node- protection for destinations E and F." There is no node F in the diagram. You mean to say D1 here? 4. Section 2.1 - Table 2 D2 | S->E->D1 | R3 | S=>N=>E=>R3->D2 The above should be S->E-R3-D2 5. Section 2.1 "Again a closer look at Table 2 shows that, unlike Table 1, where the single PQ-node R2 provided node-protection, for destinations R3 and G, if we choose R3 as the R-LFA nexthop, it does not provide node- protection for R3 and D1 anymore." There is no node G in the diagram 6. Section 2.2.1 D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,E) + D_opt(E,Y) Need to be changed (even in the main draft, per agreement earlier) to D_opt(Ni,Y) < D_opt(Ni,S) + D_opt(S,Y) 7.Section 2.2.2 "It must be noted that a node Y satisfying the condition in Figure 4 above only guarantees that the R-LFA alternate path segment from S via direct neighbor Ni to the PQ-node Y is not affected in the event of a node failure of E. It does not yet guarantee that the path segment from PQ-node Y to the destination is also unaffected by the same failure event." I don't think Y is yet a PQ node as description says. Probably it needs to be corrected as "potential PQ-node" 8. Section 2.3.1 (even title itself is incorrect, this is all about NP ext-P space) "Implementations should run the inequality in Section 2.2.2 Figure 4 for all direct neighbor, other than primary nexthop node E, to determine whether a PQ-node Y is also a candidate node-protecting PQ- node." for all direct neighbor ==> should be replaced to indicate all eligible neighbors where back is provisioned. 9. Section 2.3.1 " Implementations should run the inequality in Section 2.2.2 Figure 4 for all direct neighbor, other than primary nexthop node E, to determine whether a PQ-node Y is also a candidate node-protecting PQ- node." Y is not PQ-node here. "PQ-node" should be replaced with node protecting extended-p space node. 10. Section 2.3.1 In the similar grounds as above Table 3 & table 4 first column should not be "PQ-node (y)" 11. Section 2.3.1 Though this section is trying to justify how and why the PQ nodes selected are link protecting and node protecting. But the way it's written is incorrect with references to section 2.2.2 For e.g. "So S may re-use the list of links and nodes collected from the same SPF computations, to decide whether a PQ-node Y is a candidate node-protecting PQ-node or not. A PQ-node Y shall be considered as a node-protecting, if and only if, there is atleast one direct neighbor of S, other than the primary nexthop E, for which, the primary nexthop node E does not exist on the list of nodes traversed on any of the shortest path(s) from the direct neighbor to the PQ-node." Here the usage of PQ node is incorrect as it is referring to section 2.2.2. The more correct term here is the candidate NP extended-P space. 12. Section 2.3.1 " As seen in the above Table 4 while R2 is candidate node-protecting Remote-LFA nexthop for R3 and G, it is not so for E and F, since the primary nexthop E is in the shortest path from R2 to E and F." There are no nodes G and F anywhere in the diagrams 13. Section 2.3.2 "After running the forward SPF on a PQ-node (from the node-protecting PQ- space) the computing router shall run the inequality in Figure 6 below. PQ-nodes that does not qualify the condition for a given destination, does not gaurantee node-protection for the path segment from the PQ-node to the given destination." Here the PQ nodes are candidate NP PQ nodes - this section should be cognizant of this while loosely using PQ nodes term. Also it's not "After running the forward SPF..", it should be "While running the forward SPF.." 14. Section 2.3.3 " Implementations MUST choose a default value for this limit and may provide user with a configuration knob to override the default limit. Implementations MUST also evaluate some default preference criteria while considering a PQ-node in this subset." Here the point is for interoperability and deterministically getting the same PQ node from all vendors one default criteria should be used. But if "some default" preference is used you won't fulfill the objective of same PQ node. If this is really a goal then this document must define indeed a default heuristic and this must be implemented by all. The below paragraph indicates a suggested default criteria and also points out further study is required to confirm this is indeed the "default". I think this need to be worked out. "A suggested default criteria for PQ-node selection will be to put a score on each PQ-node, proportional to the number of primary interfaces and remote destination routers being protected by it, and then pick PQ-nodes based on this score. A more appropriate heuristsics can be devised, based on in-depth study of coverage provided by R-LFA, in the networks where they are mostly deployed. The same can then be used for PQ-node selection." 15. Section 3 "For such policy-based alternate selection to run, all the relevant path characteristics for each the alternate paths (one through each of the PQ-nodes), needs to be collected." This is very vague - what path characteristics you are seeking must be clearly spelled out. And also this whole thing doesn't belong here and should be in http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-manageability-03 And I already see the same in Section 5.2.4.2 of the same. -- Uma C.
- RE: Comments on draft-psarkar-rtgwg-rlfa-node-pro… Pushpasis Sarkar
- Comments on draft-psarkar-rtgwg-rlfa-node-protect… Uma Chunduri
- RE: Comments on draft-psarkar-rtgwg-rlfa-node-pro… Uma Chunduri
- RE: Comments on draft-psarkar-rtgwg-rlfa-node-pro… Pushpasis Sarkar