[bess] [bier] Comments on draft-ietf-bier-mvpn

Xiejingrong <xiejingrong@huawei.com> Fri, 02 February 2018 08:04 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5A54312F4E2; Fri, 2 Feb 2018 00:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Status: No, score=-4.23 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XLYt1TrAbaIS; Fri, 2 Feb 2018 00:04:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (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 1EA33124D6C; Fri, 2 Feb 2018 00:04:00 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id C94B958E2990C; Fri, 2 Feb 2018 07:48:15 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com ( by lhreml701-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 2 Feb 2018 07:47:31 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([]) with mapi id 14.03.0361.001; Fri, 2 Feb 2018 15:47:11 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "bier@ietf.org" <bier@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bier] [bess] Comments on draft-ietf-bier-mvpn
Thread-Index: AdOb+DRSc9gG+YyfSJGn3PjcdKHl6w==
Date: Fri, 2 Feb 2018 07:47:11 +0000
Message-ID: <16253F7987E4F346823E305D08F9115A99A15C2C@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115A99A15C2Cnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/pXXHaHpqVogT48pKyXRi4jHX5zw>
Subject: [bess] [bier] Comments on draft-ietf-bier-mvpn
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 08:04:07 -0000

Hi, Authors:

I have a question about <draft-ietf-bier-mvpn-09>: whether we can leverage LIR-pF in segmented tunnels scenario, to get a better multicast join latency ?

This draft states that Segmented P-tunnels require per-flow vpnlabel, so have to use S-PMSI(S,G) AD routes to carry such per-flow vpnLabel.

Obviously, this will result in an increase in the number of routes, and more importantly an increase in multicast join latency, comparing to the case of Non-Segmented P-tunnels using LIR-pF.

My consideration is , When all segments are type of BIER (greenfield), Is it possible to use a Per-vpn VpnLabel, and use LIR-pF for efficiently explicit tracking ? like below:

Topo: [SRC--IngressPE--ABR--EgressPE--RCV]
1) Use I-PMSI route with PTA<type=BIER, VpnLabel> and S-PMSI(*,*) route with PTA <type=NonTnlInfo, Flag=LIR-pF>, to advertise the Per-vpn Label, and collect all the per-flow Leaf AD.
2) Or use a S-PMSI(*,*) route with PTA <type=BIER, VpnLabel, Flag=LIR-pF>, and Let ABR to re-generate a S-PMSI(*,*) route with PTA <type = BIER, VpnLabel,  Flag=LIR-pF> to EgressPEs.

Through have got a nice clarification from Eirc about <draft-ietf-bess-mvpn-expl-track>, I found that this question still in my mind :-)