[Bier] Warren Kumari's Discuss on draft-ietf-bier-architecture-07: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-bier-architecture-07: Discuss

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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I agree with Ben, but feel more strongly than him - why is this Experimental?
Where is the experiment / how do you determine if it is successful? The
shepherd writeup says: "(1) Experimental, as per charter. The document title
page header indicates experimental. ", but this doesn't really answer the
question; the charter says: "BIER is initially chartered to do experimental
work on this new multicast forwarding mechanism as follows:

1) BIER architecture: The WG will publish an architecture, based
upon draft-wijnands-bier-architecture-04...."

I really think that this document should be Informational or PS, or something.
I can understand the *work* to be experimental in nature, but the document
*itself* seems like it shouldn't be - it doesn't (really) explain how to
implement.

I'm making this a DISCUSS, but am more than happy to clear if the chairs / AD
says that the've considered this and Experimental really is best.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Notes:
Section 1:
"If the packet also needs to be sent to a BFER whose BFR-id is 257, the BFIR
would have to create a second copy of the packet, and the BIER encapsulation
would specify an SI of 1, and a BitString with bit 1 set and all the other bits
clear." - while reading this it seemed to me that it would be much simpler to
do away with the SI completely and just make the BitString N bits longer
(instead of having e.g a one octet SI and 2 octet BitString, concatenate this
and have a 3 octet BitString). It was only when I got down to Section 3 that I
discovered that this is (kinda) discussed, and that each SI can have a
different BitString length. I'd suggest adding a refernce (like: "and a
BitString with bit 1 set and all the other bits clear (see Section 3 for more
details)."

Section 4.1.  The Routing Underlay:
"Alternatively, one could deploy a routing underlay that creates a
multicast-specific tree of some sort, perhaps a Steiner tree." A reference for
Steiner trees would be nice -- best I could find was probably the WA page at:
Weisstein, Eric W. "Steiner Tree." From MathWorld--A Wolfram Web Resource.
http://mathworld.wolfram.com/SteinerTree.html Please note: I'd pay good money
for a router doing Steiner optimizations using the soap and surface tension
trick.

Nits and notes:
1: " A router that supports BIER is known as a "Bit-Forwarding Router" (BFR)."
-- this makes me sad; the BFR acronym was already in use, and had interesting
history behind it (Big er... Fast Router) -
http://photos.kumari.net/Technology/Networking/i-k4vCdwv/A

2: "MVPN signaling also has several components that depend on the
   type of "tunneling technology" used to carry multicast data though
   the network." -- though the network what?! I suspect you meant "through" :-)
3: Section 6.1.  Overview
"If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and
BitString identify that BFR itself, ..." -- identifies.

O: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it
of course decapsulates..." P: "When BIER on a BFER is to pass a packet to the
multicast flow overlay, it, of course decapsulates" C: Missing a comma. I
suspect: "When BIER on a BFER is to pass a packet to the multicast flow
overlay, it decapsulates..." would be even better.

Section 6.9.  When Some Nodes do not Support BIER
"In this section, we assume that the routing underlay is an SPF-based IGP that
computes a shortest path tree from each node to all other nodes in the domain."
C: I *think* that this should actually be "the shortest path", but I'm not
sure; everything talks about e.g Dijkstra's algorithm finding the shortest
path, but what if there are multiple equal cost paths? But, this is a singular
tree, but may not be unique, so any SP tree will... erk... Good this this is a
nit and I can move on :-)

Section 6.10.3.  Transitioning from One BitStringLength to Another
Typo:  Dispostion ->  Disposition