Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER)
draft-ietf-bier-bar-ipa-13

Thanks for the work on this document.

Thank you for addressing my DISCUSS and comments.

Francesca

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.

My DISCUSS was resolved in -13, thanks!

Old DISCUSS:



[1]
This document could instruct IANA to rename "240-254 Experimental Use" to "240-254 Private and Experimental Use", since that is what this document states:

   If a BAR value is not specified in a RFC but only privately used for
   a deployment, it MUST be within the "240-254 Experimental Use" range
   of the registry.

Furthermore, the statement implies there are two different allocation types here ("RFC" and "privately used"), but the IANA Registry shows 3 types:

   0-127 	Standards Action
   128-239 	Specification Required
   240-254 	Experimental Use

The "Specification Required" could be a non-RFC specification.

If this is done, the Abstract should mention the IANA Registry is updated and the IANA Considerations section should be updated.

[2]
   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.

   None of the components of the BAR or IPA can be unknown. [...]

Then why are these SHOULDs not MUSTs?

Thank you to Vincent Roca for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.

Dagnabbit -- I'd completely missed the IPA reference. I don't drink, but still...

</hangs head in shame>

Thank you for the work put into this document. Reading IPA in a BAR for a BIER document made me smile even at 8 AM ;-) Anyway, the document is easy to read with crystal clear specification.

Please find below one non-blocking COMMENT points and one nit.

Special thanks to:

- Greg Mirsky for the shepherd's write-up including the WG consensus and the intended status. 
- Suresh Krishnan for his INT directorate review at https://mailarchive.ietf.org/arch/msg/int-dir/KXUlJRKxuG_S2O3YSNJLg_ZwABc/  (please ensure that Suresh's comment is acted upon)

I hope that this helps to improve the document,

Regards,

-éric

## Section 1
Suggest to expand "SPF" even if it appears in https://www.rfc-editor.org/materials/abbrev.expansion.txt 

# NITS  

## Section 4

Suggest to be consistent in the use of "IPA" and "IGP Algorithm"

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

Thanks to Meral Shirazipour for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/JM0DuH-Nkq5MuFIzjTb2OthI6lQ).

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

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 1754, nit:
> . If a BAR value is not specified in a RFC but only privately used for a dep
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Hi,

Thanks for this.

A few minor comments:

(1) 
   This document specifies general rules for the interaction between the
   BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
   path calculation when other BAR and/or IPA values are used.

I wondered whether it would helpful to clarify that "other" means "non zero", e.g.,
"when other (i.e., non zero) BAR and/or IPA values are used"

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

Under what conditions can these SHOULDs be violated, or to state it another way, why are they not MUSTs?

(3) I note that this document doesn't have, or reference, any YANG, but presumably these two fields are covered by igp-algorithm and bier-algorithm in draft-ietf-bier-bier-yang-07?  Not this document, but it would be useful if those fields included this RFC-to-be in a reference statement for those two fields, perhaps with slightly enhanced descriptions to give some indication of how the fields work together.  You might also consider including an informational reference to where the YANG management interface of these two fields is defined, but I'll leave that to the authors discretion.

Regards,
Rob