[mpls] Alvaro Retana's No Objection on draft-ietf-mpls-egress-protection-framework-06: (with COMMENT)
Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 03 July 2019 13:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2E912007A; Wed, 3 Jul 2019 06:28:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-egress-protection-framework@ietf.org, Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <156216051344.14674.3862670637095165565.idtracker@ietfa.amsl.com>
Date: Wed, 03 Jul 2019 06:28:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/dIhjsO91BrvTxCwESbmQvjVoqYw>
Subject: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-egress-protection-framework-06: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 13:28:33 -0000
Alvaro Retana has entered the following ballot position for draft-ietf-mpls-egress-protection-framework-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) [nit] The MP and the protector are the same thing, right? Names are just that...but it seems that using MP avoids adding one more name for the same thing. (2) §1: "The framework is described by mainly referring to P2P...it is equally applicable to P2MP...MP2P...and MP2MP...if the sub-LSPs of these tunnels can be viewed as P2P tunnels." This statement is reflected in one of the requirements in §4. Are there cases where P2MP/MP2P/MP2MP tunnels cannot be treated as p2p? If so, then please add some text about that to scope the applicability. (3) §1: "The framework does see the need for extensions of IGPs and service label distribution protocols in some procedures, particularly for supporting protection establishment and context label switching. This document provides guidelines for these extensions, but leaves the specific details to separate documents." Leaving the details to separate documents is fine. However, the document is not clear/straight forward about which procedures might need extensions and which do not. In particular, I think that this document, and future work, would benefit from a clear indication of where particular procedures are documented (which might mean adding a lot of more references), or, even better, a clear indication of the ones that are not already documented. (4) §1: "It is RECOMMENDED that the framework SHOULD be used in conjunction with control-plane convergence or global repair..." RECOMMENDED and SHOULD have the same meaning. This sentence is redundant. (5) §3: "A protector MAY be physically co-located with or decoupled from a backup egress router..." I think that the MAY is out of place because it isn't specifying anything, just stating a fact. s/MAY/may (6) §4: s/considers the followings/considers the following (7) §4 (Requirements) Are there requirements listed in this section that are not satisfied in the document? I expect the answer to be No. I don't think that using Normative Language in this Section is a good thing because it is not being used to require any type of interoperability (as can be argued for the rest of the document), but only to define requirements that should be satisfied in this same document. (8) §5.2: "The mechanisms SHOULD be reasonably fast, i.e., faster than control plane failure detection and remote failure detection." When would it be ok for this mechanism to be slower? IOW, why isn't MUST used? (9) §5.2: In the list of guidelines a difference between "a reasonably fast mechanism" and "a fast mechanism" seems to be made. The implication (from the previous comment) is that a "fast mechanism" is not fast enough (because it is slower that the control plane). In the context of this section what seems important is the ability to distinguish between a link failure and an egress node failure, or not...and not whether the mechanism is reasonably fast or simply fast. Suggestion: s//PLR has a mechanism (10) §5.2: "treating a link failure as an egress node failure MUST NOT have a negative impact on services" How can the PLR figure the impact on the services beforehand? (11) §5.3: "each service destination MUST be dual-homed or have dual paths to the egress router and a backup egress router which serves as the protector." I don't think it is a requirement for the backup to always be the protector. s/backup egress router which serves as the protector/backup egress router which may serve as the protector (12) §5.4: "A given egress router E MAY be the tailend of multiple tunnels." The MAY is out of place, the sentence just states a fact. s/MAY/may (13) "MAY or MAY not" is used a couple of times to show an optional behavior. MAY already means optional. In all cases in this document I don't think that Normative language is needed. s/MAY or MAY not/may or may not (14) §5.6: s/The bypass tunnel MUST have the property that it MUST NOT be affected by the topology change caused by an egress node failure./The bypass tunnel MUST NOT be affected by the topology change caused by an egress node failure. (15) s/IPv4/v6/IPv4/IPv6 (16) §5.7: "The PLR MAY establish the egress-protection bypass tunnel to P in several manners." The MAY is just stating a fact. s/MAY/may (17) Please expand UHP. (18) §5.8: "The advertisement MUST be understood by the PLR." On one hand, I think this is an obvious statement, and is not needed. On the other hand, I get the feeling that it was included because there is something else to be considered...but I don't know what, and the text doesn't say. If there is something specific to be considered, please write it down. (19) §5.8: "The "context ID label binding" advertisement is defined as IGP mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS]." The mirror context segment is not defined for OSPF. (20) §5.8: "...care MUST be taken for the applicability of this approach to a network." What does that mean? How can it be Normatively enforced? It would be nice to spell out the potential pitfalls to be taken into account. The sentence right after says that "the feasibility of each approach in a given network as dependent on the topology, manageability, and available protocols of the network." This statement sounds like it should result in guidance (even if general) on when an approach may be applicable. I would like to see that type of guidance somewhere in the document -- the Operational Considerations sections looks ideal to me. (21) §5.9: "An egress-protection bypass tunnel MAY be established via several methods:" I think that all the MAYs in the bullets are not needed because of the one at the top. In fact, I think all of them (including the one at the top) just state a fact (not a Normative action). s/MAY/may (22) §5.11: "Specific extensions MAY be needed..." Again, just a fact. s/MAY/may' (23) §5.11: "The details of the extensions SHOULD be specified in separate documents." Where else would they be specified? IOW, why not use MUST? Or even better, why is Normative language even needed? (24) §7: s/it is RECOMMENDED that the services affected by a failure SHOULD be moved to/the services affected by a failure SHOULD be moved to RECOMMENDED = SHOULD (25) §8: s/it is RECOMMENDED that the router SHOULD generate/it is RECOMMENDED that the router generate RECOMMENDED = SHOULD (26) §10: "The nexthops of these routes MUST be... The nexthops MUST NOT use..." This section is an example, there should not be any Normative language.
- [mpls] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana via Datatracker
- Re: [mpls] Alvaro Retana's No Objection on draft-… Yimin Shen