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

[Ballot comment]
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?

[Ballot 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",
              .

## 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.

[Ballot 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",
              .

## 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 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.

[Ballot discuss]
** Section 2.

  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.

If this document is redefining “experimental use” to be “privately used for a deployment” please provide the appropriate applicability statement that bounds this “deployment”.

[Ballot comment]
Thank you to Vincent Roca for the SECDIR review.

** Section 2.  I support Paul Wouter’s DISCUSS on his concerns on:

  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.

This text suggests that BAR values will be either published in an RFC or NOT.  The current ranges in that IANA registry (https://www.iana.org/assignments/bier/bier.xhtml#bier-algorithm) suggest that that only 0-127 is an RFC (Standards Action), but 128 – 239 could be either RFC or other specification (Specification Required). 

** Section 2.

The definition for the BAR and IPA fields in [RFC8401] and [RFC8444]
  are updated as follows.

Please be specific on which text is being modified – Section 6.1 of RFC8401 and Section 2.1 of RFC8444.

[Ballot comment]
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".

[Ballot comment]
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

[Ballot comment]
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"

[Ballot 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?

[Ballot discuss]
Thanks for the work on this document.

The DISCUSS comment is easy to fix (missing reference), but I also have a couple of minor comments - for the first one I'd like to see a response but the others are suggestions, please feel free to implement or disregard as you see fit.

Francesca

1. -----

Missing Reference: 'RFC8665' is mentioned on line 123, but not defined

[Ballot comment]
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.

FP: While I think BA and RA are self-explanatory, I looked (and couldn't find quickly) pointers to BC and RC semantics. Could you please add a pointer to the RFCs and sections defining what qualifies as BCs and RCs? I also believe more context around the use of SHOULD is warranted - in what cases are exceptions to the SHOULD likely to arise and why is that ok? It seems to me that the "catch all" following paragraph (see below) should not leave authors of new registrations thinking "it's ok if I don't mention constraints" because they don't understand what they are supposed to be.

  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.

3. -----

Section 2

FP: I note that the "1 octet" or "single-octet" definition for both BAR and IPA has disappeared. I think this is OK, given that the registry covers only values in the 1 byte registry, but I want to make sure that is not an oversight.

4. -----

Section 2

FP: (weak) suggestion to add references to the IANA registries directly, rather than to the RFCs defining them.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bier-bar-ipa-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-04):

From: The IESG
To: IETF-Announce
CC: Greg Mirsky , aretana.ietf@gmail.com, bier-chairs@ietf.org, bier@ietf.org, draft-ietf-bier-bar-ipa@ietf.org, gregimirsky@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BIER Underlay Path Calculation Algorithm and Constraints) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'BIER Underlay Path Calculation
Algorithm and Constraints'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-04-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies general rules for the interaction between the
  BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
  path calculation.  The semantics defined in this document update
  RFC8401 and RFC8444.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-Up. Changes are expected over time.

(1) the document is on the Proposed Standard track that is the appropriate direction as the document, upon its approval, will update RFCs 8401 and 8444

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document specifies general rules for interaction between the  BIER Algorithm (BAR) and IGP Algorithm (IPA) fields defined in ISIS/OSPFv2 Extensions for BIER.  The semantics for the BAR and IPA fields (when both or any of them are non-zero) defined in this document and updates the semantics defined in RFC 8401 and RFC 8444.

Working Group Summary:

The draft was first submitted in March 2018, has been reviewed by a reasonable number of people in the BIER and LSR working groups, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Alvaro Retana


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by BIER and IGP experts.

(5) The Document Shephard doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document ID nit notes that there are six names listed on the front page. The authors and the WG believe that all of the authors have provided valuable contributions to the document and moving a single one to the Contributors List section doesn't seem fair. Thus, the WG and Shepherd agreed to have names of all six co-authors listed on the front page.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document does not include a downward reference.

(16) The publication of this document will update RFCs 8401 and 8444, which appropriately noted in the Abstract and Introduction.

(17) The document does not have any requests for IANA.

Shepherd Write-Up. Changes are expected over time.

(1) the document is on the Proposed Standard track that is the appropriate direction as the document, upon its approval, will update RFCs 8401 and 8444

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document specifies general rules for interaction between the  BIER Algorithm (BAR) and IGP Algorithm (IPA) fields defined in ISIS/OSPFv2 Extensions for BIER.  The semantics for the BAR and IPA fields (when both or any of them are non-zero) defined in this document and updates the semantics defined in RFC 8401 and RFC 8444.

Working Group Summary:

The draft was first submitted in March 2018, has been reviewed by a reasonable number of people in the BIER and LSR working groups, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Alvaro Retana


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by BIER and IGP experts.

(5) The Document Shephard doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document is ID nits free.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document does not include a downward reference.

(16) The publication of this document will update RFCs 8401 and 8444, which appropriately noted in the Abstract and Introduction.

(17) The document does not have any requests for IANA.

Shepherd Write-Up. Changes are expected over time.

(1) the document is on the Proposed Standard track that is the appropriate direction as the document, upon its approval, will update RFCs 8401 and 8444

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document specifies general rules for interaction between the  BIER Algorithm (BAR) and IGP Algorithm (IPA) fields defined in ISIS/OSPFv2 Extensions for BIER.  The semantics for the BAR and IPA fields (when both or any of them are non-zero) defined in this document and updates the semantics defined in RFC 8401 and RFC 8444.

Working Group Summary:

The draft was first submitted in March 2018, has been reviewed by a reasonable number of people in the BIER and LSR working groups, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Alvaro Retana


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by BIER and IGP experts.

(5) The Document Shephard doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document is ID nits free.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document does not include a downward reference.

(16) The publication of this document will update RFCs 8401 and 8444, which appropriately noted in the Abstract and Introduction.

(17) The document does not have any requests for IANA.

Request for posting confirmation emailed to previous authors: Hooman Bidgoli , Andrew Dolganow , Zhaohui Zhang , IJsbrand Wijnands , Tony Przygienda , Arkadiy Gulko , bier-chairs@ietf.org