Re: [Bier] proposed BIER charter
Antoni Przygienda <antoni.przygienda@ericsson.com> Sat, 14 February 2015 01:38 UTC
Return-Path: <antoni.przygienda@ericsson.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9A1A1A99; Fri, 13 Feb 2015 17:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3iSwhpo_wgm; Fri, 13 Feb 2015 17:38:31 -0800 (PST)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D581A1A86; Fri, 13 Feb 2015 17:38:30 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-57-54de53545654
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 96.B6.03307.4535ED45; Fri, 13 Feb 2015 20:41:09 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 20:38:28 -0500
From: Antoni Przygienda <antoni.przygienda@ericsson.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>, Alia Atlas <akatlas@gmail.com>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: [Bier] proposed BIER charter
Thread-Index: AQHQRjuQYyjkJ/or3U2D1i8/o65ffZztW3uAgAIBvMA=
Date: Sat, 14 Feb 2015 01:38:27 +0000
Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1824CFA5@eusaamb103.ericsson.se>
References: <CAG4d1reTLuz5AUVrsiSjh4JTbryD=54jf3OX9kx_ceAbHFfm7A@mail.gmail.com> <54DCAE4F.8050903@cisco.com>
In-Reply-To: <54DCAE4F.8050903@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: multipart/alternative; boundary="_000_2E4BB27CAB87BF43B4207C0E55860F1824CFA5eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPiG5o8L0Qg7+HmSx+9Nxgtvj08BKz xd+fWxktls7Yw2Qx489EZotzT+cwOrB5TPm9kdVj56y77B5Llvxk8lixeSVjAEsUl01Kak5m WWqRvl0CV0bTTLeCW1OZK3791m5gbH7M1MXIwSEhYCKx96xIFyMnkCkmceHeerYuRi4OIYEj jBJvJuxjAUkICSxnlLh6RxzEZhOwkLj87SkziC0iUCDx5+QfdhCbWSBXYt6pa2C2sICmRO+l PWwQNVoSG++vZ4KwrSROHD8NVsMioCrxe187O8gNvALeEhtv1kOsypd41ruUEcTmBBqz68hr VhCbEei276fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStK7OufDnUa0Mx/N8Be4RUQ lDg58wnLBEbRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqW m25ksIkRGI3HJNh0dzDueWl5iFGAg1GJh7fA4G6IEGtiWXFl7iFGaQ4WJXHeRQ8OhggJpCeW pGanphakFsUXleakFh9iZOLglGpg5CjmrJknuSbk1VFmbcsX3DbbJla9q9Bes5pDZsvSP8YF KwNuKsaePvpzq+nsjVcPRrOGT2CW8tCa3u77YFOUidiCD7rPBKSONBlPm7fu/M9/J/y3C0pd TWlsFfTPOiBTuTm9fznTXbegvyLBVytZ9qf3/69y5Mw1v7K2qPiqxWEzJk0pBa1UJZbijERD Leai4kQA8/hHgqcCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/bier/GznwQjLnGUrhU0dP3PUF2YnHjqI>
Cc: Adrian Farrel <adrian@olddog.co.uk>, "iesg@ietf.org" <iesg@ietf.org>, Alvaro Retana <aretana@cisco.com>
Subject: Re: [Bier] proposed BIER charter
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Sat, 14 Feb 2015 01:38:39 -0000
<hat type="wg-chair"> Stewart, I concur with Alia that a new data plane concept like this one is a thing seldom introduced and frail with surprising risks (IPv6 = ~15 years from idea to reasonable scale of deployment ? MPLS = ~ 10 years ? ;-) IMO, it is far less risky to give this thing a vibrant WG where people know that they have to push for serious implementations (and prove them viable before standards track with resulting huge investment in silicon by many companies will be taken) rather than rush it without adequate experience and end up with a massive egg on our collective faces. The path to standards is fair (FYI, it was initially much stricter) and clearly spelled out me thinks. I'm waiting for people getting excited by the fame attached to a first Linux kernel implementation going @ 1GB bitrate (I'm too smart to talk about packet size or bitstring lengths here ;-) Pen-ultimately, I would like to see precise use-cases for the low link-speeds and edge to consider this further. A 'may be useful' does not justify major surgery on charter IMO. Ultimately, early vendor support & strong customer response in the market place is the best pressure point for IETF to move such work into Standards Track lest they end up looking like Johnie-come-laties. We ain't there yet. </hat> --- tony From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, February 12, 2015 5:45 AM To: Alia Atlas; bier@ietf.org Cc: Adrian Farrel; iesg@ietf.org; Alvaro Retana Subject: Re: [Bier] proposed BIER charter Alia I think that you are crossing far too many bridges before you get to them in terms of you expectation of where BIER will be deployed and how it will be implemented. The charter should not include such specific assumptions, particularly given the fast moving changes that are happening in our industry especially in the area of packet forwarding design. I have not seen such assumptions in other charters and I don't think that they have a place in this one. In terms of choice of document stream (experimental vs PS), that is a decision that can be taken at the time of publication when more information will be available in terms of potential market take-up, expected/actual deployment scenarios, breadth of implementation and implementation experience. Whilst this technology may be deployed in the Internet core, it my also be deployed at the edge where a much lower threshold is applicable. I fear that by introducing these caveats the IETF is entrenching the perception that it slows technology down rather than embracing and encouraging innovation. I would therefore suggest removing the text on implementation styles and document stream constraints. - Stewart On 11/02/2015 20:44, Alia Atlas wrote: I have been working on getting a charter together for BIER with the intent of pushing for it to be chartered before the Dallas IETF. This has not yet gone through IESG review and it may have some aspects updated. Please send comments here. The charter can be found at http://datatracker.ietf.org/doc/charter-ietf-bier/ and is included below as well. WG Chairs: Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>> In conventional IP multicast forwarding, the packets of a given multicast "flow" are forwarded along a tree that has been constructed for the specific purpose of carrying that flow. This requires transit nodes to maintain state on a per-flow basis, and requires the transit nodes to participate in multicast-specific tree building protocols. The flow to which a packet belongs is determined by its IP source and destination address fields. BIER (Bit Index Explicit Replication) is an alternative method of multicast forwarding. It does not require any multicast-specific trees, and hence does not require any multicast-specific tree building protocols. Within a given "BIER domain", an ingress node encapsulates a multicast data packet in a "BIER header". The BIER header identifies the packet's egress nodes in that domain. Each possible egress node is represented by a a single bit within a bitstring; to send a packet to a particular set of egress nodes, the ingress node sets the bits for each of those egress nodes, and clears the other bits in the bistring. Each packet can then be forwarded along the unicast shortest path tree from the ingress node to the egress nodes. Thus there are no per-flow forwarding entries. Due to the particular sensitivity of adding new significant functionality into the data-plane at high link speeds, the BIER work will progress as Experimental. As described in item (9) below, the work may become Standards Track once there is sufficient experience with the benefits and downsides of the technology. 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. It will include the normative algorithm for how BIER packet forwarding is done. It will specify the information that is required by a BIER header to support BIER forwarding. 2) BIER encapsulation: The working group should assume that the technology will need to be embedded in the data plane and operate at the highest packet line speeds. The WG will publish a document defining an MPLS-based encapsulation based upon draft-wijnands-mpls-bier-encapsulation-02. Due to the critical need to have a high-quality and stable RFC for a new data-plane encapsulation, the MPLS-based encapsulation draft shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. As a secondary focus, the WG may also work on one non-MPLS data-plane encapsulation. This draft also shall wait after WGLC and not progress to IETF Last Call until there are two independent interoperable implementations. This draft must focus on and include the following details: a) What is the applicability of the encapsulation and for which use-cases is this encapsulation required? b) Does this proposed encapsulation imply any changes to the MPLS-based encapsulation? c) What design choices have been made for the encapsulation type and the included fields. d) The proposed encapsulation with considerations given to at least OAM, Class of Service, security, fragmentation, TTL. 3) Transition Mechanisms: The WG will describe how BIER can be partially deployed and still provide useful functionality. A minimum of the necessary mechanisms to support incremental deployment and/or managing different BIER mask-length compatibility may be defined. Each such mechanism must include an applicability statement to differentiate its necessity from other proposed mechanisms. 4) Applicability Statements: The WG will work on a document describing how BIER can be applied to multicast L3VPN and to EVPN. This draft will describe what mechanism is used to communicate the group membership between the ingress router and the egress routers, what scalability considerations may arise, and any deployment considerations. 5) Use Case: The WG may produce one use-case document that clearly articulates the potential benefits of BIER for different use-cases. This would be based upon draft-kumar-bier-use-cases-01. 6) OAM: The WG will describe how OAM will work in a BIER domain and what simplifications BIER offers for managing the multicast traffic. A strong preference will be given to extensions to existing protocols. 7) Management models: The WG may work on YANG models and, if needed, MIB modules to support common manageability. 8) IGP extensions. When a BIER domain falls within a "link state IGP"" network, the information needed to set up the BIER forwarding tables (e.g., the mapping between a given bit position and a given egress router) may be carried in the link state advertisements of the IGP. The link state advertisments may also carry other information related to forwarding (e.g., the IGP may support multiple topologies, in which case it may be necessary to advertise which topologies are to be used for BIER forwarding). Any necessary extensions to the IGP will be specified by the WG, in cooperation with the ISIS and OSPF WGs. 9) Deployment Experience: Once there is deployment experience, the WG will produce a document describing the benefits, problems, and trade-offs for using BIER instead of traditional multicast forwarding mechanisms. Ideally, this should also contain an analysis of the impact and benefit of the new BIER data-plane to the overall Internet architecture. This document is intended to be used to evaluate whether to recharter BIER to produce Standards Track RFCs. The BIER working group will coordinate with several different working groups and must include the relevant other working groups during working group last call on the relevant drafts. BIER will coordinate with MPLS on the MPLS-based encapsulation and associated MPLS-based OAM mechanisms. BIER will coordinate with ISIS and OSPF on extensions to flood BIER-related information. BIER will coordinate with BESS and IDR on the applicability of existing BGP-based mechanisms for providing multicast group membership information. Regards, Alia _______________________________________________ BIER mailing list BIER@ietf.org<mailto:BIER@ietf.org> https://www.ietf.org/mailman/listinfo/bier -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
- [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Xuxiaohu
- Re: [Bier] proposed BIER charter Antoni Przygienda
- Re: [Bier] proposed BIER charter Xuxiaohu
- Re: [Bier] proposed BIER charter Stewart Bryant
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter arkadiy.gulko
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Xuxiaohu
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Xuxiaohu
- Re: [Bier] proposed BIER charter Xuxiaohu
- Re: [Bier] proposed BIER charter Antoni Przygienda
- Re: [Bier] proposed BIER charter IJsbrand Wijnands
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Dino Farinacci
- Re: [Bier] proposed BIER charter IJsbrand Wijnands
- Re: [Bier] proposed BIER charter Brian Haberman
- Re: [Bier] proposed BIER charter Rajiv Asati (rajiva)
- Re: [Bier] proposed BIER charter Brian Haberman
- Re: [Bier] proposed BIER charter Joel M. Halpern
- Re: [Bier] proposed BIER charter Stewart Bryant
- Re: [Bier] proposed BIER charter Stewart Bryant
- [Bier] proposed BIER charter Uwe.Joorde
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Brian Haberman
- Re: [Bier] proposed BIER charter Alia Atlas
- Re: [Bier] proposed BIER charter Luay Jalil