Subject: Re: [Bier] Fwd: New Version Notification for draft-shepherd-bier-standards-track-00.txt

From: Xiejingrong <[email-masked]>
Date: Wed, 24 Jan 2018 12:04:44 +0000

HI, Chairs Greg, Co-Author Andrew, AD Alia, everyone:

After three years of hard work, the working group has released two RFCs, Architecture(RFC8279) and Encapsulation(RFC8296), which deserve great congratulations.
At the same time, I also feel that we still lack APPs / Solutions of using BIER to solve customer multicast service requirements.
Should we first take a look at the various Scenario / usecase / solution ?  and remove the idealism of kill tree-building protocols ?
As <draft-ietf-bier-use-cases> states, protocol simplification is only some customer's choice in some Usecase.
As various documents states, the main paradox of traditional multicast lies in the hard trade-off, between states caused by the per-flow per-tree, and flooding caused by many-flows aggregated in one-tree.
It seems not to be the fault of the tree-building protocol.

This draft is a justification before Re-charter, and about the descriptions of the tree-building protocol, I would like to raise some discussion.

1.  Introduction

   BIER [RFC8279](Bit Index Explicit Replication) is an alternative      //
   method of multicast forwarding.  It does not require any multicast-  //XJR1
   specific trees, and hence does not require any multicast-specific
   tree building protocols.  Due to the particular sensitivity of adding
   new significant functionality into the data-plane, the BIER work
   began progress as Experimental.  The current status of the experiment //
   is documented in this draft and is intended to provide justification
   for re-charting the BIER Working Group (WG) as Standards Track and to
   move all published documents of the BIER WG to Standards Track.  This //
   document will detail the benefits, problems, and trade-offs for using
   BIER instead of traditional multicast forwarding mechanisms, as
   required by the BIER WG Charter charter-ietf-bier-01

   [XJR1]: Yes, BIER is not a tree-building multicast protocol, it does not require tree either.

2.  IP Multicast Challenges

   Current IP Multicast solutions require a tree-building control plane //
   to build and maintain end-to-end tree state per flow, impacting
   router state capacity and network convergence times.  Multi-point    //XJR2
   tree building protocols are often considered complex to deploy and
   debug and may include mechanics from legacy use-cases and/or
   assumptions which no longer apply to the current use-cases.  When   //XJR3
   multicast services are transiting a provider network through an
   overlay, the core network has a choice to either aggregate customer
   state into a minimum set of core states resulting in flooding traffic
   to unwanted network end-points, or to map per-customer, per-flow tree
   state directly into the provider core state amplifying the network-
   wide state problem.  Though the value proposition of network        //
   replication is high, the cost of deploying IP Multicast is often
   considered too high to justify deployment.

   [XJR2]: why considered tree-building protocols complex/legacy/no-longer apply to current ? that is to say current MVPN are useless ? they not only work but also widely deployed!  aren't they ?
   [XJR3]: Agree, per-flow tree is the key. how about Aggregate multi-flow but no per-flow tree ?

3.  Benefits of BIER

   BIER is a radical simplification of IP Multicast.  BIER has no tree-   //XJR4
   building protocol.  BIER has no end-to-end tree/flow state.  BIER has
   no RPF requirements.  BIER packets follow the same path to a
   destination as a unicast packet would take to the same destination.
   BIER provides deterministic convergence times regardless of how many
   (S,G)s are being transported through the BIER network.  BIER can be
   deployed in SDN-driven deployment models, that minimize protocols
   required in a network as well by eliminating multicast protocols and
   relying on IGP infrastructure or direct SDN programmability.

   [XJR4] BIER has no tree-building protocol, I think it is not a sure benefits, but a feature/technology/philosophy. Real benefits is how we get a better solution to specific usecase.

Thanks.
XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Friday, December 22, 2017 4:56 AM
To: [email-masked]
Subject: [Bier] Fwd: New Version Notification for draft-shepherd-bier-standards-track-00.txt

*,

Here's our first swing at the Standard Track justification draft.

Cheers,
Greg

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Dec 21, 2017 at 12:55 PM
Subject: New Version Notification for draft-shepherd-bier-standards-track-00.txt
To: Greg Shepherd <[email-masked]<mailto:[email-masked]>>, Andrew Dolganow <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-shepherd-bier-standards-track-00.txt
has been successfully submitted by Greg Shepherd and posted to the
IETF repository.

Name:           draft-shepherd-bier-standards-track
Revision:       00
Title:          Justification for BIER on Standards Track
Document date:  2017-12-20
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-shepherd-bier-standards-track-00.txt
Status:         https://datatracker.ietf.org/doc/draft-shepherd-bier-standards-track/
Htmlized:       https://tools.ietf.org/html/draft-shepherd-bier-standards-track-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-shepherd-bier-standards-track-00

Abstract:
   This document is intended to provide justification for re-chartering
   the BIER Working Group as Standards Track, and to move all BIER WG
   previously published documents to Standards Track.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 24 Jan 2018 08:50:22 -0800

A few comments inline:

On Wed, Jan 24, 2018 at 4:04 AM, Xiejingrong <[email-masked]> wrote:

> After three years of hard work, the working group has released two RFCs,
> Architecture(RFC8279) and Encapsulation(RFC8296), which deserve great
> congratulations.
>
> At the same time, I also feel that we still lack APPs / Solutions of using
> BIER to solve customer multicast service requirements.
>
> Should we first take a look at the various Scenario / usecase / solution
> ?  and remove the idealism of kill tree-building protocols ?
>

Please read and comment on the proposed new charter as to whether it is
open to your concerns.

> As various documents states, the main paradox of traditional multicast
> lies in the hard trade-off, between states caused by the per-flow per-tree,
> and flooding caused by many-flows aggregated in one-tree.
>

Tree-state is the problem. A tree building protocol is responsible for that
state. :)

> This draft is a justification before Re-charter, and about the
> descriptions of the tree-building protocol, I would like to raise some
> discussion.
>

As above, please comment on the proposed charter. It seems you are in
agreement that the work is worthy of Standards Track. If so, details of the
justification draft are pointless to discuss. The proposed charter will set
the direction for the WG on the Standards Track. Please take the discussion
there.

1.  Introduction
>    [XJR2]: why considered tree-building protocols complex/legacy/no-longer
> apply to current ? that is to say current MVPN are useless ? they not only
> work but also widely deployed!  aren't they ?
>
>    [XJR4] BIER has no tree-building protocol, I think it is not a sure
> benefits, but a feature/technology/philosophy. Real benefits is how we get
> a better solution to specific usecase.
>

The BIER WG will be working on use case solutions using BIER. BIER has no
tree-building protocol. If you have a specific use case that needs a tree
building protocol, write a draft and incite discussion in a WG of your
choice or request a BOF.

Thanks,
Greg

>
>
> Thanks.
>
> XieJingrong
>
>
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Greg Shepherd
> *Sent:* Friday, December 22, 2017 4:56 AM
> *To:* [email-masked]
> *Subject:* [Bier] Fwd: New Version Notification for
> draft-shepherd-bier-standards-track-00.txt
>
>
>
> *,
>
>
>
> From: <[email-masked]>
> To: Greg Shepherd <[email-masked]>, Andrew Dolganow <
> [email-masked]>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>