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

[Yimin Shen <[e-mail]>]

Hi Alvaro,

Thanks very much for your detailed review! 

Please see inline below...

Thanks,

-- Yimin

On 7/3/19, 9:28 AM, "Alvaro Retana via Datatracker" <[e-mail]> wrote:

    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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=nuNPJGM9BmukPhjCkjpAn-PyeWi8JF7vdeWqL8Mz9d0&s=nr6mCLXg1zg1sTPehwxetvAKufeEIOt4EBk8gZY6-8Q&e= 
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Degress-2Dprotection-2Dframework_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=nuNPJGM9BmukPhjCkjpAn-PyeWi8JF7vdeWqL8Mz9d0&s=Y3bLarolWCLz2lGxXMJgwgQhyNDoP-mD7QJde9SF91I&e= 
    
    
    
    ----------------------------------------------------------------------
    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.
    
[yshen] The protector is not an MP. In egress protection, there is no MP, as rerouted traffic doesn't merge back to the original data path.

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

[yshen] Will change "if ... " to "as the sub-LSPs of these tunnels can be
    viewed as P2P tunnels."
    
    (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.
    
[yshen] The draft does points out where extensions may be needed or have been provided by other drafts and RFCs. This is done in some sections, as the procedures are described.

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

[yshen] Will fix this as suggested.

    (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

[yshen] Will fix this as suggested.
    
    (6) §4: s/considers the followings/considers the following

[yshen] Will fix this as suggested.

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

[yshen] I agree. Will replace the normative language MAY/SHOULD/MUST in this section with may/should/must. 
    
    (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?
    
[yshen] Yes, it MUST be fast in order to get the benefit.

    (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
   
[yshen] Will fix this as suggested.
 
    (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?

[yshen] This section talks about the applicability of the egress node mechanism. Will clarify this by saying that it is not a run time decision of the PLR, but an applicability decision of the operator based on the characteristics of the network and services. 
    
    (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
    
[yshen] Will fix this as suggested.

    (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

[yshen] Will fix this as suggested.

    (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
 
[yshen] Will check and fix all the places.
   
    (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.
 
[yshen] Will fix this as suggested.
   
    (15) s/IPv4/v6/IPv4/IPv6
    
[yshen] Will fix this as suggested.

    (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
    
[yshen] Will fix this as suggested.

    (17) Please expand UHP.
 
[yshen] Will fix this as suggested.
   
    (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.
    
[yshen] Will fix by removing this.

    (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.
 
[yshen] Will remove [SR-OSPF], and suggest to define it 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.
    
[yshen] This just points back to statement proceeding it --- "The correctness of the egress-protected tunnels and the bypass  tunnels relies on the path computations for the anycast IP  address performed by the ingress routers and PLR.  Therefore, care MUST be taken for the applicability of this approach to a network."

    (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
    
[yshen] Will fix this as suggested.

    (22) §5.11: "Specific extensions MAY be needed..."  Again, just a fact. 
    s/MAY/may'
   
[yshen] Will fix this as suggested.
 
    (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?

[yshen] Will change it to "should".

    (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
   
[yshen] Will fix this as suggested.
 
    (25) §8: s/it is RECOMMENDED that the router SHOULD generate/it is RECOMMENDED
    that the router generate    RECOMMENDED = SHOULD

[yshen] Will fix this as suggested.
    
    (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.
    
[yshen] Will fix this as suggested.