Re: [Bier] AD Review of draft-ietf-bier-bar-ipa-07

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

Hi Alvaro,

Thanks for your review and comments, and sorry for the late response.

Please see zzh> below, and the attached diff.

-----Original Message-----
From: Alvaro Retana <[e-mail]>
Sent: Thursday, September 2, 2021 2:57 PM
To: [e-mail]
Cc: Greg Mirsky <[e-mail]>; BIER WG Chairs <[e-mail]>; [e-mail]
Subject: AD Review of draft-ietf-bier-bar-ipa-07

[External Email. Be cautious of content]


Dear authors:

I just finished reading this document.  In general, for such a short
document, I think there are significant loose ends.  Please see the
details in-line below.


My biggest issue is better illustrated by this exchange during the WGLC [1]:

   =====
   > But if new BIER algorithms are defined, how would you define BC?
   > Is the idea that the values in the BIER algorithm registry signify
   > both BC and BA?

   Yes when a new value is defined, corresponding BC & BA semantics need
   to be given. I will clarify that.
   =====

I read this answer as meaning that the registries will contain the
information about the constraints *and* the algorithm.  This makes
sense to me because the draft talks about signaling the provisioned
values, which is related, I assume, to the Update to rfc8401/rfc8444.
*BUT*, the registries are not updated and it is then not clear
how/where the information will be documented so that interoperability
can be possible.

Zzh> To clarify, I did not mean the registry will contain the information. The registry only records which numbers have been assigned. The specification that defines a registered number need to clearly specify the both BC and BA.

Zzh> More below on the inline comments.

[Note that this concern applies to both the BAR and the IPA.  I based
my comments below on this interpretation.]

To the Chairs: 6 authors are listed in the front page, but rfc7322
recommends a limit of 5.  Can you please provide justification for
going over the limit?  [In general, I think that 6 is an ok number --
we just need to cross the T's...]


Thanks!

Alvaro.


[1] https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bier/N04qbGI-dNbX5H8ShWQT-167p9k__;!!NEt6yMaO-gk!Q7s45WSRSvBrP7poBxv-xC_yIS_tE-VxbAabzT0j31H8fXxJxEm1yAsPZLWeLfSC$



[Line numbers from idnits.]

...
18    Abstract

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

[major] Why isn’t draft-ietf-bier-ospfv3-extensions considered too?
It specifies the same behavior as rfc8444.

Zzh> You're right. It should be.

[major] "(when both or any of them is non-zero)"   The other documents
left non-zero values out of scope, but that doesn't mean that the
semantics can only change for those values.  Specifically, §2.1 talks
about the BC for BAR 0.  IOW, the changes to the semantics apply to
all values.

Zzh> Strictly speaking, §2.1 just clarifies what "BAR 0" means using the BA/BC terms - nothing is changed from the two RFCs.

[minor] "specifies general rules for interaction between the BAR (BIER
Algorithm) and IPA (IGP Algorithm) fields"  The interaction is not
between the fields but the algorithms.

Suggestion>
   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, RFC8444, and draft-ietf-bier-ospfv3-extensions.

Zzh> I've taken the suggested text.
...
80    1.  Introduction

82       In Bit Index Explicit Replication (BIER) architecture [RFC8279],
83       packets with a BIER encapsulation header are forwarded to the
84       neighbors on the underlay paths towards the BFERs.  For each sub-
85       domain, the paths are calculated in the underlay topology for the
86       sub-domain, following a calculation algorithm specific to the sub-
87       domain.  The <topology, algorithm> could be congruent or incongruent
88       with unicast.  The topology could be a default or non-default
89       topology [RFC5120].  The algorithm could be a generic IGP algorithm
90       (e.g.  SPF) or could be a BIER specific one defined in the future.

[nit] s/In Bit/In the Bit

Zzh> Fixed.

[minor] s/For each sub-domain, the paths are calculated in the
underlay topology for the sub-domain, following a calculation
algorithm specific to the sub-domain./The paths are calculated in the
underlay topology following a algorithm specific to each sub-domain.

Zzh> Both the topology and the algorithm could be sub-domain specific. The new text makes it sound like that only algorithm is specific to a sub-domain?
Zzh> I changed it to:

     The paths are calculated in the underlay topology for each sub-domain
     following an algorithm specific for the sub-domain.

[minor]  The last 3 sentences are wordy, and the reference to rfc5120
seems unnecessary and potentially confusing.

Suggestion>
   The topology or algorithm used may be congruent with the unicast
   topology and algorithm.

Zzh> Reference to 5120 is removed. The last sentence seems to be useful (this is why we have the BAR/IPA stuff)?

   "the algorithm could be a generic IGP algorithm
   (e.g.  SPF) or could be a BIER specific one defined in the future"

92       In [RFC8401] and [RFC8444], an 8-bit BAR (BIER Algorithm) field and
93       8-bit IPA (IGP Algorithm) field are defined to signal the BIER
94       specific algorithm and generic IGP Algorithm respectively and only
95       value 0 is allowed for both fields in those two documents.  This
96       document specifies the general rules for the two fields and their
97       interaction when either or both fields are not 0, and updates their
98       semantics defined in [RFC8444] and [RFC8401].

Suggestion (same as the 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], [RFC8444], and [draft-ietf-bier-ospfv3-extensions].

Zzh> I was subconsciously compelled to provide a bit more/different text in the introduction section than in the abstract 😊
Zzh> but I happily changed to what you suggested.

100    2.  General Rules for the BAR and IPA fields

102       For a particular sub-domain, all BIER Forwarding Routers (BFRs) MUST
103       be provisioned with and signal the same BAR and IPA values.  When a
104       BFR discovers another BFR advertising different BAR or IPA value from
105       its own provisioned, it MUST treat the advertising BFR as incapable
106       of supporting BIER for the sub-domain.  How incapable routers are
107       handled is outside the scope of this document.

