Re: [Bier] Éric Vyncke's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)

[Toerless Eckert <[e-mail]>]

Thanks, Eric Vyncke

Detailed replies for your comments below inline.
It should resolve all your concerns.
These have been integrated into draft rev -12
which the authors feel is ready for RFC editor.

Full diff from -11 to -12:

http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt

Diff with just the deltas for comments by Eric Vyncke, Eric Kline, Martin Vigoroux and Lars Eggert

http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/c88c22d82f8e17e66929e2f0d82ca02680b8fe0e/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/ca1c4ec15302e5287c0bd60b9f14d2c58428e50f/draft-ietf-bier-te-arch.txt

Thanks again for your review.

Toerless

On Thu, Aug 26, 2021 at 05:04:12AM -0700, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-bier-te-arch-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. As I am back from vacations, I
> am afraid that I had only browsed quickly through this dense document, please
> accept my apologies for that. Please also note that I am not familiar with BIER.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Abstract --
> I find the statement "Co-existence of BIER and BIER-TE forwarding in the same
> domain is possible, for example by using separate BIER sub-domains (SDs)" quite
> an oxymoron as co-existence in a single domain requires splitting the domain
> into sub-domains. Suggest to rather mention sharing the BIFT-id address space
> among BIER and BIER-TE.

"BIER sub-domains" is not referring to a non-BIER-specific / generally
applicapple operator method such as splitting up the network of one administrative
 domain into (virtually) non-overlapping sub-topologies of routers! If it
was that, then i think that would be a tautology, not an oxymoron though.

Instead, BIER sub-domains are a fundamental architectural/protocol element of BIER,
mentioned 120 times in rfc8279. Each BIER packet belongs to a particular BIER
sub-domain, so the sub-domain value must somehow (explicitly or implicitly)
be signlled with the BIER packet. Typically this is via the bift-id field of
the rfc8296 BIER header.

The BIFT-id is just an rfc8296 construct, mentioned in rfc8279 only 5 times in
reference to rfc8296. Therefore, the BIER-TE arch is also trying to refer primarily
to the BIER architecture component sub-domain, and to the bift-id only in reference to
rfc8296. 

Aka: I am sure BIER sub-domain is the right choice here.

> In the statement "BIER-TE can also be a good fit to support multicast path
> steering in Segment Routing (SR) networks" s/can also be a good fit/is shown to
> be a good fit/ ? Even if section 6 is really light on the topic.

Explicit suggestions how to improve section 6 welcome.

The line of thought why it would be a good fit is IMHO very simple: SR is source
routing with an in-packet path. BIER-TE is source-routing of multicast
with of an in-packet tree.  I thought the text does actually elaborate 
that well!

I can not write "is shown", because that would require IMHO deployment experience
of SR together with BIER. Instead we even had some animosity between SR and
BIER proponents, and the text actually tries to start bridging that gap.

> -- Section 1 --
> Please expand "BIFT" and "BFR" at first use as other BIER terms are expanded.

Done. Thanks. *sigh*. I am sure i went through "first use - expand" more
than once, but then its easily forgotten on individual review fixes later
on. I wish there was a better tool for this problem. 

I went a bit more through the text trying to find cases where i may not have done
this correctly (forgot quotes around expansion when defining abbreviation).

> -- Section 2.4 --
> The blanket/broad statement that "Forwarding of BIER-TE is designed to easily
> build/program common forwarding hardware with BIER." is it applicable to all
> hardware handling BIER ? Or is it vendor specific ?

Changed text to "is designed with the intent to easily".

Of course, i do not know all the proprietary HW optimizations
that may be done to implement BIER, so i can only judge
from the efforts done on the design side: 

Primarily the goal was to have as few changes as possible betwen the
rfc8279 BIER pseudocode and the MANDATORY BIER-TE pseudocode
in this draft (the first pseudocode). That pseudocode should
be even easier to implement than the BIER variant, because 
it removes the sequential dependencies between replications: BIER
pseudocode updates a variable used across all replications,
making e.g.: (distributed) egress linecard implementations more expensive.

The optional features
like ECMP, DNC and multiple adjacencies for a single bit-position are
moderate additional complexity that should be able to attach to
a shared core forwarding/replication code.

But beyond that, the biggest argument in favor of "designed with intent to easily..."
is the fact that BIER-TE continues to use the same fixed-length
bitstring that BIER uses. This actually leads to all the complex
options to reduce the number of total bits required to represent
some part of the netork topology, shown primarily through
section 5 (controller procedures to assign bits, bit-types) and
the optional BIER-TE adjacencies that go along with that.

If we would dare to go beyond the fixed-length/flat bitstring of
BIER, then we would end up with much easier BIER-TE+?,
which is what draft-eckert-bier-cgm2-rbs actually proposes).
But that overall simplification/scalability enhancements come
at the price of more complex forwarding plane parsing of the
structured bitstring in the per-packet forwarding plane.

> -- Section 3.2.1 --
> As BIER-TE is basically centralized in a control, "such YANG/Netconf/RestConf"
> is a little hand waving. Does the BIER WG have already started work on this
> control protocol ?

Small correction: A centralized BIER-TE controller is just the
"reference model" for the BIER-TE control plane (section 2.2 point 2.2).

