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

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Thanks for comments Jingrong

Inline HB>

Regards

Hooman

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

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

Hi
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
   modifications:
[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
   assigned.

   - 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
   IBBRs.
[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!


Thanks
Jingrong