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