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

[Alvaro Retana <[e-mail]>]

On October 25, 2021 at 1:33:45 AM, Jeffrey (Zhaohui) Zhang wrote:


Jeffrey:

Hi!

Thanks for the update and your patience.

In short, I still have the same concerns about the
specification/registration  of the constraints for each algorithm and
how that works in practice.  I put more comments below, but we should
talk live instead of going in circles.  It should help me better
understand what you see that I don't.  [I don't expect replies to my
related comments below -- we can use those to help me understand when
we talk f2f.]

Here's a link to my calendar, pick a time that works for you:
https://doodle.com/mm/alvaroretana/book-a-time

Please see inline.

Happy Holidays!

Alvaro.



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

Are you expecting the semantics to be specified in an RFC?  --- or is
this an operator/implementation thing?  Let me explain -- thanks for
being patient and for filling any gaps that I may have!

- For a BAR, the constraints can be many: avoid x, use y, etc.  Is it
expected that a different BAR codepoint will be assigned for each
possible BC?

- For the IPA.  I would imagine that a typical IPA might be first
defined to be used with the IGPs.  The text above implies extra
specification when it says "to be used as a BIER IPA".  In this case,
same questions as above?  Also, that seems to mean that a new IPA
using codepoint P may not be used as a BIER IPA until RCs are
defined...and, as above, that may take a different codepoint...

- For both, what should a receiver do if unknown?



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

Hmm... There has to be a way to get that in there, I just don't know
what it is. :-(  You might want to ask [e-mail]  Let's not
forget about it.



...
> ...
> > [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
> Zzh2> routers. Otherwise, they can do bad damage by simply advertising
> Zzh2> wrong information that is not BIER related at all.

Yes, avoiding rogue routers would eliminate this issue.  But that is
akin to saying that configuration errors will never occur: there's a
very fine line between a misconfiguration and an attack.  :-(

Put another way: what would be the effect of such a misconfiguration?

See more later in the Security Considerations section.



> ...
> > 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
> zzh2> signal the same algorithm with a different set of constraints.

I am definitely missing where that text is. :-(  Can you please point me to it?

This is related to my question/confusion about the registries.  If the
registries are not changed, meaning that there's only a "Description"
field, then I guess that the expectation if for that field to indicate
the constraints.  Is that it?

For example, the BIER Algorithm registry would include something like
this for a new BIER Algorithm:

  Value   Description

   P      BIER Algo P, constraints: no constraints
   P+1    BIER Algo P, constraints: consider only BIER nodes

??


If that is the case, then this document needs to also update the
instructions to the DEs so that they are aware of this requirement.



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

How does the router/operator recognize that the resulting AG may not
be applicable to BIER?  All BAs should be applicable -- so it is a
matter of recognizing which RAs may not be.



> 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.
> Zzh2> I think it's fine to use BC/BA here, but I can change as well.

Perhaps change "BC/BA" with "BC and BA" then.  I'm sure others will be
confused my the terminology.



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

This is where my issues with the definition come from, and my
confusion/questions about the registries: a new IGP Algorithm defined
by lsr to be used by OPSF (for example) will take up a codepoint in
the registry...but that algorithm may not be able to be used as a BIER
IPA until/unless the RC and RA semantics are specified.  A separate
document can specify those semantics -- there may be multiple RCs for
the same algorithm, but only one codepoint.

This is one where we will be better off talking about so you can walk
me through it.


> > [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
> Zzh2> and I replied above (and added I the draft) - when you use an
> Zzh2> algorithm that does not apply to BIER, you have a network design issue
> Zzh2> not a protocol issue.

You obviously have a better understanding of this and I do...but "I
would say 0 is applicable" is a long way from "semantics MUST be
specified".

Also, "I don't think 1 is applicable" doesn't make it clear to me why
a strict SPF is not applicable.  How would an operator recognize that
1 is not applicable (before deciding on its use)?  Are they just
expected to know?  Or is the fact that the applicability hasn't been
specified in an RFC enough?

The new text in ^2.2 (Compatibility) is also not strong enough either way.



...
> 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"
> Zzh2> while RC could be "exclude green links". "BA" could be "steiner tree"
> Zzh2> (vs. SPF). You can see that it is better to advertise and register
> Zzh2> them separately.

...yes, if the registration includes the constraints...  [Yes, I know
I keep coming back to this...  Hopefully talking will set me
straight.]



...
> 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
> Zzh2> general rules, so they're different and better stay as is?

I don't see the difference...except that maybe the General Rules may
be changed for existing (not new) BAR or IPA.

In any case, the suggestion was to simply move this text to §2, where
the General Rules are defined.



...
> 165 3. Examples
...
> [] 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
> zzh2> links so "exclude BIER-incapable routers" and "exclude green links"
> zzh2> will end up an empty set.

I meant, in the document. :-)


>
> ...
> 182 5. Security Considerations
...
> [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
> Zzh2> to say. But for your example of a "rogue router" - it can do much more
> Zzh2> damage by simply advertising basic wrong information - not even BIER-
> Zzh2> related, right?

Maybe...but, for this document, we care about the specific things that
are being specified.

Yes, a rogue router can do many more things...the point is that before
this specification the interaction of the combination of BAR/IPA was
different.

For example:

   A rogue router may advertise incorrect or inconsistent BAR or IPA values
   that can result in unexpected forwarding decisions or even empty
   topologies. While this threat is a product of the interaction as
   specified in the general rules, it is not new in the context of the
   corresponding IGP advertisements.

It's ok if you want to add this only if someone asks.

[]