Re: [Bier] Comments on <draft-hj-bier-mldp-signaling-00>

Xiejingrong <> Wed, 24 July 2019 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D8E91200FA for <>; Wed, 24 Jul 2019 06:35:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jZS38UDGHcg2 for <>; Wed, 24 Jul 2019 06:35:38 -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 5C30D1200E3 for <>; Wed, 24 Jul 2019 06:35:38 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id EE3BD399E1889DCD22FB for <>; Wed, 24 Jul 2019 14:35:36 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 24 Jul 2019 14:35:36 +0100
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Wed, 24 Jul 2019 21:34:22 +0800
From: Xiejingrong <>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <>, BIER WG <>
Thread-Topic: [Bier] Comments on <draft-hj-bier-mldp-signaling-00>
Thread-Index: AQHVPRgC3pDalx5MhUaWQCG3v6wi+qbX2SWAgAH0lYw=
Date: Wed, 24 Jul 2019 13:34:21 +0000
Message-ID: <>
References: <> 217C555B-17AE-4905-A65A-5C5FED4A7960, <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_16253F7987E4F346823E305D08F9115AAB90C441nkgeml514mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Bier] Comments on <draft-hj-bier-mldp-signaling-00>
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: Wed, 24 Jul 2019 13:35:42 -0000

Hi Hooman,
Thanks for the response.
we can talk about this in person after BIER WG?
We might need to beef up the draft with a bit more explanation here.


From: Bidgoli, Hooman (Nokia - CA/Ottawa) []
Sent: Tuesday, July 23, 2019 23:38
To: Xiejingrong; BIER WG
Subject: RE: [Bier] Comments on <draft-hj-bier-mldp-signaling-00>

Thanks for comments Jingrong

Inline HB>



From: BIER <> On Behalf Of Xiejingrong
Sent: Wednesday, July 17, 2019 11:22 PM
To: BIER WG <>
Subject: Re: [Bier] Comments on <draft-hj-bier-mldp-signaling-00>

it's on draft-hb-bier-mldp-signaling-over-bier-00
sorry for the typo.
From:Xiejingrong <<>>
To:BIER WG <<>>
Date:2019-07-17 23:10:45
Subject:[Bier] Comments on

I have read the draft and think it looks far better by using multi-hop tLDP session than the complex mechanism that I had not understand well in previous draft.
some comments/questions below:

3.2. EBBR procedure method

   The Egress BBR (EBBR) is connected to the mLDP domain which the root
   of the P2MP or MP2MP LSP resides on. The EBBR should accept the tLDP
   session and assign a upstream assigned label for arriving FEC.

   The EBBR should follow the [RFC7060] procedures with following
[XJR] the following procedures follow 7060 or 7389 ?

HB> follows 7060 not sure what does 7389 has to do with this.

   - The label assigned by EBBR cannot be Implicit Null. This is to
   ensure that identity of each p2mp and/or mp2mp tunnel in BIER domain
   is uniquely distinguished.

   - The label can be assigned from a domain-wide Common Block (DCB) [I-
   D.zzhang-bess-mvpn-evpn-aggregation-label], as well as upstream

   - The Interface ID TLV [RFC6389]includes a new BIER sub-domain sub-
   tlv (type TBD)
[XJR] this Interface ID TLV is carried in message from EBBR(BFIR) to IBBR(BFERs)?

HB> this is part of TLDP signaling

   With same token the EBBR should track all the arriving FECs and the
   IBBRs that are generating these FECs. EBBR will use this information
   to build the bier header for each set of common FEC arriving from the
[XJR] How does EBBR track the IBBRs?
[XJR] Let me imagine:
(1) IBBR(BFER) receive the mLDP Mapping from downstream LSR, and send a xxx message to EBBR(BFIR).
(2) EBBR(BFIR) send a LDP Mapping message (with Upstream-Assigned Label Request TLV) to all its tLDP neighbors ?
(3) BFIR should tell the BFERs the upstrea-assigned Label, and the Sub-domain, and the BFIR-id at least I guess.
Is that right ?
What's the xxx message (in case the tLDP is static configured, in case the tLDP is dynamicly established)?
Thinking of the information need to carry in the LDP message, there will be MPLS WG be considered more.

HB> we can talk about this in person after BIER WG? But basically this implementation, for an specific upstream assigned label on BFIR, all the TLDP PEERs (BFERs) that have requested for that label should be noted. The TLDP PEER session IP can be used to correlate it to a BIER prefix (BFER) for building the BIER header.
We might need to beef up the draft with a bit more explanation here.

4. Datapath Forwarding

4.1. Datapath traffic flow

   On BFIR when the MPLS label for P2MP/MP2MP LSP arrives a lookup in
   ILM table is done and the label is swapped with tLDP upstream
   assigned label. The BFIR will note all the BFERs that are interested
   in specific p2mp/mp2mp LSP (as per section 3.2). BFIR will put the
   corresponding BIER header with bit index set for all IBBRs interested
   in this P2MP LSP. BFIR will set the  BIERHeader.Proto = MPLS and will
   forward the BIER packet into BIER domain.
[XJR] is there a proper BFIR-id value to be mentioned ?

HB> the BFIR should have a list of all BFERs that are interested so you are probably correct that in the draft we need to mention that the targeted LDP session setup should be in sync with BIER prefix used.  If they are then the TLDP Peer and the FEC can be used to find all the BFERs.
I will add more details about this in next version of the draft, Thank you!