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

[Alvaro Retana <[e-mail]>]

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


Jeffrey:

Hi!

> Please see zzh> 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://mailarchive.ietf.org/arch/msg/bier/xTt9GEW-v3iSV96bx9WbzhNSByc/


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


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


...
> Zzh> Reference to 5120 is removed.

Remove it from the References section too. ;-)


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


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


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


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