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

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

Hi Alvaro,

I submitted -09 revision.
Please see zzh> below.

-----Original Message-----
From: Alvaro Retana <[e-mail]>
Sent: Tuesday, October 12, 2021 3:17 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; Greg Shepherd <[e-mail]>
Cc: BIER WG Chairs <[e-mail]>; Greg Mirsky <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: AD Review of draft-ietf-bier-bar-ipa-07

[External Email. Be cautious of content]


On September 17, 2021 at 5:03:17 PM, Jeffrey (Zhaohui) Zhang wrote:


Jeffrey:

Hi!

> Please see zzh2> below, and the attached diff.

I have a couple of replies in-line myself.

It looks like you may have not looked at the complete review -- your
reply stops at line 131, but the comments continue.  The complete
message is in the archive:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/bier/xTt9GEW-v3iSV96bx9WbzhNSByc/__;!!NEt6yMaO-gk!WPhwF8k6XQRV883V7vXDJd86FuAtXPybcG6aqICuS24A4wD7V29je5TYyxu1eD2F$

zzh2> Sorry for that - I don't know what happened. Let me continue at the end of this message.

...
> 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.
> Zzh> The registry only records which numbers have been assigned. The
> Zzh> specification that defines a registered number need to clearly specify
> Zzh> the both BC and BA.
>
> Zzh> More below on the inline comments.

Hmm... I still don't see this as clearly as you obviously do.  Let's
get through the rest of the review/comments first before coming back
to this point.

I did see some of your comments later on (and replied to a couple).
If the registries won't reflect the constraints, then we'll want to
make the requirements for a new algorithm (what a future document has
to specify) clearly outlined.

Zzh2> The document does have the following:

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

Zzh2> Does that clearly outline the requirements for a new algorithm?

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

Greg: I need you to please look into this.


Thanks!

Alvaro.



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

The header needs to also include draft-ietf-bier-ospfv3-extensions.

Zzh2> Do you mean the following?

BIER                                                            Z. Zhang
Internet-Draft                                             A. Przygienda
Updates: 8401,8444, draft-ietf-bier-                    Juniper Networks
         ospfv3-extensions (if approved)                     A. Dolganow

That truncated “draft-ietf-bier-“ name messes up the submission tool. For now I removed the “draft-ietf-bier-ospfv3-extensions”.
...
> Zzh> Reference to 5120 is removed.

Remove it from the References section too. ;-)

Zzh2> Yes 😊