There is no reason to not implement at least a decentralized control plane,
such as has been done historically for RSVP-TE: every headend-LSR (BFIR)
calculating the path/trees for which it is the headend. For BIER-TE this
would be quite attractive as an RSVP-TE/P2MP replacement - removes all
the unwanted per-LSP signalling in the network. 

The text just does not discuss because it would be a lot of additional text,
so arguably not the best thing to do for a generic architecture
document. BIER (rfc8279) also only discusses the fully distributed (IGP) model,
even though there may now be interest in a centralized controller option as well.
Some thing (IGP is "reference model" for BIER).

To your question: yes, there is now draft-ietf-bier-te-yang, and
some other drafts for a bier-te control plane (with IGPs), e.g.: draft-chen-bier-te-isis

> -- Section 4.2.3 --
> What is the "entropy parameter" ? where is it defined ? (to repeat myself, I am
> not a BIER expert) if the entropy is part of the BIER header then strong
> suggestion to s/entropy parameter/value of the entropy field of the BIER
> header/.

Great catch. I now actually copied the improved correct text almost straight out of rfc8279:

| If the packet's encapsulation contains an entropy field, the entropy field SHOULD 
| be respected; two packets with the same value of the entropy field SHOULD be sent on
| the same adjacency.

(only difference is "adjacency" instead of "interface").

> -- Section 4.3 --
> Do the authors have an idea on how to share the BIFT-id address space among
> BIER (which is decentralized AFAIK) and BIER-TE (which is centralized) without
> overlapping and keeping the separation during all operations (including when
> nodes/links appear/disappear) ?

This is pretty independent of whether the control plane is centralized,
decentralized or distributed for BIER and/or BIER-TE. Maybe think about it like
co-existance of IP unicast and IP multicast. There we simply split up the IP address space.

In BIER/BIER-TE it would be most easy to split up the sub-domain address space.
For example the BIER and BIER-TE SD ranges could be configured on each BFR.

When using rfc8296 encap, typically the SD value will be encoded and/or mapped
to the bift-id. When using it with MPLS, the bift-id is actually an MPLS label,
and the IGP is used to signal to the BFR neighbors the binding between label range
and sub-domain. So far that exists for BIER, but draft-chen-bier-te-isis for
example proposes the same for BIER-TE. And we work on/need YANG models as well..

Topology changes with MPLS are just like any other label re-binding in MPLS.
When not using MPLS, but e.g.: BIER directly over ethernet, the SD
could be a fixed part of the bift-id, so there would be no dynamic re-signaling
required.

> -- Section 6 --
> While discussing about SR, did the WG think about using RFC 8986 network
> programming to achieve the same results as BIER-TE ?

There is no stateless multicast/replication functionality in SR RFCs,
and specifically RFC8986 is i think a red-herring, because we wanted solutions
working for not only IPv6, but also MPLS (like BIER). And as far as i see
it, RFC8986 is actually primarily about ingres/egres PE stuff, but not
midpoint SIDs, which something like replication would be. So RFC8986
is to me more like another layer of the solution. It comes in very handy
as part of the BIER packet payload header to support all the different
services on top of BIER(-TE) replication.

If we wanted to do something like BIER/BIER-TE with the approach of SRv6,
we would need to encapsulate a whole tree in some modified SRH header,
but with 128 bit per entry instead of 1 bit as we do in BIER/BIER-TE.
That approach was never considered to be attractive by the BIER-WG because
of what many of the early contributors learned from ca. year 2000 Small
 Group Multicast (SGM) (US Patent 7,978,718) (pretty much the same idea
with IPv4 addresses).

> Unsure whether the note about "BIER itself" brings any value in this BIER-TE document.
> Unsure what the last § has to do with segment routing.
> To be honest, this section is really light and the document would gain by
> removing it.

I am sorry that you feel that way. I really want this section to be
useful to operators, and i think it basically is, but of course it
can always be improved.

Let me try to motivate to you better:

SR is the most widely used or planned unicast forwarding technology in
service provider networks. These too are the primary networks that BIER/BIER-TE
targets (i think there are a lot more additional networks like in IoT, but
we have too little participation of those entworks in IETF yet to know
enough about the operational realities there).

 SR operators are naturally asking the question how BIER/BIER-TE
relates to SR. Given how we can not simply rename BIER to SR-Multicast, we
need to technically explain how it actually can very well fit the goal
and designs of SR networks. And given how these questions on relationship
where not answered so far for BIER either, this section also had to include
a paragraph about BIER.

Given the scope of this document (architecture), i think it is therefore
appropriate to have such a more inspirational overview/comparison than either nothing
or a deep/detailled technical review. My hope of course is that by mean of
simply putting what BIER/BIER-TE does into the SR perspective it also helps
operators coming from SR to easier understand the rest of the document and
its benefits.

> == NITS ==
> 
> Please use the all uppercase "YANG" rather than "Yang" as it is an acronym.

Done.

> -- Section 2.3 --
> s/that is forwarding plane is a simple extension/that its forwarding plane is a
> simple extension/ ?

Ack.

Thanks a lot for the review! Hope my replies are satisfactory even though of
our difference of opinion on some core point!

Cheers
    Toerless