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

Benoit Claise <bclaise@cisco.com> Thu, 06 July 2017 13:13 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: bier@ietf.org
Delivered-To: bier@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDEC131752; Thu, 6 Jul 2017 06:13:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benoit Claise <bclaise@cisco.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-bier-architecture@ietf.org, Greg Shepherd <gjshep@gmail.com>, bier-chairs@ietf.org, gjshep@gmail.com, bier@ietf.org, victor@jvknet.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149934683636.2270.10065032311656213669.idtracker@ietfa.amsl.com>
Date: Thu, 06 Jul 2017 06:13:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Z-hZbqZefyo2-O43u8affoOyxgI>
Subject: [Bier] Benoit Claise's Discuss on draft-ietf-bier-architecture-07: (with DISCUSS and COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 13:13:56 -0000

Benoit Claise 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:


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.


2. operations and management section
I'm sure there are such considerations:
    - configuration
    - sub-domain management
    - BFR-id management
    - adding new BFIR/BFER device to the domain
    - logging
    - troubleshooting
    - OAM
    - etc.

There are also two other management documents that should be referenced:
chartered item 6 and 7. There are some management sentences, from time to time,
in the doc. Ex: avoiding a second copy is an important from an operational
point of view

   It is generally advantageous to assign the BFR-ids of a given sub-
   domain so that as many BFERs as possible can be represented in a
   single bit string.


   In order to minimize the number of copies that must be made of a
   given multicast packet, it is RECOMMENDED that the BFR-ids be
   assigned "densely" (see Section 2) from the numbering space...

    Btw, I guess you meant: assigned densely per subdomain, right?

What this "operations and management section" should contain is the points that
operators, who will deploy this technology, have to pay attention to. An
architecture document is typically the first document people will read. RFC
5706 appendix A provide typical questions from an OPS point of view. I
understand that this is an experiment and you might not have all the answers at
this point in time.


-   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? End of section 4 you have an example about MVPN over
ingress/egress PEs. 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.

Victor Kuarsing performed the OPS-DIR review, copied below. Discussion is

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

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