IETF Logo Mail Archive

Re: [Bier] Call for adoption: draft-xiong-bier-resilience-01

<xiong.quan@zte.com.cn> Fri, 15 February 2019 11:51 UTC

Return-Path: <xiong.quan@zte.com.cn>
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 84E32130FCB for <bier@ietfa.amsl.com>; Fri, 15 Feb 2019 03:51:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.208
X-Spam-Level:
X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 YCxHJE5fY9XZ for <bier@ietfa.amsl.com>; Fri, 15 Feb 2019 03:51:16 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 6E6DB130FBB for <bier@ietf.org>; Fri, 15 Feb 2019 03:51:16 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 48054B586A4862AF6839; Fri, 15 Feb 2019 19:51:14 +0800 (CST)
Received: (from root@localhost) by mse01.zte.com.cn id x1FBpB2Z053594; Fri, 15 Feb 2019 19:51:11 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Message-Id: <201902151151.x1FBpB2Z053594@mse01.zte.com.cn>
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse01.zte.com.cn with SMTP id x1F8Npun002183; Fri, 15 Feb 2019 16:23:51 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Fri, 15 Feb 2019 16:23:53 +0800 (CST)
Date: Fri, 15 Feb 2019 16:23:53 +0800
X-Zmail-TransId: 2afa5c667719bc54ee92
X-Mailer: Zmail v1.0
Mime-Version: 1.0
From: xiong.quan@zte.com.cn
To: zzhang@juniper.net
Cc: bier@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse01.zte.com.cn x1FBpB2Z053594
X-MSS: AUDITRELEASE@mse01.zte.com.cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/8aEpwJ5MNg3FbwMrX_CHwkq19RQ>
Subject: Re: [Bier] Call for adoption: draft-xiong-bier-resilience-01
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 15 Feb 2019 11:51:26 -0000

Hi Jeffery,




Sorry to reply late!  I was on vocation during last two weeks.

Thanks for taking your time to review and sharing your comments, much appreciated.

draft-xiong-bier-resilience is an informational draft and its goal is to summarize and specify BIER resilience use cases and related failure detection methods.
We try to specify all possible scenarios for BIER-specific network but maybe no need to be done in BIER related methods.
The document mainly focus on providing use cases with  the failure detection methods like P2MP BFD and active tail which is defined in draft-hu-bier-bfd.

More comments are welcome to fix the draft. Thank you!

Best Regard,
Quan







"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Fri, 25 January 2019 18:36 UTCShow header


Hmm … I had some email exchanges on this topic with a few folks before but looks like I forgot to compile and send out my comments soon after the Bangkok meeting.

Anyway, I think we need more discussion on the content before adoption.

Quite a long time ago we discussed with some customers and the following are a summary:


 * BIER makes use of unicast FRR so traffic interruption is minimum
 * Same as unicast
 * Therefore MoFRR or live-live is not really needed
 * Live-live might be done for mission critical applications
 * Just send two streams in different subdomains (with disjoint underlays)
 * Application must be responsible for merging the two streams and discard duplicates
 * It’s not feasible or it does not provide live-live protection value for a BFER to pick which stream to deliver
 * Switch over can’t be link status based
 * Traffic based switch over only possible for CBR, and even so due to FRR traffic loss may not be enough to trigger detection



For the three use cases in draft-xiong-bier-resilience:


3.1. End-to-End 1+1 Protection

3.2. End-to-End 1:1 Protection

3.3. BIER Link Protection



1+1 Protection is what we referred to as live-live, but it only make sense if both copies are sent to the CE (using MVPN example) for it to do the merge, and that is really not BIER specific (it is rather an overlay function).

BIER Link Protection is inherent of unicast protection and nothing special needs to be done.

With the inherent unicast FRR it’s not clear to me what value the 1:1 protection has.



Jeffrey

From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Friday, January 25, 2019 1:12 PM
To: BIER WG <bier@ietf.org>;
Subject: [Bier] Call for adoption: draft-xiong-bier-resilience-01

Please read and reply to this thread with your vote for/against adoption of:https://datatracker.ietf.org/doc/draft-xiong-bier-resilience/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxiong-2Dbier-2Dresilience_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=STb7mqddzf1ELpQUCskrlZeKWCg8DUFLm6tGxLR5-N4&s=zxYw2qZxEAraeYYpbwQ4j3pvaDxP-VTa-Zj70NrZh4U&e=>..as a BIER WG document.

This starts a two week counter.

Thanks,
Chairs
(Shep)

v2.23.0 | Report a Bug | By Email