[nit] s/When/If

Zzh> Fixed.

[nit] s/advertising different BAR or IPA value from its own
provisioned,/advertising different BAR or IPA values

zzh> Fixed.

[major] "...MUST treat the advertising BFR as incapable of supporting
BIER for the sub-domain.  How incapable routers are handled is outside
the scope of this document."

This is a Normative contradiction!  How are routers supposed to meet
the MUST if they don’t know what to do?  I'm assuming that being
"incapable of supporting BIER" is equivalent to being a node that
doesn't support BIER (as in §6.9/rfc8279), right?  If so, then you can
avoid the contradiction by simply using the same name as rfc8279.

s/it MUST treat the advertising BFR as incapable of supporting BIER
for the sub-domain.  How incapable routers are handled is outside the
scope of this document./it MUST ignore all BIER-related information
and treat the node as if it doesn't support BIER [rfc8279].

Zzh> Now I borrow text from RFC8401 as following:

      it MUST treat the advertising router as incapable of supporting BIER
      (one way of handling incapable routers is documented in Section 6.9
      of [RFC8279] and additional methods may be defined in the future).

[major] Given that routers with different BAR/IPA are treated as not
supporting BIER, it seems that advertising different values would be a
nice tool to divide the network into multiple independent BIER
sub-domains.  Is this an issue?  What about the interaction in the
domain itself, is having a different view of a sub-domain an issue???

Zzh> It is can indeed be used that way. It is not an issue, but it is better to define separate sub-domains.

109       It is expected that both the BAR and IPA values could have both
110       algorithm and constraints semantics.  To generalize, we introduce the
111       following terms:

[major] "It is expected"   The Normative language below requires it!

Suggestion>
   Both the BAR and IPA have algorithm and constrain semantics.  To
   generalize, we introduce the following terms:

Zzh> Fixed.

113       o  BC: BIER-specific Constraints

115       o  BA: BIER-specific Algorithm

117       o  RC: Generic Routing Constraints

119       o  RA: Generic Routing Algorithm

121       o  BCBA: BC + BA

123       o  RCRA: RC + RA

125       A BAR value corresponds to a BCBA, and an IPA value corresponds to an
126       RCRA.  Any of the RC/BC/BA could be "NULL", which means there are no
127       corresponding constraints or algorithm.

[major] "BAR value corresponds to a BCBA...IPA value corresponds to an RCRA"

Does this mean that every algorithm can have only one set of
constraints?  Or that a different value has to be used to signal the
same algorithm with a different set of constraints?

Zzh> If you look at FlexAlgo (IPA), each number identifies an <algorithm, constraints> tuple. BAR is like that, too.

Note that the values of both BAR/IPA already (as defined in
rfc8401/rfc8665) map to a single BA or RA, the constraints are not
considered.  This change in semantics should result in a change in the
registries — and a redefinition of the already assigned values.

If the registry created by rfc8665 needs to be updated to track the
constraints, then rfc8665 should also be formally Updated.  What is
the effect on other work that my use the same registry?

Zzh> Non-zero BAR/IPA value is outside the scope of 8401, which means only the SPF w/o constraints are used.
Zzh> This document defines how non-zero BAR/IPA values are used for BIER. They are considered to have BA/BC and RA/RC semantics, some of which could be NULL (a NULL BC/RC means no constraints).
Zzh> As mentioned earlier, registry only recorders numbers not semantics.

Zzh> I don't think 8665 is relevant here. It is specific to SR, which is orthogonal to BIER. In addition, 8665 says:

   +-------+--------------------------------------------+-----------+
   | Value | Description                                | Reference |
   +=======+============================================+===========+
   | 0     | Shortest Path First (SPF) algorithm based  | This      |
   |       | on link metric.  This is the standard      | document  |
   |       | shortest path algorithm as computed by the |           |
   |       | IGP protocol.  Consistent with the         |           |
   |       | deployed practice for link-state           |           |
   |       | protocols, Algorithm 0 permits any node to |           |
   |       | overwrite the SPF path with a different    |           |
   |       | path based on its local policy.            |           |
   +-------+--------------------------------------------+-----------+
   | 1     | Strict Shortest Path First (SPF) algorithm | This      |
   |       | based on link metric.  The algorithm is    | document  |
   |       | identical to Algorithm 0, but Algorithm 1  |           |
   |       | requires that all nodes along the path     |           |
   |       | will honor the SPF routing decision.       |           |
   |       | Local policy at the node claiming support  |           |
   |       | for Algorithm 1 MUST NOT alter the SPF     |           |
   |       | paths computed by Algorithm 1.             |           |
   +-------+--------------------------------------------+-----------+

Zzh> I would not expect algorithm 1 will be used with BIER; even if it is, you can see that the RA part is identical to algorithm 0.

[major] "RC/BC/BA could be "NULL"   This text hints at having part of
the BAR/IPA indicate the a constraint/algorithm, but it is not
specified anywhere which part of the value field that is.  IOW, I
assume "NULL" means that the bits in the value corresponding to the
constrain/algorithm are set to 0.

Zzh> "NULL" does not mean some 0 bits. It simply means that the BAR/IPA does not have the corresponding algorithm (BA/RA) or constraints (BC/RC) semantics. For example, a BAR 100 could mean "steiner tree" without any constraints - so the BA is "steiner tree" while BC is NULL.

129       When a new BAR value is defined, its corresponding BC/BA semantics
130       MUST be specified.  For a new IGP Algorithm to be used as a BIER IPA,
131       its RC/RA semantics MUST also be clearly specified




  Juniper Business Use Only