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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi John,

Sorry for the late response. I took some time off and am slowly catching up.
Please see zzh> below.


Juniper Business Use Only

-----Original Message-----
From: John Scudder via Datatracker <[e-mail]> 
Sent: Tuesday, April 19, 2022 4:52 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Greg Mirsky <[e-mail]>; [e-mail]; [e-mail]
Subject: John Scudder's No Objection on draft-ietf-bier-bar-ipa-12: (with COMMENT)

[External Email. Be cautious of content]


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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!UYNUbdushdLDIl7ukQ6Z-FfAH5N3vn8wPnw9jXh70NlPJaGVv0D_jFQS1Lsph4dY$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/__;!!NEt6yMaO-gk!UYNUbdushdLDIl7ukQ6Z-FfAH5N3vn8wPnw9jXh70NlPJaGVv0D_jFQS1LhV9eHx$



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

I support Paul and Roman's DISCUSSes.

Zzh> I replied to and made changes for those.

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",
              <https://urldefense.com/v3/__http://www.iana.org/assignments/bgp-parameters__;!!NEt6yMaO-gk!UYNUbdushdLDIl7ukQ6Z-FfAH5N3vn8wPnw9jXh70NlPJaGVv0D_jFQS1MHeY1JC$ >.

Zzh> I have removed the citation for the registries.

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

Zzh> Yes.

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

Zzh> Thanks. I've updated the document as you suggested.

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

Zzh> Yes. Updated as you suggested.

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

Zzh> Yes exactly.
Zzh> Thanks!
Zzh> Jeffrey