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

From: Warren Kumari <[email-masked]>
Date: Wed, 05 Jul 2017 10:59:26 -0700

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Jul 2017 14:10:53 -0400

Hi Warren,

> https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/

The document is defining a novel look-up and forwarding mechanism to use for
multicast that replaces longest-prefix-match used for unicast.  This is
where it is
defined.  That needs to experimental or standards track.

In the BIER Charter, work item 9 describes a document based on deployment
experience that can justify moving the BIER work from Experimental to
Standards
Track.  When I chartered the WG, it wasn't clear whether it was merely a
good idea
or a good idea with enough motivations towards deployment that it is worth
complicating
the architecture at the narrow point of the IP hourglass.

If the IESG wants to discuss whether it makes sense to recharter in the
absence of
deployment experience such that BIER will need to be considered for the
Internet
architecture moving forwards, I am certainly willing to have that
discussion.

I did discuss with the BIER WG that it is possible to do a status update to
move a
document from Experimental to Proposed Standard without needing to update
the RFC.
That is what I would anticipate happening with this document and others (in
my queue
and soon to be in ours) if and when BIER is rechartered to do Standards
Track work.

Regards,
Alia