Re: [Bier] draft-xie-bier-ipv6-mvpn question:

"Xiejingrong (Jingrong)" <> Thu, 10 September 2020 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DFFB3A0FEB for <>; Thu, 10 Sep 2020 00:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gB7VUcVhUUgl for <>; Thu, 10 Sep 2020 00:41:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6A213A0FE4 for <>; Thu, 10 Sep 2020 00:41:25 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 63DC7EF3C39F16295183 for <>; Thu, 10 Sep 2020 08:41:21 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 10 Sep 2020 08:41:20 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 10 Sep 2020 15:41:18 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Thu, 10 Sep 2020 15:41:18 +0800
From: "Xiejingrong (Jingrong)" <>
To: "Jeffrey (Zhaohui) Zhang" <>, BIER WG <>
Thread-Topic: draft-xie-bier-ipv6-mvpn question:
Thread-Index: AdZw6Yw4P4783jMOTziUSmhOVRVLCQWUiiOg
Date: Thu, 10 Sep 2020 07:41:17 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Bier] draft-xie-bier-ipv6-mvpn question:
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 07:41:27 -0000

Hi Jeffrey, 
Appreciate sincerely for raising discussions about the draft.
Please see my response inline below marked with [xjr]


-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [] 
Sent: Thursday, September 10, 2020 4:36 AM
To: Xiejingrong (Jingrong) <>om>; BIER WG <>
Subject: draft-xie-bier-ipv6-mvpn question: 

Hi Jingrong,

The draft says that the x-PMSI routes carry the following:

   o  Route MUST also carry an BGP Prefix SID attribute with an SRv6 L3
      Service TLV carrying an Src.DTx IPv6 address uniquely identifying
      the MVPN instance.

So this is supposedly to be the counter part of an upstream assigned label - in fact both the context (ingress PE) and upstream label are encoded into the same source address.
[xjr] Yes, very precisely. The source address is very similar to the upstream label and its context.

Section 6.1 talks about encapsulation but does not talk about decapsulation. Supposedly the Src.DTx, instead of destination address is used to identify the VRF table for the next lookup. 
[xjr] General consideration is to set this Source-address lookup as default behavior for c-multicast packet decapsulation, and provide some configuration knob to change that.

Since the (Ingress PE, VPN) combination could be huge as described in section 2.1 of draft-ietf-bess-mvpn-evpn-aggregation-label addressed, how is the scaling addressed?
[xjr] Yes, draft-ietf-bess-mvpn-evpn-aggregation-label presents a scaling problem (as below text copied from the document). 
   Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000
   VPN/BDs.  Each ingress PE has to assign 1000 labels, and each egress
   PE has to be prepared to interpret 1000 labels from each of the
   ingress PEs.
This scaling problem is common to MVPN/EVPN, and this draft has the same scaling problem too.
One point to mention, some MVPN service may not want a full-meshed MP2MP model, but an asymmetrical P2MP model with small number of "Sender sites" and large number of "Receiver sites" [RFC6513 section 2.3].
This scaling problem can be relieved in such case.

Presumably the same concept of "DCB label" can be used - encoded into the function portion of the source address - in that case that should be advertised as part of the label field of PTA, and it must be made clear that only the function portion of the source address is used for lookup, and every PE must agree which part of the addresses is the function portion.
[xjr] Good idea to apply the "DCB label" solution to solve the problem!
To advertise such indication from Ingress PE to Egress PE is a good way to keep alignment between them.
It can also detect possible confliction (for example, Ingress PE support this method but Egress PE doesn't).
Use configuration knob independently on Ingress PE and Egress PE may also be reasonable ?
Besides, would you think it necessary to extend the "DCB label" to 24bit to cover the VNI length ?

   In case of inter-AS scenario, BIERv6 packets may travel through
   unicast to a Boarder Router (BR), and then replicate in a single
   intra-AS BIERv6 domain.  How such non-segmented BIERv6 scenario can
   be supported is outside the scope of this document.
Can you elaborate the above scenario (BIERv6 packets unicast to BR and then replicated)? Is it a scenario that must be supported?
[xjr] The above scenario is covered in <draft-geng-bier-ipv6-inter-domain>, so it is not covered in this document, as this document mainly focuses on the "BGP-MVPN" protocol extension.
[xjr] It's an optional scenario I think.

   How segmented MVPN, for example, between BIERv6 and BIERv6, or
   between BIERv6 and Ingress Replication(IR) in Non-MPLS IPv6 networks,
   is outside the scope of this document.
When/where would the above two scenarios (non-segmented and segmented) be covered?

[xjr] A simple non-segmented inter-AS consideration (using some configuration for inter-AS BIFT construction) is covered in <draft-geng-bier-ipv6-inter-domain>.
Seems to me that there is no much "BGP-MVPN" protocol extension needed for non-segmented MVPN, and the main challenge is the underlay inter-AS BIFT construction.
<draft-zzhang-bier-multicast-as-a-service-01> is an example using BGP for inter-AS BIER information advertisement and BIFT construction for non-segmented inter-AS deployment.
[xjr] Haven't considered segmented MVPN in detail yet, Will come back if I have any further thoughts.


Juniper Business Use Only