MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-07

Thank you for addressing my DISCUSSes and COMMENTs.

Firstly, I'd like to thank you for addressing Scott Bradner's OpsDir review, and Scott for providing it. I think that this has noticeably improved the document.

I have a general question -- like many documents, this talks about "link failure", but is somewhat silent on what exactly is meant by "link" -- is this a "circuit" or does it also include something like TE / bundled (RFC4201) / aggregated / whatever links? The terminology section somewhat hints that it covers all, but is still somewhat vague. 
(Note that this is just a comment, feel free to consider and reject it... )

Please update the examples to use either IPv6 addresses or a mix of IPv4 and IPv6 addresses. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for details.

I support Roman's DISCUSS.

(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.

I recommend to use the exact boilerplate text from RFC8174:
      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here."

Editorial comments:

1) I recommend to either move the requirement section to the appendix or rephrase this section to outline features of the final framework instead of stating requirements.

2) section 5.2: "The mechanisms SHOULD be reasonably fast"
Alvaro also commented on this sentence, however, I think the resolution here is to not use normatively language because that is not needed.