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

[Éric Vyncke via Datatracker <[e-mail]>]

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

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.

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

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

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

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

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

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

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.

== NITS ==

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

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