[mpls] Alvaro Retana's No Objection on draft-ietf-mpls-egress-protection-framework-06: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

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.