Re: [Bier] BIER rechartering

Xiejingrong <xiejingrong@huawei.com> Thu, 25 January 2018 02:07 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7AB12DA69 for <bier@ietfa.amsl.com>; Wed, 24 Jan 2018 18:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level:
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 w_CBBZS7UPru for <bier@ietfa.amsl.com>; Wed, 24 Jan 2018 18:07:08 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9751C12D7EF for <bier@ietf.org>; Wed, 24 Jan 2018 18:07:07 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 39D8A7B4B3DF4 for <bier@ietf.org>; Thu, 25 Jan 2018 02:07:04 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 02:07:04 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 10:06:53 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: Alia Atlas <akatlas@gmail.com>, "bier@ietf.org" <bier@ietf.org>
Thread-Topic: [Bier] BIER rechartering
Thread-Index: AQHTlJ+mrD/lkTaw3k6Cz2IgZ3nMtKODzsfw
Date: Thu, 25 Jan 2018 02:06:52 +0000
Message-ID: <16253F7987E4F346823E305D08F9115A99A14ABB@nkgeml514-mbx.china.huawei.com>
References: <CAG4d1rdCysU+qnb=9U9iaZ+UefudWYDmz=mNPSfhDPuWNQQHVw@mail.gmail.com>
In-Reply-To: <CAG4d1rdCysU+qnb=9U9iaZ+UefudWYDmz=mNPSfhDPuWNQQHVw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.217.214]
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99A14ABBnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/efDvJVwhvLIeufab1WElCa6hS7M>
Subject: Re: [Bier] BIER rechartering
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.22
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: <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, 25 Jan 2018 02:07:10 -0000

Alia, Chars :

Yesterday I went to wrong place. And today I raise it here again.

What I am most concerned about is,  weather it is acceptable or not, of related solutions involving tree-building protocols ?

I think it is necessary to be clarified explicitly, in this re-charter.

Detail comments in-line.

Regards.
XieJingrong


From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, January 24, 2018 7:12 AM
To: bier@ietf.org
Subject: [Bier] BIER rechartering

As discussed, I have been working with Tony and Greg on the planned rechartering for the
BIER WG.

You can find this version at:  https://datatracker.ietf.org/doc/charter-ietf-bier/.

Please send comments.  I want this to make the February 8 IESG telechat.

================================
The BIER (Bit Index Explicit Replication) Working Group has defined
an architecture [RFC 8279] for  multicast forwarding that uses an
encapsulation [RFC 8296] that can be used on MPLS or Ethernet transport.
The BIER-WG is now chartered to produce Standards Track RFCs and to
update or do a Status Change for those RFCs previously published as
Experimental (RFC 8279, RFC 8296, etc.).

First and primarily, the BIER-WG will complete its work on:
  1) 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.
     Operation of BIER in non-congruent topologies, i.e.
     topologies where not all routers are BIER capable can
     also be addressed. In addition to tunneling solutions, other
     approaches to make BIER deployable in such environments
     can be worked on. Each such mechanism must include an
     applicability statement to differentiate its necessity from
     other proposed mechanisms.
[XJR1]: I think P2MP based BIER can naturally work as an alternative partially deploy solution also. But unfortunately it involve tree-building protocol. Acceptable or not ?
  2) 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.
[XJR2]: MVPN using P2MP-based BIER, is also one way of apply BIER in MVPN. Acceptable or not ?

  3) Use Case: The WG may produce one use-case document that clearly
     articulates the potential benefits of BIER for different use-cases.
  4) 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.
[XJR3]: P2MP-based BIER can use exist P2MP PMTU. It will be helpful. Acceptable or not ?
  5) Management models: The WG may work on YANG models and, if needed, MIB
     modules to support common manageability.

  6) 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 advertisements 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 Standards Track, in cooperation with the LSR WG.
[XJR4]: How about BGP extensions as BIER underlay ? and how about RSVP-TE/MLDP extensions as BIER underlay ?

The BIER-WG is additionally chartered to start Standards Track work on:
  7) BIER in IPv6 :  A mechanism to use BIER natively in IPv6 may be
     standardized if coordinated with the 6MAN WG and with understood
     applicability.  Such functionality may focus on assuming software or
     slow-path support first.
  8) BIER Traffic Engineering:  An architecture for BIER-TE is defined
     in draft-ietf-bier-te-arch; associated fundamental technology is included.
[XJR5] Thanks for acceptance of this topic in the re-charter. I think it is a necessary puzzle, and P2MP-based BIER can also provide an alternative TE through transport mechanism. Acceptable or not ?
  9) Extensions to support BIER in multi-area IGP Deployments

The BIER-WG is chartered to investigate the following topics. The adoption
of any Standards Track drafts will require a milestone approved by the
responsible Area Director.
  10) Novel uses of the BIER bitmap: There are a variety of proposals for
      additional algorithms and other uses of the BIER bitmap and
      encapsulation beyond BIER and BIER-TE.
  11) BIER between Autonomous Domains:   With understood applicability,
      these scenarios may be investigated.
  12) Use of BIER in Controller-based Architectures:  How might controllers
      be used to provide calculated BIRTs and/or BIFTs tables to BFRs?
  13) Applicability of BIER to Applications: The WG may advise on the
      applicability of BIER to various applications.

The BIER-WG 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-WG will coordinate with MPLS-WG
on the associated MPLS-based OAM mechanisms. BIER-WG will coordinate with
LSR-WG on extensions to flood BIER-related information. BIER-WG will
advise BABEL-WG on Babel extensions to support BIER. BIER-WG will
coordinate with BESS-WG and IDR-WG on the applicability of existing
BGP-based mechanisms for providing multicast group membership information.
BIER-WG will coordinate with PIM-WG on the applicability of and extensions
to PIM, IGMP, and MLD to support BIER operations and transition; BIER-WG
will work directly on the applicability statements, as needed.
=================================

Thanks,
Alia