Minutes IETF 112
mLDP over BIER

Loa: fwd’ to MPLS working group for comments
Alvaro:
* also cc: BESS
* why is it informational?
Hooman: copy/paste problem
Alvaro: no normative refs?
PCE Based BIER

Tony: why is B bit for (non-BIER) while you’re passing around a BIER bitmask, we take to the list, author’s answer not clear
Greg/Tony: extend beyond IP multicast
Dhruv: technical problems

From Chat Box:
Dhruv Dhody:
There are actually lot of BIER bases PCEP extensions right now in PCE WG. So some guidance from BIER on the overall requirements and procedures on the use of PCE and PCEP for BIER would be very helpful.
Tony Przygienda
hmm, ok, yeah, we need to be in sync here .
just thinking out loud I’m not even against to have this work in PCE since it’s mostly PCE procedures/protocol & BIER here just provides an architecture (as in overlay, underlay, BIER layer) which is spelled out in the RFC and should be kept pls ;-)
maybe showing this preso in PCE is the right thing, maybe starting to work together with PCE on req document towards PCE. I’m open to suggestions, Dhruv.I think the current document looks good (but my PCE skills are minimal to be frank) except that it’s too IP multicast specific for my taste looking from BIER side. maybe the doc should get a PCE WG review? authors, I encourage to fwd to PCE WG and ask for comments as well.
Dhruv Dhody
They are presenting in PCE WG tomorrow and targeting it to PCE WG. I did a count there are six documents related BIER on the PCE WG data tracker2
Tony Przygienda
aaah, that’s news, thanks for heads-up. I try to make it to PCE tommorow (but my agenda is exploding frankly already) and will look @ the docs coming towards you.
Dhruv Dhody
Regarding the current document I agree there are things which are generic and not directly related to BIER, I wish they are kept generic in PCEP so that they could be used for non-BIER P2MP case as well.
Alvaro Retana
We should keep the interaction between pce/bier tighter (i.e. more formal than this chat). I would prefer it if bier defined (or at least approved) the architecture before BIER-specifc extensions are specified.
Maybe we need a joint meeting to avoid discussing things several times…
BIER Slicing

Toerless: discussion on hop-by-hop header for v6. side-meeting on friday in relation to the draft
Xuesong: There is a document of Flex-algo for BIER in WG. What is the relationship between these 2 documents?
Jeffrey: didn’t read it
Hooman: Similar question as previous. The type of data plane, IPv6 or MPLS should also be considered
Zheng： Flex-algo is for different sub-domain, this document is for 1 sub-domain, so they are different.

From Chat Box:
Xuesong Geng
@zheng, continue the discussion of network slice for BIER, if the goal of these 2 documents is similar with different method, one with 1 sub-domain and one with different sub-domain, I think it means there will be potential conflict here
Aijun Wang
we are also expecting to extend the meeting for the additional drafts
Zheng Zhang
No, one FA is take effect on a SD, but the SA is take effect in a SD, in my understanding there is no confliction.
in a SD there may be several SA
Xuesong Geng
Whether there is conflict depends on the problem, no the solution method
Zheng Zhang
several SAs
BIER-TE/CGM2

Zhaohui: how many bits to reach 2K routers ?
Toerless: we didn’t specify units yet so <flap hands, flap hands> ;-) Also depends how many intermediate nodes to reach receivers.
So basically need simulate different topologies to figure out #bits for receivers on different topologies.
Tianji: internet area had something similar? can you say something about feedback there?
Toerless: said “no, don’t remember” in complex way ;-) We just suggest here to muck around with BIER bitmask semantics again ;-)
Sandy: Whether the bitstring will be cut through the process
Toerless: explains how it works (recursive extraction) and it will be shorter and shorter
Tony: do we have charter to do that? is that still TE?
Greg/Jeffrey: TE+ ?
Greg: the way charter reads we have TE plane as generic concept so nothing prevents us working from something like this if adopted.
BIER-TE-LAN

Greg: is the problem even valid? the mask is misconstructed
Toerless: will look in more detail
EGRESS-PROTECTION

Jeffrey: why adding now a vector?
Michael: we have different cases & different solutions, some simpler than other

From Chat Box:
Tony Przygienda
I htought this egress stuff has still unaddressed issues Jeffrey brought up that can replicate the packet under normal ops