Multicast using Bit Index Explicit Replication
Note: This ballot was opened for revision 07 and is now closed.
Alia Atlas Yes
Deborah Brungard No Objection
Ben Campbell No Objection
I agree with other comments that the architecture document should describe the experiment.
Benoit Claise (was Discuss) No Objection
Next point moved from DISCUSS to COMMENT after the IESG telechat: 1. I want to come back to the experimental status. I have seen Alia's reply: 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. From the writeup, it seems that the experiment is successful already: The vendors are being quite tight lipped about current implementations. Operator feedback indicates there are at least two implementations currently, with others in the works. There are currently five vendors collaborating on the work in the IETF. However, I've not been following the specifications development and implementation to provide a definitive answer. At the minimum, the document needs to describe what the criteria are for a successful experiment. Implementations (RFC7942?)? two interop implementations? hardware implementation? "deployment experience" (to cite the charter text)? impact analysis? something else? The ideal BIER document for this explanation is this architecture doc. A reference to the charter Item 9 would be a good start. Examples: https://tools.ietf.org/html/rfc7360#section-1.3 https://tools.ietf.org/html/rfc7499#section-2 - Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain to which it belongs. A BFR's BFR-Prefix MUST be an IP address (either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the BFR-prefix be a loopback address of the BFR. Just one observation. Was thinking, so it's like an (OSPF) routerId, except that it's called a prefix. Then I understood, reading further. It's not called a routerId because this address/prefix must be routable - Was wondering. Is this mechanism only for multicast packets? What about anycast/unicast? Some multicast packets would take BIER encap, while others packets would take a different encap From a troubleshooting point of view, does it make sense (is it even allowed) to send non multicast traffic over BIER.
Alissa Cooper No Objection
Comment (2017-07-05 for -07)
I'm a bit confused about the experimental status of this document as well, given that the other WG drafts that define protocol extensions to support BIER seem to be headed for the standards track. If what is documented here really is the only experimental part, this seems like the place to document the experiment.
Spencer Dawkins No Objection
Just asking for my own understanding ... In this text, If, at some time, the routing underlay is not providing a loop free path between BFIR-A and BFER-B, then BIER encapsulated packets may loop while traveling from BFIR-A to BFER-B. However, such loops will never result in delivery of duplicate packets to BFER-B. I'm assuming that these loops could result in out of order delivery of packets to BFER-B? No document change requested, of course. And either answer is fine.
Suresh Krishnan No Objection
Warren Kumari (was Discuss) No Objection
Comment (2017-07-05 for -07)
[ 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.
Mirja Kühlewind No Objection
Update: While it is now clearer why this doc is not informational, I agree with the gen-art review (Thanks Dan!) that is could be made even clearer what the experiment is/why this is experimental and not PS. Old ballot text: I also initially expected that this document should be informational because it specifies an architecture, however, while reading I realized that is rather specifies abstract mechanisms and a data model. So it's basically an abstract protocol spec without defining the on the wire format. Maybe it would be helpful to describe the content of this document this way, rather than speaking of an architecture. However, I guess the word architecture is rather board though. Thanks for a well-written doc; especially the ECMP part is very clear!
Terry Manderson No Objection
Alexey Melnikov No Objection
Kathleen Moriarty No Objection
Alvaro Retana No Objection
Adam Roach No Objection
Not wishing to re-litigate any of the previous discussions (for which I was not available), I have reviewed only the deltas between -07 and -08. I have no objection to the changed and new material.