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

[Alvaro Retana <[e-mail]>]

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.

[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://mailarchive.ietf.org/arch/msg/bier/N04qbGI-dNbX5H8ShWQT-167p9k



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


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


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


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

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


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


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


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


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


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


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


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:


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?

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?


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


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.

[minor] "BC/BA"  The terminology used "BCBA".


[minor] "RC/RA"  The terminology used "RCRA".


[major] Does the requirement only apply to "IGP Algorithm to be used
as a BIER IPA"?  If these algorithms (like a simple SPF) can be
defined elsewhere, how can this requirement be enforced?


[major] (Related) I’m assuming that the existing IGP Algorithms can be
used as a BIER IPA — what are their RCRA semantics?  What about the
flex-algos?  How will these values be distinguished from other that
are not to be used as a BIER IPA?


[major] "MUST also be clearly specified"  In a normative context, what
does "clearly" mean?


133       For a particular topology X (which could be a default topology or
134       non-default topology) that a sub-domain is associated with, a router
135       calculates the underlay paths according to its provisioned BCBA and
136       RCRA the following way:

[minor] s/For a particular topology X (which could be a default
topology or non-default topology) that a sub-domain is associated
with/For the particular topology associated with the sub-domain


[major] "a router calculates"  Should this phrase include some sort of
Normative language ("MUST calculate", for example)?


[nit] s/ the following way/in the following way


“Provisioned” ??   Are the constraints provisioned or defined as part
of the value??


138       1.  Apply the BIER constraints, resulting in BC(X).

[major] Apply to what?/What is X?  I’m guessing (based on 4 below)
that you mean the topology (eliminate nodes, etc.), but how do you
know the topology if you haven't run the algorithm?   I feel like I'm
missing something obvious...


140       2.  Apply the routing constraints, resulting in RC(BC(X)).

[major] I thought RCs applied to the RA -- but you're applying them to
whatever results from the application of the BC.  Again, I'm probably
missing something obvious.


142       3.  Select the algorithm AG as following:

144           A.  If BA is NULL, AG is set to RA.

146           B.  If BA is not NULL, AG is set to BA.

148       4.  Run AG on RC(BC(X)).

[] The result is then that the constraints apply to whichever
algorithm is used, regardless of whether the constraints were
associated with it.  Right?

The obvious questions, at least for me, is: why advertise 2 algorithms
if only one matters...and why advertise the constraints as associated
to an algorithm if they're not?


150    2.1.  When BAR Is Not Used

152       The BIER Algorithm registry established by [RFC8401] and also used in
153       [RFC8444] has value 0 for "No BIER specific algorithm is used".  That
154       translates to NULL BA and NULL BC.  Following the rules defined
155       above, the IPA value alone identifies the calculation algorithm and
156       constraints to be used for a particular sub-domain when BAR is 0.

[] Suggestion>
   BAR value 0 is defined as "No BIER-specific algorithm is used" [rfc8401].
   This value indicates NULL BA and BC.  Following the rules defined above,
   the IPA value alone identifies the calculation algorithm and constraints
   to be used for a particular sub-domain.


158    2.2.  Exceptions/Extensions to the General Rules

160       Exceptions or extensions to the above general rules may be specified
161       in the future for specific BAR and/or IPA values.  When that happens,
162       compatibility with defined BAR and/or IPA values and semantics need
163       to be specified.

[] The expectations about new BAR/IPA are also mentioned in §2 ("When
a new BAR value...") -- please consolidate the text in one place (and
eliminate this section).  The piece that is not covered there is the
one about compatibility.


[major] This document is not defining a new BAR/IPA, but it is
introducing the concept of constraints and the need to specify the
compatibility with defined values.  I assume that the constraints for
the existing BAR/IPA values are all NULL and that there are no
compatibility issues.  Please include something about that in this
document.


165    3.  Examples

167       As an example, one may define BAR=x with the semantics of "excluding
168       BIER incapable routers".  That BIER specific constraint can go with
169       any IPA: whatever RCRA defined by the IPA is augmented with
170       "excluding BIER incapable routers", i.e., BIER incapable routers are
171       not put onto the candidate list during SPF calculation.

[nit] s/BAR=x/a new BAR


[minor] "semantics of "excluding BIER incapable routers""   Should
this be s/semantics/constraints  ??


[minor] s/i.e./e.g. (it's an example)


[minor] s/BIER incapable routers are not put onto the candidate list
during SPF calculation/routers that don't support BIER are not
considered when applying the IGP Algorithm


173       Note that if the BC and RC happen to conflict and lead to an empty
174       topology, then no native BIER forwarding path will be found.  That is
175       a network design issue that an operator need to avoid when choosing
176       BAR/IPA.

[] Please remove "native".  As part of the effort to make language
more inclusive, this is one of the words that can be sensitive.  I
think that the meaning of the sentence is not affected if the word is
removed.


[nit] s/operator need/operator needs


[] Can you please provide an example of a different constraint, or a
pair that could end up in an empty set?   Maybe using colors...


...
182    5.  Security Considerations

184       This document does not change the security aspects as discussed in
185       [RFC8279].

[major] Please also mention rfc8401, rfc8444 and
draft-ietf-bier-ospfv3-extensions.


[minor] Please add a short summary of that this document specifies
that results in no changes in security concerns.  For example:

   This document specifies general rules for the interaction between
   the BIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay
   path calculation.  It does not change the security considerations
   discussed in [RFC8279], [RFC8401], [RFC8444], and
   [draft-ietf-bier-ospfv3-extensions].


[major] The extension documents didn’t mention security related to the
BAR/IPA being non-zero -- in fact, there's only one BAR defined.   By
changing the semantics there is now interaction between them.  Are
there new risks introduced?

The one that comes to mind is the ability of a rogue router to
advertise an incorrect (or simply different) BAR or IPA which may
result in unexpected routing or even a network partition.


...
218    7.2.  Informative References
...
226       [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
227                  Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
228                  Explicit Replication (BIER)", RFC 8279,
229                  DOI 10.17487/RFC8279, November 2017,
230                  <https://www.rfc-editor.org/info/rfc8279>.

[major] Must be Normative.

[End of Review -07]