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

[Alia Atlas <[e-mail]>]

Hi Warren,

On Wed, Jul 5, 2017 at 1:59 PM, Warren Kumari <[e-mail]> wrote:

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

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


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