Re: [Bier] AD Review of draft-ietf-bier-te-arch-09

[Alvaro Retana <[e-mail]>]

On May 18, 2021 at 5:41:00 PM, Toerless Eckert wrote:


Toerless:

Hi!

Just replying to a couple of things.


...
> > (1) What is this document specifying?
> >
> > To start, I believe it is ok for an architecture document to be in the
> > Standards Track.
> >
> > As far as I can see, this document mainly specifies alternate semantics
> > for the BitString. Beyond that, the BIER-TE architecture (§2) maps well
> > onto the layering described in §4/rfc8297, where the BIER layer (§4.2/
> > rfc8297) is "replaced" with the BIER-TE Control Plane and the BIER-TE
> > forwarding layer.  Is this a fair high-level representation of what is
> > defined in this document?
>
> "replaced" is certainly how the doc is written, so as to make it read
> as simple as possible. The intent of course is to "amend" BIER by sharing
> as much as possible with it such that a joint BIER/BIER-TE implementation
> is but slightly more work than just a BIER implementation.

Simplicity is good, but being clear is better.  I would like to see a
list of the things in the BIER layer that are not replaced.  I
remember text about the differences -- think of something similar for
the things that don't change.


...
> > The BIER-TE topology is a "key new component in BIER-TE". The document
> > doesn't specify, explain, or leave out of scope how "BIER-TE Controller
> > discovers the network topology and creates the BIER-TE topology from it"
> > (§2.2). This omission is a significant hole in the architecture.
>
> How about this. As long as it is clear that no references here are
> normative, but all informational (like any similar references in RFC8279
> that are all informational too).
>
> | In statically managed networks, such as in industrial environments,
> | topology discovery may be a manual/offline process. In other networks
> | topology discovery may rely on protocols such extending the LSP IGP into
> | the controller itself, RFC7752 (BGP-LS) or RFC8345 (Yang topology) as
> | well as BIER-TE specific extensions for example via draft-ietf-bier-te-
> | yang. These examples are non-exhaustive.

Sure, that works for me.



...
> > (2) Can BIER and BIER-TE really coexist in the same network?
> >
> > The Abstract mentions that they can:
> >
> > BIER-TE can co-exist with BIER forwarding in the same domain, for
> > example by using separate BIER sub-domains.
> >
> > The result of separate sub-domains is more akin to ships-in-the-night than
> > having them be "mixed": in the same sub-domain using a single BIFT
> > (populated by different sources). Is this correct?
>
> The way in which the BIER-TE draft defines BIER-TE forwarding, it is
> exclusively "owning" a BIFT. This is because the code, e.g.: Figure 15 shows
> the bit-reset semantic for all bits to use BIER-TE ([1] vs. [2]). So, what
> you call "mixed" is not part of the draft.
>
> Of course, implementations can easily build a single implementation of
> forwarding across BIER/BIER-TE, even with semantic, BIER vs. BIER-TE
> different for every bit, but to me this is just implementation optimization.
> Reason is that i have not identified good operational benefits to make this
> part of the BIER-TE architecture. (aka: use case with some bits using bier
> othre bits in same bitstring using bier-te bit-reset logic).
>
> However, your ships-in-the night semantic is probably incorrect.
> Even BIER alone can already have multiple BIFT per sub-domain,
> because according to rfc8279, you need a combination of (sub-domain, bsl)
> to map to a BIFT, not just a sub-domain.

Does this mean that multiple BIFTs could exist in the same sub-domain,
some using only BIER and other only BIER-TE?  If so, then that should
be the clarification: they can coexist even in the same sub-domain as
long as the BIFTs are separate.


> Here is suggested text to help clarify:
>
> | When BIER-TE is used with rfc8296 encapsulation, the bift-id identifies
> | an SI, a sub-domain, and a BitStringLength (as specified in rfc8279) AND
> | whether to use BIER or BIER-TE forwarding for this bift-id.

Hmmm...that may be locally true: the local node "knows" how the
adjacencies look like and how they were populated, but the BIFR
doesn't.  Even if the controller programs the encapsulation at the
BIFR, the meaning of the BIFT-id field is not changing.  I think this
text raises more questions.

Also, the text above seems to have an implication on BIER: "When
BIER-TE is used...AND whether to use BIER or BIER-TE..."


...
> > (3) Organization
...
> Let me see if i can do the reshuffling without having to completely rewrite
> explanations (stuff was put in order of explanation dependencies).

ACK


Thanks!

Alvaro.