* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Bier Status Pages

Bit Indexed Explicit Replication (Active WG)
Rtg Area: Alvaro Retana, Alia Atlas, Deborah Brungard | 2015-Mar-24 —  
Chairs
 
 


2016-06-21 charter

Bit Indexed Explicit Replication (bier)
---------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Greg Shepherd <gjshep@gmail.com>
     Tony Przygienda <prz@juniper.net>

 Routing Area Directors:
     Alia Atlas <akatlas@gmail.com>
     Deborah Brungard <db3546@att.com>
     Alvaro Retana <aretana@cisco.com>

 Routing Area Advisor:
     Alia Atlas <akatlas@gmail.com>

 Mailing Lists:
     General Discussion: bier@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/bier
     Archive:            https://mailarchive.ietf.org/arch/browse/bier/

Description of Working Group:

  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.  The scope of the experiment will be
  documented in the output of the Working Group.  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 discuss the
     security properties of BIER.   It will include the normative
     algorithm for how BIER packet forwarding is done.  It will specify
     the information that is required to be in a BIER header so that a
     router can 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 very high 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 describe 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.  The WG
     will work on additional applicability statements, as needed,
     describing how BIER can be applied; for example, this may be needed
     to clarify how a non-MPLS data-plane encapsulation would be used.

     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) Manageability and 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 as Experimental, in cooperation with the
     ISIS and OSPF WGs.

     9) Deployment Evaluation: Once there is deployment experience, the
     WG will produce an Informational RFC 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.  BIER will coordinate
  with PIM on the applicability of and extensions to PIM, IGMP, and MLD
  to support BIER; BIER will work directly on the applicability
  statements, as needed.

Goals and Milestones:
  Mar 2015 - WG Call for Adoption of draft related to BIER problem statement
  Mar 2015 - WG Call for Adoption of draft related to BIER MPLS encapsulation
  Mar 2015 - WG Call for Adoption of draft related to OSPF BIER extensions
  Mar 2015 - WG Call for Adoption of draft related to BIER MVPNs
  Mar 2015 - WG Call for Adoption of draft related to ISIS BIER ranges
  Mar 2015 - WG Call for Adoption of draft related to BIER use cases
  Mar 2015 - WG Call for Adoption of draft related to BIER OAM
  Jul 2015 - WG Call for Adoption of draft related to BIER Transition Mechanisms
  Jul 2015 - WG Call for Adoption of draft related to BIER YANG Model / MIB
  Aug 2015 - WG Last Call on draft related to BIER problem statement
  Aug 2015 - WG Last Call on draft related to OSPF BIER extensions
  Aug 2015 - WG Last Call on draft related to ISIS BIER ranges
  Dec 2024 - WG Call for Adoption of draft related to BIER deployment experience
  Dec 2024 - WG Last Call on draft related to BIER architecture
  Dec 2024 - WG Last Call on draft related to BIER MPLS encapsulation
  Dec 2024 - WG Last Call on draft related to BIER MVPNs
  Dec 2024 - WG Last Call on draft related to BIER use cases
  Dec 2024 - WG Last Call on draft related to BIER OAM
  Dec 2024 - WG Last Call on draft related to BIER Transition Mechanisms
  Dec 2024 - WG Last Call on draft related to BIER YANG Model / MIB
  Dec 2024 - WG Last Call on draft related to BIER deployment experience


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/bier/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -