[RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
Eric Gray <eric.gray@ericsson.com> Tue, 16 April 2013 14:18 UTC
Return-Path: <eric.gray@ericsson.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DC21F96F2 for <rtg-dir@ietfa.amsl.com>; Tue, 16 Apr 2013 07:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM+CDSV3Ojz2 for <rtg-dir@ietfa.amsl.com>; Tue, 16 Apr 2013 07:18:28 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EC11021F9726 for <rtg-dir@ietf.org>; Tue, 16 Apr 2013 07:18:27 -0700 (PDT)
X-AuditID: c6180641-b7faf6d00000096b-9e-516d5db23b15
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 30.4C.02411.2BD5D615; Tue, 16 Apr 2013 16:18:27 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 10:18:26 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" <draft-ietf-mpls-tp-ring-protection@tools.ietf.org>, "rtg-ads@tools-ietf.org" <rtg-ads@tools-ietf.org>
Thread-Topic: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
Thread-Index: Ac46I/L2HHXp8Uk5T2ussJve4WIn1A==
Date: Tue, 16 Apr 2013 14:18:25 +0000
Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF6090EF7@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF6090EF7eusaamb107ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPuO7m2NxAgzn7pS3O7K212HnmOrPF gjVP2R2YPZYs+cnk8eNkiseXy5/ZApijuGxSUnMyy1KL9O0SuDKaz99hL1g/lani7fsTzA2M 994xdjFyckgImEhsW/sbyhaTuHBvPVsXIxeHkMBRRolZ/zYxQjjLGSX6Nk9mB6liE9CQOHZn LVhCRGARUOLaRqYuRg4OZgFNibWXuUBqhAWCJSaufM0MYosIREi8/vWXEcLWk3jbup4JxGYR UJW4tmgf2ExeAW+JF2/+sIHYjEBXfD+1BqyGWUBc4taT+UwQ1wlILNlznhnCFpV4+fgfK4St LLHkyX4WiPp8iQ9T97FAzBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHs MwceMyGLL2BkX8XIUVqcWpabbmS4iREYO8ck2Bx3MC74ZHmIUZqDRUmcN9T1QoCQQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGxvjQuEvNC3tUmfd8mdUS/NhUtzxw5w/nta/yQ2+sX3VvnVXj hNOJ8x7mevzUObA6Zd22TOnsnwen2DmdSfLykP9q1Jjp9HanMbe9evo8qYkbP/Ss35BZz9d7 fIXjE04j25Pqm0okQk5sffrhBBPzhacT5vTeCWV+pTK1qHvWkn9uyttWJZQ1rVViKc5INNRi LipOBAAEvfOJawIAAA==
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 14:18:35 -0000
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05 Reviewer: Eric Gray Review Date: 17 April, 2013 Intended Status: Informational There is at least one major issue with this document, as it is now written. Comments/Questions: ================= The "disclaimer" at the end of the Introduction misses a case related to the cases excluded from the scope of this document - which is itself presumably out of scope. The text currently talks to protection of a path prior to entry to the ring, or after exit from the ring. The missing case is when the path is part of a protected service that involves one or more alternative paths external to the ring. It is not difficult to think of a scenario in which a protection event outside of the ring will require that data forwarded across the ring will need to enter the ring at a different point, leave the ring at a different point, or both. While this would seem to impact the protection of the ring itself (possibly requiring setup of similar protection for the new path traversing the ring), it should be quite easy to represent such an occurrence as a set of discrete event/operations that would not be significantly different when compared to initial setup of protection for the previous path in the ring. If for any reason folks feel that this may not be the case under some circumstances this document should either address those cases or explicitly state that they will not be addressed by this document. Alternatively, the issue may be addressed by simply removing the 2nd sentence of the "disclaimer" paragraph, or the cases explicitly stated should be expressed as "examples." ------------------------------------------------------------------------------------------------------------- Bullet 4 of section 1.3 is confusing as written. The meaning of "LI" is clear enough, but "LE" presents some problems. Suppose that PHP is used; in this case, there is no label "expected" at the egress point from the ring (although a label may be present and will be used by the LSR at that point, that label may not always be the same label). Is PHP never permitted? Also, under what circumstances would the ring egress point SPME exit LSR not be the same? Based on subsequent reading, I believe this would be the case for use of an SPME to provide "Wrapping" protection - it would probably therefore be a good idea to either say something to this effect (if that is the case) or provide a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or possibly just to section 2.3). I would suggest adding a sentence to this bullet, along the lines of: "See section 2.3 for examples of where the SPME egress and ring exit might not be the same." ------------------------------------------------------------------------------------------------------------- Section 2 appears to ignore 1+1 protection, which would (similar to "Steering") use pre-established protection paths from an ingress LSR/node to each egress LSR/node but would send that traffic both ways at all times. The main differences between this approach and Steering are: o the need to notify the ingress node is eliminated as a consideration for protection switching latency o there is (therefore) no reliance on the existence of a failure detection method that is able to notify the ingress of a failure in the ring o double bandwidth is required This is carried forward in all subsequent sections/subsections. ------------------------------------------------------------------------------------------------------------- Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" comparison basis in the bullets relating to "considerations" in each subsection. In order to allow this comparison, both sections would need to provide an indication of the order of protection paths required in a protection domain. Because - in the "Wrapping" case - it is necessary to provide protection SPME for each node and link (in a ring the number of links is exactly the same as the number of nodes), the number of protection SPME is O(2N). For the "Steering" case, however, it is necessary to provide protection SPME for each ingress node to each egress node (except for the last one) - which is O(N^2). This statement is actually made in the introductory text in section 2.4. I would suggest either adding a bullet in section 2.2 and including forward references in these bullets to the analysis in section 2.4, or removing the bullet in section 2.1. ------------------------------------------------------------------------------------------------------------- Section 2.3 appears to assume that the desired protection scheme will be based on "Steering" rather than "Wrapping." This assumption is made without any effort/analysis to justify why this assumption is made (at least as far as I can see). If that is the intention, minimally, section 2.3 should start with a statement that this is the assumption made. Reading further, however, subsequent subsection 2.3.2 describes how the SPME concept - as outlined in the introductory text of section 2.3 - may be used for the "Wrapping" approach. The confusion arises as a result of figure 3 and the text that describes it in the preceding paragraph, as this figure/text is what most contributes to an impression that an SPME would start at the ingress and end at an egress. I would suggest that this figure and the preceding paragraph would find a better home on section 2.3.1. This would also align subsections of section 2.3 better as there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4. ------------------------------------------------------------------------------------------------------------- The last paragraph in introductory text in section 2.3 (immediately prior to the start of section 2.3.1) appears to ignore the case where the egress LSR would use labels to "steer" delivery of labeled packets it receives over the SPME to specific egress ports (of the egress LSR). These labels would most likely not be a part of the label stack received by the ingress LSR (there is no need for these labels to be known outside of the ring) and would have to be pushed onto the stack before pushing on the label for an SPME to the egress LSR/node. ------------------------------------------------------------------------------------------------------------- I believe the text in the last paragraph of section 2.3.4 is incorrect in stating that protected traffic might not share the same protection path in both directions. If both LSR-B and LSR-F detect that LSR-A is not available, then both will use the protection SPME between LSR-B and LSR-F. If both LSR-A and LSR-E detect that LSR-F is not available, then both will use the protection SPME between LSR-A and LSR-E. If both LSR-A and LSR-F detect that the link between them is not available, then both will use the protection SPME between them. All that is required is that both LSRs in each case agree as to the nature of the failure (node or link) - which may be easily and consistently determined by monitoring the status of the working and protection SPME. While it is possible for the end-point LSRs in each case to have an inconsistent view of the nature of the failure, this inconsistency should be short lived (based on the periodicity of OAM monitoring of SPMEs). Depending on the OAM monitoring periodicity used - and the length of links in the ring - this inconsistency may exist for a period of time that is less than the latency to be expected for "Steering" based protection. Note that this is a major issue with the current text as it impacts on analysis in subsequent section 2.4 and the conclusion/recommendations of this document. ------------------------------------------------------------------------------------------------------------- The analysis in section 2.4 is incomplete or based on an incorrect assertion made in section 2.3.4. If the alternative suggested in section 2.3.4 were used, the number of SPME that will be required would be O(4N) - which is still O(N) and would be less than O(N^2) for fewer than the 16-node limit assumption made for the analysis. ------------------------------------------------------------------------------------------------------------- In the 1st sentence of the last paragraph in the introductory text of section 2.4, the sentence mentions the use of additional resources but does not mention the additional latency. Is there any reason for the omission? I suggest removing the text in this sentence that starts with "even though" as it might otherwise be necessary to attempt an exhaustive list of detractions. ------------------------------------------------------------------------------------------------------------- Also in the last paragraph of the introductory text in section 2.4, I imagine that the case where one or more pairs of SPME may be eliminated because of LSRs that are not ingress-egress pairs is most likely of trivial value in any deployment involving a ring topology. Perhaps the last sentence in the last paragraph of this text in section 2.4 could be removed? NITs: ==== In the Introduction section, 5th bullet in (or after) the 2nd paragraph - " Impact of signaling and routing information exchanged during protection, in presence of control plane." - the phrase "in presence of control plane" should probably be "in the presence of a control plane." ------------------------------------------------------------------------------------------------------------- In the 2nd bullet in section 2.1, I believe it is the case that O(2N) = O(N). ------------------------------------------------------------------------------------------------------------- In the 1st paragraph of section 2.3.1, where it says "there is always an alternative path ..." - at the SPME level (as described in this document), there's always exactly one alternative path. ------------------------------------------------------------------------------------------------------------- In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) = O(N^2). ------------------------------------------------------------------------------------------------------------- In the 1st and 2nd bullets in section 2.4, I believe it is the case that O(2N) = O(N). -------------------------------------------------------------------------------------------------------------
- [RTG-DIR] Routing Area Directorate Review of draf… Eric Gray
- Re: [RTG-DIR] Routing Area Directorate Review of … Yaacov Weingarten
- Re: [RTG-DIR] Routing Area Directorate Review of … Eric Gray
- Re: [RTG-DIR] Routing Area Directorate Review of … Yaacov Weingarten
- Re: [RTG-DIR] Routing Area Directorate Review of … Eric Gray