Subject: [Bier] Shepherd's review of draft-ietf-bier-bar-ipa

From: Greg Mirsky <[email-masked]>
Date: Wed, 9 Sep 2020 09:56:12 -0700

Dear WG Chairs,
we're waiting for one author to respond to the IPR poll on the draft.

Dear Authors,
thank you for the well-written document. The proposed solution is elegant
and presented clearly. I have several comments and questions. Also a number
of nits that may be worth your attention. First, comments and questions:

   - In Section 2 the requirement to provision BAR and IPA values uses
   SHOULD:

   For a particular sub-domain, all routers SHOULD be provisioned with
   and signal the same BAR and IPA values.

Do you think that the MUST is more suitable and would not require a change
of the text that follows?

   - Could the following benefit from the use of the normative language?

   It is expected that both the BAR and IPA values could have both
   algorithm and constraints semantics.
>From the text that follows, it seems that both semantics are required for a
router to calculate the underlay path. Is that correct? Also, is there a
default value of a semantic? If that is the case, it would be helpful to
state that explicitly.

   - There is a pair of requirements in Section 2:

   When a new BAR value is defined, its corresponding BC/BA semantics
   MUST be specified.  For a new IGP Algorithm to be used as a BIER IPA,
   its RC/RA semantics MUST also be clear.
The last sentence can benefit from mode details of what is required to make
RC/RA semantics clear. Would s/clear/clearly specified/ be acceptable?

