[Bier] John Scudder's No Objection on draft-ietf-bier-bar-ipa-12: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-bier-bar-ipa-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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/



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

I support Paul and Roman's DISCUSSes.

I appreciate Greg Mirsky's shepherd writeup, including the rationale for
six authors. (One per page! :-)

# COMMENTS

## SECTION 2

You use RFCs 8665 AND 8401 as your citations for two registries. But
these RFCs aren't the registries, they just established them. As far as
I'm aware, the better practice is to cite the registry directly. For an
example, look at how RFC 7606 cites the BGP Path Attributes registry:

   [IANA-BGP-ATTRS]
              IANA, "BGP Path Attributes",
              <http://www.iana.org/assignments/bgp-parameters>.

## SECTION 2

You have

   When a BAR value is defined, the corresponding BA and BC semantics
   SHOULD be specified.  For an IGP Algorithm to be used as a BIER IPA,
   its RA and RC semantics SHOULD be specified.

What happens if they aren't? Is that what you're getting at with the next
paragraph?

   None of the components of the BAR or IPA can be unknown.  If any of
   the components is not specified, it is interpreted as "NULL"
   algorithm or constraint.  For example, the IGP Algorithm 0 defined in
   [RFC8665] is treated as having a NULL RC, i.e., no constraints.

I found that paragraph to not be crystal clear. First, it's not explicit
what you mean by "components". I infer you mean RA+RC and BA+BC,
respectively. Please say so. Assuming that, you say "none of the
components... can be unknown" as if it were a statement of fact. But, the
SHOULD in the previous paragraph contradicts that: they can be unknown if
the specifier contravenes the SHOULD. Maybe (?) what you mean is something
like:

   When a BAR value is defined, the corresponding BA and BC semantics
   SHOULD be specified.  For an IGP Algorithm to be used as a BIER IPA,
   its RA and RC semantics SHOULD be specified.  If the semantics of
   any of these is not specified, the default value of "NULL" MUST be
   used. For example, the IGP Algorithm 0 defined in [RFC8665] is
   treated as having a NULL RC, i.e., no constraints (see Section 3).

## SECTION 3

The rules given in §3,

   1.  Apply the BIER constraints, resulting in BC(X).

   2.  Apply the routing constraints, resulting in RC(BC(X)).

   3.  Select the algorithm AG as following:

       a.  If BA is NULL, AG is set to RA.

       b.  If BA is not NULL, AG is set to BA.

   4.  Run AG on RC(BC(X)).

are silent about what to do if BC or RC are NULL. Maybe something like

   1. Apply the BIER constraints, resulting in BC(X). If BC is NULL,
      then BC(X) is X itself.

   2. Apply the routing constraints, resulting in RC(BC(X)). If RC is
      NULL, then RC(BC(X)) is BC(X).

would work?

## SECTION 3

Section 3 mentions that,

                                        If a BFR discovers another BFR
   advertising different BAR or IPA value for a sub-domain, it MUST
   treat the advertising router as incapable of supporting BIER for that
   sub-domain

I presume the implications have been thought through, of the fact that
this shunning behavior can be expected to apply in both directions, in
effect partitioning the domain into subdomains each one of which advertises
a homogenous (BAR, IPA) value? This kind of rule has been in BIER for a
while (since before this spec) so I assume the answer is yes, but I thought
I'd still ask.