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

From: Warren Kumari <[email-masked]>
Date: Wed, 05 Jul 2017 12:22:55 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-bier-architecture-07: 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 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/

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

[ After response from Alia I'm clearing my discuss. I still somewhat feel that
an Architecture document which discusses an experimental protocol / idea
doesn't need to be Experimental itself, but a: I don't feel it very strongly /
could be wrong, and b: her "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." makes me happy.  I'm copying my original
discuss comment below for hysterical raisins. ]

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

------ ORIGINAL DISCUSS TEXT ----
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.

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 5 Jul 2017 16:08:08 -0400

> do away with the SI completely and just make the BitString N bits longer

The size of the BitString is really determined by the capabilities of 
the forwarding hardware.  And the encapsulations (at least, those 
specified in draft-ietf-bier-mpls-encapsulation) support only certain 
sizes.  If your hardware supports only a BitStringLength of 256, and you 
have 257 BFERs, you can't just say, "hey let's use a longer BitString".  
Even if your hardware supports the next larger BitStringLength, 512, you 
might not want to use a BitStringLength of 512 when you only have 257 BFERs.

> and have a 3 octet BitString).

A 3-octet BitString would allow you to identify 24 BFERs (3*8), whereas 
a 1-octet SI and a 2-octet BitString allow you to identify 4096 BFERs 
(256*16).  BTW, the BitStringLengths that are envisioned are all larger 
than two octets.  I wouldn't expect to see less than 64 bits, and 256 is 
more likely.

> It was only when I got down to Section 3 that I
> different BitString length.

Sub-domains can have different BitStringLengths, the SI is relative to a 
single sub-domain.  The fact that sub-domains can have different 
BitStringLengths may be useful if you have hardware that supports 
multiple BitStringLengths, but that's really orthogonal to whether the 
SI is needed.

> http://mathworld.wolfram.com/SteinerTree.html  

I think it is probably best to remove the mention of Steiner trees and 
instead just say that the routing underlay could be some sort of 
multicast tree.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Jul 2017 16:48:39 -0400

On Wed, Jul 5, 2017 at 4:08 PM, Eric C Rosen <[email-masked]> wrote:
> The size of the BitString is really determined by the capabilities of the
> forwarding hardware.

Oh. Yeah, that is obvious (now :-)).

>  And the encapsulations (at least, those specified in
> draft-ietf-bier-mpls-encapsulation) support only certain sizes.  If your
> hardware supports only a BitStringLength of 256, and you have 257 BFERs, you
> can't just say, "hey let's use a longer BitString".  Even if your hardware
> supports the next larger BitStringLength, 512, you might not want to use a
> BitStringLength of 512 when you only have 257 BFERs.
>
> A 3-octet BitString would allow you to identify 24 BFERs (3*8), whereas a
> 1-octet SI and a 2-octet BitString allow you to identify 4096 BFERs
> (256*16).  BTW, the BitStringLengths that are envisioned are all larger than
> two octets.  I wouldn't expect to see less than 64 bits, and 256 is more
> likely.
>
> BitStringLengths may be useful if you have hardware that supports multiple
> BitStringLengths, but that's really orthogonal to whether the SI is needed.
>
> instead just say that the routing underlay could be some sort of multicast
> tree.

Awww. I really wanted a router with a big bucket of water and some
soap, but your solutiuon works too.

Thanks,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Antoni Przygienda <[email-masked]>
Date: Thu, 6 Jul 2017 02:02:11 +0000

The IGP signaling has a hook to allow things like Steiner trees in the future already today. Currently, only the absence of a “tree type” TLV is specified to mean “use normal SPF” and the presence implying “do not participate, it’s some different tree”. 

Rest of the points raised have been addressed by Eric in satisfactory fashion IMO … 

thanks 

--- tony

<[email-masked]> spake:

    

    Thanks,
    W

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 6 Jul 2017 14:07:25 -0700

> http://photos.kumari.net/Technology/Networking/i-k4vCdwv/A

Some of the authors are known as mild punsters so for the old hands it may
look like some of the acronym choices have not been innocuous ;-)

> BitString identify that BFR itself, ..." -- identifies.

ack

> nit and I can move on :-)

in fact, it is a DAG with SPF properties and BIER is free to use the DAG to
ECMP. The ECMP section should make that pretty obvious.

> Typo:  Dispostion ->  Disposition

ack