Nits:

   - AFAIK, references are not used in an abstract text, instead reference
   an RFC as text, e.g., "RFC 8444 and RFC 8401".
   - rules for introducing abbreviations (Section 3.6 RFC 7322
   <https://tools.ietf.org/html/rfc7322#section-3.6>) explain that:

   Abbreviations should be expanded in document titles and upon first
   use in the document.  The full expansion of the text should be
   followed by the abbreviation itself in parentheses.

Several cases, e.g., BAR and IPA, don't follow that rule.

   - BFR (Section 2) needs expansion on the first use.
   - s/a IPA/an IPA/
   - s/a RCRA/an RCRA/
   - s/with semantics/ with the semantics/
   - s/are augmented/is augmented/
   - s/secuity/security/
   - s/thanks/thank/

Regards,
Greg

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 9 Sep 2020 20:04:19 -0700

Thanks Greg, et al.

The draft is currently expired. Can the authors refresh then we can move it
to the queue.

- Shep

On Wed, Sep 9, 2020 at 9:56 AM Greg Mirsky <[email-masked]> wrote:

> From the text that follows, it seems that both semantics are required for
> a router to calculate the underlay path. Is that correct? Also, is there a
> The last sentence can benefit from mode details of what is required to
> make RC/RA semantics clear. Would s/clear/clearly specified/ be acceptable?
>
> Nits:
>
>    - AFAIK, references are not used in an abstract text, instead
>    reference an RFC as text, e.g., "RFC 8444 and RFC 8401".

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 20 Sep 2020 18:03:43 -0700

Hi All,
would like to thank Authors for promptly responding to the IPR poll. The
result - no IPR reported.
Looking forward to your response to my comments and the publication of the
updated version.

Regards,
Greg M (as the Shepherd)

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 21 Sep 2020 18:16:32 +0000

Hi Greg M.,

Thanks for shepherding and the thorough review!
Please see zzh> below.

Juniper Business Use Only
From: Greg Mirsky <[email-masked]>
Sent: Wednesday, September 9, 2020 12:56 PM
To: [email-masked]; BIER WG Chairs <[email-masked]>; BIER WG <[email-masked]>
Subject: Shepherd's review of draft-ietf-bier-bar-ipa

[External Email. Be cautious of content]

Dear WG Chairs,

Dear Authors,
thank you for the well-written document. The proposed solution is elegant and presented clearly. I have several comments and questions. Also a number of nits that may be worth your attention. First, comments and questions:

  *   In Section 2 the requirement to provision BAR and IPA values uses SHOULD:
   For a particular sub-domain, all routers SHOULD be provisioned with
   and signal the same BAR and IPA values.
Do you think that the MUST is more suitable and would not require a change of the text that follows?

Zzh> These are always headaches to me. Routers not configured with same BAR/IPA values will not consider each other as BIER capable so things should still work. Strictly speaking, using SHOULD seems to be fine, but I changed it to MUST.

Could the following benefit from the use of the normative language?
   It is expected that both the BAR and IPA values could have both
   algorithm and constraints semantics.
>From the text that follows, it seems that both semantics are required for a router to calculate the underlay path. Is that correct? Also, is there a default value of a semantic? If that is the case, it would be helpful to state that explicitly.
Zzh> According to the following text:

   ...  Any of the RC/BC/BA could be "NULL", which means there are no
   corresponding constraints or algorithm.

Zzh> So the text you quoted should be fine. There  is no default value, as all must be clearly defined:

  *   There is a pair of requirements in Section 2:
   When a new BAR value is defined, its corresponding BC/BA semantics
   MUST be specified.  For a new IGP Algorithm to be used as a BIER IPA,
   its RC/RA semantics MUST also be clear.
The last sentence can benefit from mode details of what is required to make RC/RA semantics clear. Would s/clear/clearly specified/ be acceptable?

Zzh> Changed as suggested.

Nits:

  *   AFAIK, references are not used in an abstract text, instead reference an RFC as text, e.g., "RFC 8444 and RFC 8401".
Zzh> Fixed.

  *   rules for introducing abbreviations (Section 3.6 RFC 7322<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7322*section-3.6__;Iw!!NEt6yMaO-gk!TamQS9xaXAEQf8EnQikvLq6nG0DVIJfmbXDWECfZTYUBMYypbXeUtf1zEUuVk-yX$>) explain that:

  *   BFR (Section 2) needs expansion on the first use.
  *   s/a IPA/an IPA/
  *   s/a RCRA/an RCRA/
  *   s/with semantics/ with the semantics/
  *   s/are augmented/is augmented/
  *   s/secuity/security/
  *   s/thanks/thank/
zzh> All the above are fixed. Please see attached diff.
zzh> Thanks!
Zzh> Jeffrey

Regards,
Greg

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 21 Sep 2020 18:18:07 +0000

Oops. Wrong version of the diff was attached. Please see this one.

Juniper Business Use Only
From: Jeffrey (Zhaohui) Zhang
Sent: Monday, September 21, 2020 2:17 PM
To: Greg Mirsky <[email-masked]>; [email-masked]; BIER WG Chairs <[email-masked]>; BIER WG <[email-masked]>
Subject: RE: Shepherd's review of draft-ietf-bier-bar-ipa

Hi Greg M.,

Juniper Business Use Only
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 9, 2020 12:56 PM
To: [email-masked]<mailto:[email-masked]>; BIER WG Chairs <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>
Subject: Shepherd's review of draft-ietf-bier-bar-ipa

Dear WG Chairs,

Dear Authors,

Nits:

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 21 Sep 2020 12:38:26 -0700

Hi Jeffrey,
thank you for the detailed clarifications. All changes look good to me.
Please feel free to upload the working version at your convenience.

Regards,
Greg

On Mon, Sep 21, 2020 at 11:18 AM Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

> *From:* Jeffrey (Zhaohui) Zhang
> *Sent:* Monday, September 21, 2020 2:17 PM
> *To:* Greg Mirsky <[email-masked]>;
> [email-masked]; BIER WG Chairs <[email-masked]>;
> BIER WG <[email-masked]>
> *Subject:* RE: Shepherd's review of draft-ietf-bier-bar-ipa
>
>
>
> Hi Greg M.,
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Wednesday, September 9, 2020 12:56 PM
> *To:* [email-masked]; BIER WG Chairs <
> [email-masked]>; BIER WG <[email-masked]>
> *Subject:* Shepherd's review of draft-ietf-bier-bar-ipa
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear WG Chairs,
>
> Zzh> These are always headaches to me. Routers not configured with same
> BAR/IPA values will not consider each other as BIER capable so things
> should still work. Strictly speaking, using SHOULD seems to be fine, but I
> changed it to MUST.
>
>
>
>    …  Any of the RC/BC/BA could be "NULL", which means there are no
>
>    <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7322*section-3.6__;Iw!!NEt6yMaO-gk!TamQS9xaXAEQf8EnQikvLq6nG0DVIJfmbXDWECfZTYUBMYypbXeUtf1zEUuVk-yX$>)
>    explain that:
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 23 Sep 2020 01:50:47 +0000

Hi Greg,

I have uploaded -07.
Thanks!

Jeffrey

Juniper Business Use Only
From: Greg Mirsky <[email-masked]>
Sent: Monday, September 21, 2020 3:38 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; BIER WG Chairs <[email-masked]>; BIER WG <[email-masked]>
Subject: Re: Shepherd's review of draft-ietf-bier-bar-ipa

Hi Jeffrey,
thank you for the detailed clarifications. All changes look good to me. Please feel free to upload the working version at your convenience.

Regards,
Greg

On Mon, Sep 21, 2020 at 11:18 AM Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Oops. Wrong version of the diff was attached. Please see this one.

To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG Chairs <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>

Hi Greg M.,

Dear WG Chairs,

Dear Authors,

Nits:

Regards,
Greg