Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen <[e-mail]>]

Benjamin,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues.

Please let me know whether this is the case.

And thank you for doing such a careful review.

Eric


On 10/22/2018 9:41 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-bess-mvpn-expl-track-12: Discuss
>
> 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=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0&s=UWa2_MZELEQCZBxgLuEXDrhFGiFhDaSLecKezEgQJSk&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-2Dbess-2Dmvpn-2Dexpl-2Dtrack_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=_As6D3lr-KYW2BdIKLvT4bjw3HDCFWJBsOFYObf1E_0&s=Zs4cZ41OK1XktcOKuVjcsMkGQmpuzOc9fWuTjx1HQZY&e=
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This document places normative requirements on new tunnel types but does
> not indicate this in a way that someone specifying a new tunnel type would
> be forced to see.  This occurs both in Section 5.2:
>
>     o  When additional tunnel types are defined, the specification for
>        how MVPN is to use those tunnel types must also specify how to
>        construct the PTA of a Leaf A-D route that is originated in
>        response to the LIR-pF flag.  As an example, see [BIER-MVPN].
>
> and in Section 6:
>
>     If L's PTA specifies a tunnel type not mentioned above, the
>     specification for how MVPN uses that tunnel type must specify the
>     actions that N is to take upon receiving L.  As an example, see
>     [BIER-MVPN].
>
> I think the best way to do this would be to have IANA Considerations
> updating the registration procedure for
> P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
> new registrations must include this information.  It might also suffice to
> call out the existence of these requirements in the portion of the
> Introduction that discusses how this document Updates RFC 6514 (though, per
> the COMMENT section, this portion of the Introduction doesn't exist in a
> good form yet).
>
> Thank you for providing the BIER example, though -- it is helpful to see
> how the requirement plays out in practice!
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
>     This document clarifies the procedures for originating and receiving
>     S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
>     procedures to allow more efficient explicit tracking.  The procedures
>     being clarified and/or extended are discussed in multiple places in
>     the documents being updated.
>
> This is in effect saying to the reader, "you must read the updated
> document(s) in their entirety and decide for yourself whether a procedure
> being updated is described", which is perhaps not the most friendly thing
> to be doing.
>
> Section 2
>
>     If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
>     flag of that PTA MUST also be set.
>
> What do I do if I receive a PTA in violation of the MUST?
>
>     Note that support for the LIR-pF flag is OPTIONAL.  This flag SHOULD
>     NOT be set unless it is known that all the PEs that are to receive
>     the route carrying the PTA support the flag.  How this is known is
>     outside the scope of this document.
>
> Maybe remind us what a PE that doesn't support this flag will do if it
> happens to receive a PTA with it set?  (I see discussion below of the state
> at the ingress node in this case, but not an explicit confirmation of what
> egress nodes do.)  It would also be nice to give non-normative examples of
> how a sender might know that receivers support the flag.
>
> Section 3
>
>     The rules for finding a "match for reception" in [RFC6625] are hereby
>     modified as follows:
>
> Maybe give a section reference too?  (Especially since 6625 does not use
> the abbreviated version we define here, and instead writes "Finding the
> Match for Data Reception".)
>
>        For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for
>        tracking" is chosen as follows.  Ignore any S-PMSI A-D route that
>        has no PTA.  Also ignore any S-PMSI A-D route whose PTA specifies
>        "no tunnel information present", but does not have either LIR or
>        LIR-pF set.  (That is, DO NOT ignore an S-PMSI A-D route that has
>
> I think this would be clearer as "and has neither LIR nor LIR-pF set" --
> the "but" can easily lead the reader astray.
>
>        a PTA specifying "no tunnel information present" unless its LIR
>        and LIR-pF bits are both clear).  [...]
>
>        Note that the procedure for finding the match for tracking takes
>        into account S-PMSI A-D routes whose PTAs specify "no tunnel
>        information present" and that have either LIR or LIR-pf set.  The
>        procedure for finding the match for reception ignores such routes.
>
> Why are we talking about this like LIR and LIR-pF can be set independently,
> when just last page we said that if LIR-pF is set, LIR MUST be set?
>
> Section 4
>
> Please expand I-PMSI on first usage.
>
>         When following this procedure, the PTA of the S-PMSI A-D route
>         may specify a tunnel, or may specify "no tunnel information
>         present".  The choice between these two options is determined by
>         considerations that are outside the scope of this document.
>
> Could you give some examples of what sort of things might be involved in
> making that choice?
>
> Section 5.3
>
>     Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel,
>     and also has LIR-pF set.  [...]
>
> nit: is this this "route being forwarded" (i.e., where the ABR/ASBR acts as
> egress) or the "after forwarding route" (i.e., where the ABR/ASBR acts as
> ingress)?
>
>     As a result of propagating such an S-PMSI A-D route, the egress ABR/
>     ASBR may receive one or more Leaf A-D routes that correspond to that
>     S-PMSI A-D route.  [...]
>
> Just to check my understanding (no document change requested), this
> correspondance is determined by the NLRI in the Leaf A-D route matching the
> NLRI from the S-PMSI A-D route?
>
>     The "global administrator" field of the modified RT will be set to
>     the IP address taken either from the S-PMSI A-D route's next hop
>     field ([RFC6514]), or from its Segmented P2MP Next Hop Extended
>     Community ([RFC7524]).
>
> How do I choose which one to use?
>
> Section 6
>
>     then the action taken by N when it receives L is a local matter.  In
>     this case, the Leaf A-D route L provides N with explicit tracking
>     information for the flow identified by L's NLRI.  However, that
>     information is for management/monitoring purposes and does not have
>     an effect on the flow of multicast traffic.
>
> I would prefer to say "does not necessarily have an effect".
>
> Section 9
>
> I agree with the secdir reviewer that some mitigation for the new problem
> indicated is appropriate.  (Some justification for why the problem is
> insoluble in the scope of this document might also suffice.)
>
> Additionally, it seems that the mechanisms here can require more state to
> be maintained in the SP network than a pure 6513/6514 solution would, and
> that could be worth mentioning (along the lines of 6513's mention of the
> potential for overload when multicast activity exceeds expectations).
> Similarly, additional implementation limitations may be advisable.
>
>