Dear Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - draft-ietf-bier-architecture-07 Link to Document - https://tools.ietf.org/html/draft-ietf-bier-architecture-07 Summary: The document reviewed outlines the BIER (Bit Indexed Explicit Replication) architecture for multicast packet delivery. The document is one of the earlier documents written around BIER and currently under development / review within the bier working group. The document is set as an architectural level document which defers some discussion of implementation and operational topics to companion (later) documents. That said, the document does walk the reader through a number of examples which addresses some operational use cases. Very well written and explained. Removing state form the network is beneficial and I see BIER as a way to help do this while still providing a robust way to deliver Multicast (M/C) based services. General Comments and Feedback First, there were no textual changes recommended as part of this review. The document seems to be well written and had undergone previous review/updates. Given the nature of this document, there are limited operational specific points made as part of this review however three points are noted for follow-up with the actors. (1). Security Considerations It was not 100% clear to the reviewer (me) if the use case of how the BIER architecture (or guidance for future implementation) may avoid certain DoS like activity from illegitimate neighbors (BFR-NBRs). I may have missed specific text which addresses the point made herein (if so, please disregard my first point and please make reference where it is addressed). The concern is if a packet is introduced into the system by a host (compromised perhaps) which fabricates packets (may or may not have valid payload inside the BIER encapsulation) that attempts to starve resources in the system. One way of doing this (which may require control plane access - maybe) would be to set/create packets which forces additional replication at BFRs (i.e. set a single - or all bits - for all SIs). This would then create the maximum amount of replication within the system. Perhaps this use case is addressed as noted. I was no able to find specific operations/functions which scrutinized incoming packets and/or guard for bad NBRs. Could this be an issue from the authors standpoint? In more traditional networks, there are methods operators use to ensure that illegitimate traffic is not introduced into the system. I wanted to make sure there was thoughts on how to do this with BIER. (2). SPF assumed. I agree most places where the BIER architecture would likely live (say in Enterprises and SP networks) the network would operate a standard IGP. However, in some use cases, like modern DCs, some are designing fabrics which don’t use a traditional IGP. These networks use all BGP (eBGP) with full sets of neighbor relationships. This helps reduce the amount of running protocols within the underlay, but may (or may not) cause issues with BIER in relation distribution of system information. Do the authors consider this use case one that can be address with BIER as it’s currently outlined, or would additional considerations be needed? I reviewed the “draft-ietf-bier-use-cases” document and did not see text that specifically help or hinder the operational mode I described above. (3) Broadcast Video Operation. (more of a question then a point of note) I did noticed in the use case document (as noted above in point 2), that considers more traditional broadcast video networks was described. So my question is, would an operational model which required two simultaneous M/C flows from separate sources (normally two packagers/encryptors etc) be supported by the BIER architecture as described? My best estimate would be that the operator would use two sub-domains that would allow each BFER to potentially get two of each packet (which are sourced by two different injection points / BIFRs). This mode of operation is common in some places to allow the M/C broadcast feed to be “pinned” to the egress router/device to allow for fast switchover in case of network failure (where normal network level detection and re-routing is not sufficient). regards, Victor K