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

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

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 <[e-mail]>; [e-mail]; BIER WG Chairs <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: Shepherd's review of draft-ietf-bier-bar-ipa

Hi Greg M.,

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



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

[External Email. Be cautious of content]

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?

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:


   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.


  *   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:
   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/
zzh> All the above are fixed. Please see attached diff.
zzh> Thanks!
Zzh> Jeffrey

Regards,
Greg