...
> [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
> Zzh> better to define separate sub-domains.

I was thinking about this from an attacker point of view: by
advertising different BAR/IPA values from a set of rogue routers an
attacker can create what looks like different sub-domains (i.e. no one
may have a complete view).

Zzh2> I assume the real protection can only come from exclusion of rogue routers. Otherwise, they can do bad damage by simply advertising wrong information that is not BIER related at all.
...
> 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 tuple. BAR is
> Zzh> like that, too.

I'm looking for text in this document.  FlexAlgo is not even
referenced here (and it probably shouldn't).

zzh2> In this document, the text shows that a different value is used to signal the same algorithm with a different set of constraints. I am using FlexAlo as an example to show that it is the same for BAR and IPA.

> 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
> Zzh> the SPF w/o constraints are used.
> Zzh> This document defines how non-zero BAR/IPA values are used for BIER.
> Zzh> They are considered to have BA/BC and RA/RC semantics, some of which
> Zzh> 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
> Zzh> orthogonal to BIER. In addition, 8665 says:

The IGP Algorithms Types registry which is what is used for the IPA
was defined in rfc8665.  Even if it is an OSPF/SR RFC, the registry is
more general than that.

Zzh2> Right; but still 8665 is irrelevant here. The only potential tie is the registry, but this document does not add anything to that algorithm registry. draft-ietf-lsr-flex-algo-17 does not update 8665 either (this is in reference to "rfc8665 should also be formally Updated").


>
> +-------+--------------------------------------------+-----------+
> | 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,
> Zzh> you can see that the RA part is identical to algorithm 0.

You hit here another issue that I have: not all IPAs may ever be used
in a BIER network, and some (I guess!) may not even apply.  Is that
distinction made only when the algorithm is defined?  What should
happen if that specific IPA not applicable to BIER is signaled in the
BIER network?

Zzh2> Then no underlay path will be calculated. I added the following:

               It's possible that the resulting AG is not applicable to BIER.
        In that case, no BIER paths will be calculated and it is a network
        design issue that an operator needs to avoid when choosing BAR/IPA.


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

Zzh2> BCBA is BC+BA in total, while BC/BA refers to BC and BA respectively. I think it's fine to use BC/BA here, but I can change as well.

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

Zzh2> The text says:

   For a new IGP Algorithm to be used as a BIER IPA,
   its RC/RA semantics MUST also be clearly specified.

Zzh2> I don't know what else can be said or done?

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

Zzh2> There are two registered:

0       Shortest Path First (SPF) algorithm based on link metric. This is the standard 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. [RFC8665]
1       Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is 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.

Zzh2> I would say 0 is applicable to BIER; RC is NULL, and RA is "SPF".
Zzh2> I don't think 1 is applicable to BIER.
Zzh2> I don't see flex-algo numbers registered yet, but as you asked earlier and I replied above (and added I the draft) - when you use an algorithm that does not apply to BIER, you have a network design issue not a protocol issue.

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

Zzh2> I meant w/o ambiguity. I removed it since it seems to be only causing trouble.


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

zzh2> Fixed.

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

Zzh2> Fixed.


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

Zzh2> Fixed.


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

Zzh2> Routers can have IPA provisioned or signaled (e.g. as signaled in draft-ietf-lsr-flex-algo-17). As of now we don't expect BARs need to be signaled - their semantics are either provisioned consistently on routers or well-known and well-defined (e.g. a new draft may define a BAR value for steiner tree and another for "skip all BIER incapable routers").
Zzh2> I removed the "provisioned" wording - it's better this way.

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

zzh2> Previous paragraph says:

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

Zzh2> So X is the topology (as in OSPF/ISIS multi-topology). That does not require the algorithm. That topology can be furthered pruned by apply BC(X) and/or RC(X).

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.

Zzh2> Both BC and RC apply to the topology - one is BIER specific (associated with BAR) and one is associated with IPA. Taking the flexalgo example. You have a topology, and the flexalgo may say "exclude green links" - that's RC. BC could have excluded more (e.g. those nodes who don't support BIER).

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?

Zzh2> Using the above example - BC could be "exclude BIER-incapable routers" while RC could be "exclude green links". "BA" could be "steiner tree" (vs. SPF). You can see that it is better to advertise and register them separately.

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.

Zzh2> Thanks. I updated the text.

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.

Zzh2> Earlier text is about a new BAR/IPA value. This section is about the general rules, so they're different and better stay as is?

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

Zzh2> Added a short sub-section.

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

Zzh2> Done.


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

zzh2> Yes.

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

Zzh2> It refers to "excluding BIER incapable routers", so it is an "i.e."?

[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

zzh2> Done.

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.

Zzh2> Hmm ... https://datatracker.ietf.org/doc/draft-knodel-terminology/07/ does not list "native"? and https://www.usca.edu/diversity-initiatives/training-resources/guide-to-inclusive-language/inclusive-language-guide/file actually says "native" is preferred in some cases.

Zzh2> Anyway, I removed it.


[nit] s/operator need/operator needs

Zzh2> Fixed.

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

zzh2> In the earlier example, it could be that all BFRs's links are green links so "exclude BIER-incapable routers" and "exclude green links" will end up an empty set.

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

Zzh2> Done.


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

Zzh2> Thanks!

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

Zzh2> Security section is always my headache and I usually don't know what to say. But for your example of a "rogue router" - it can do much more damage by simply advertising basic wrong information - not even BIER-related, right?

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

Zzh2> Fixed.

Zzh2> Thanks a lot for your close review and patience 😊
Zzh2> Jeffrey

[End of Review -07]




  Juniper Business Use Only