Explicit Tracking with Wildcard Routes in Multicast VPN
draft-ietf-bess-mvpn-expl-track-13

Thanks for the work everyone did on this document.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use and in the abstract;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - MVPN - Multicast VPN
 - I-PMSI - ???
 - P2MP - Point-to-Multipoint

I have some non-blocking comments:

(1) §3:

   The rules for finding a "match for reception" in [RFC6625] are hereby
   modified as follows:

      When applying the rules of Section 3.2.1 or 3.2.2 of [RFC6625], it
      is REQUIRED to ignore any S-PMSI A-D route that has no PTA, or
      whose PTA specifies "no tunnel information present".

   There are other RFCs that update [RFC6625] and that modify the rules
   for finding a "match for reception".  See, e.g., [RFC7582] and
   [RFC7900].  When applying those modified rules, it is REQUIRED to
   ignore any S-PMSI A-D route that has no PTA, or whose PTA specifies
   "no tunnel information present".

This text is also Updating rfc7582 and rfc7900 (and others?) that Updated rfc6625.  This document should then be marked to Update those other RFCs explicitly.

(2) How is this phrase intended to be interpreted: "the following procedure can be used if and only if it is known that the egress nodes support the optional LIR-pF flag" (§4)?  I ask because, even though there's no rfc2119 language, I would be inclined to interpret "if and only if" as an absolute requirement: just like a MUST.  However, later in the same section there is normative language that doesn't seem to match: "this procedure...if there are egress nodes that do not support the LIR-pF flag, and hence SHOULD NOT be used in that case."  I think that, in the best case, there may be some confusion in the text -- it would be good to clarify by maybe not using an expression as absolute as "if and only if".

(3) §5.1, Case 3: "...LIR-pF is set.  The egress node MUST follow whatever procedures are required by other specifications, based on the match for reception.  If the egress node supports the LIR-pF flag, it MUST also follow the procedures of Section 5.2."

The text above seems to account for the case where the egress node doesn't support the LIR-pF flag in the first sentence quoted.  However, if the node doesn't support the flag, it can't be assumed that it has knowledge of this document...which means that we shouldn't use normative language to instruct those nodes to do anything.  Also, the specification of "whatever procedures are required by other specifications" is too vague for being normative.  s/MUST/must

(4) §2: s/Since an ingress node that sets the LIR-pF flag is also REQUIRED to set the LIR flag,/Since an ingress node that sets the LIR-pF flag is also required to set the LIR flag,

The normative behavior is already specified above ("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").  I know that MUST = REQUIRED, but in this case the sentence is just stating a fact.

Thanks for the work on this!

*** Substantive Comments ***

I support Mirja's DISCUSS.

- There is an IPR disclosure with possible royalties. The shepherd report says there were no WG objections. How was the disclosure communicated? For example, was the WG reminded of the disclosure at WGLC?

*** Editorial Comments ***

§3: 
- Part way through the section, starting with "We also introduce a new notion, the "match for tracking":", there is a section of text that has a significantly different tone from the rest of the draft. It switches more of a lecture style, then switches back. I suggest an edit pass to keep a consistent tone.  (I know this is a question of style, and I will not press it further if people prefer not to change it.)

- 2 paragraphs starting with "For a given C-flow..."
Why is this indented?

Thank you for addressing my Discuss points!

[original COMMENT section preserved, though I believe that they have
all been addressed via email clarification or in the -13]

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.

Thanks for addressing my discuss!

Keeping in mind that reading multicast specifications now is like reading the denser MPLS specifications 10-15 years ago, even with the forest of unfamiliar terms in the Introduction, you manage to explain clearly what the problems being addressed are. Thank you for that effort. 

I support Mirja's Discuss, specifically because if this ever goes wrong, the people writing this spec probably know the most about what to do about it. If you can provide guidance, it will probably be better guidance than operators will get from anyone else.

(And please take this as a compliment!)

Thanks for addressing my DISCUSS