Re: [Bier] Francesca Palombini's Discuss on draft-ietf-bier-bar-ipa-11: (with DISCUSS and COMMENT)

[Francesca Palombini <[e-mail]>]

Hi Jeffrey,

Thanks for the quick reply! Answers look good and I will remove the DISCUSS as soon as the new version is uploaded to the datatracker. 2. Leaves me a bit uneasy but I understand this might not be a problem this document can fix, so be it. And for 4. Yes: I did intend a reference directly to the IANA registries you highlight below, but again that is a weak personal preference on my part, so feel free to skip if you’d rather keep the RFC references instead there.

Francesca

From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Date: Tuesday, 12 April 2022 at 18:12
To: Francesca Palombini <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Greg Mirsky <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Francesca Palombini's Discuss on draft-ietf-bier-bar-ipa-11: (with DISCUSS and COMMENT)
Hi Francesca,

Thanks for your review and comments. Please see zzh> below and attached diff.

-----Original Message-----
From: Francesca Palombini via Datatracker <[e-mail]>
Sent: Tuesday, April 12, 2022 9:06 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Greg Mirsky <[e-mail]>; [e-mail]; [e-mail]
Subject: Francesca Palombini's Discuss on draft-ietf-bier-bar-ipa-11: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Francesca Palombini has entered the following ballot position for
draft-ietf-bier-bar-ipa-11: Discuss

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!VA7gFzKl7l6tQwlHOhe-DkTZ0rqCSbU80AsjFyBsVty_ycEP0cx5OWO8n5YEweDj$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!VA7gFzKl7l6tQwlHOhe-DkTZ0rqCSbU80AsjFyBsVty_ycEP0cx5OWO8n5YEweDj$>
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!VA7gFzKl7l6tQwlHOhe-DkTZ0rqCSbU80AsjFyBsVty_ycEP0cx5OWO8n8jQeO3H$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-bar-ipa/__;!!NEt6yMaO-gk!VA7gFzKl7l6tQwlHOhe-DkTZ0rqCSbU80AsjFyBsVty_ycEP0cx5OWO8n8jQeO3H$>



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

Zzh> Thanks for catching that. Fixed.

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

Zzh> There is no RFC that splits an algorithm to "algorithm" and "constraints" parts. FlexAlgo has that concept but it is not explicitly called out either.
Zzh> Someone may define an IPA w/o considering BIER implications at all (they could be unaware of BIER at all), so we have to rely on the catch-all clause if that algorithm is later used for BIER.

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.

Zzh> It is an oversight. Added back.

4. -----

Section 2

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

Zzh> It seems that we normally mention a registry together with the RFC that creates it, which is what is done here? Do you mean to provide a web link to the IANA registry?

   IPA: IGP Algorithm.  Specifies a generic Routing Algorithm (RA) and
   related Routing Constraints (RC) to calculate underlay paths to reach
   other Bit-Forwarding Routers (BFRs).  Values are from the "IGP
   Algorithm Types" registry [RFC8665].

   BAR: BIER Algorithm.  Specifies a BIER-specific Algorithm (BA) and
   BIER-specific Constraints (BC) used to either modify, enhance, or
   replace the calculation of underlay paths to reach other BFRs as
   defined by the IPA value.  Values are allocated from the "BIER
   Algorithm" registry [RFC8401].

Zzh> Thanks!
Zzh> Jeffrey


Juniper Business Use Only