[Bier] Benoit Claise's Discuss on draft-ietf-bier-architecture-07: (with DISCUSS and COMMENT)
Benoit Claise <bclaise@cisco.com> Thu, 06 July 2017 14:50 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 F0F13131648; Thu, 6 Jul 2017 07:50:05 -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: <149935260597.2282.13769939557972164314.idtracker@ietfa.amsl.com>
Date: Thu, 06 Jul 2017 07:50:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/CZKtfuaw3YH5xPt8Z9g8uZBR9PQ>
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 14:50:12 -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: https://datatracker.ietf.org/doc/draft-ietf-bier-architecture/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. 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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? 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 ongoing. 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).
- [Bier] Benoit Claise's Discuss on draft-ietf-bier… Benoit Claise