[bess] Alvaro Retana's No Objection on draft-ietf-bess-mvpn-expl-track-12: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-mvpn-expl-track-12: 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-bess-mvpn-expl-track/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.