BIER WG Minutes, Day 1 IETF 103, Bangkok, Thailand Wednesday, 7 November 2018 09:00-11:00 General comment: Please avoid scheduling with SPRING Chairs Comment: very tight agenda Stig: discussion on the PIM join draft is not on the agenda but wanted to have a discussion about it as some of the last call comments did not get addressed PRESENTATIONS: #1: mldp signaling bgp Presenter: Hoooman Draft: draft-hj-bier-ldp-signaling Toerless Comments: is anyone selling services over this? Hooman: Yes, this does exist Toerless: The labels need to be received and looked upon in context. Hooman: between PE and Root same MVPN procedures Toerless: Could the came label end up getting sent representing different trees by different EBFRs? Ice: :He means on the way back, There is a global label or context label that makes the tress/P-MP unique Ice: when you send out the mLDP FEC to the egress BBR. You are saying this is now being sent natively into BIER. Hooman: New BIER pkt type "MPLS". Ice: how do you take care of pkt loss, retransmission, highly recommend not coming up with a new protocol...either use tLDP. More discussion needed Andrew D: it is a valid point that we need to figure out that the pkt arrives at the far end. MVPN procedures are fundamentally wrong, as you add service aware on a P router.So, do we need to enhance the draft to pay attention to packet loss Tony P: please keep all the overlay signaling out of the data path Jeffery Zhang: based on offline discussions: if we only consider mLDP, RFC7060 is the best, if you want to go beyond mLDP, them BGP MVPN may be the best way to go, but love to continue this Hooman: tLDP is a great option but not generic enough, but MVPN procedures, I could not figure out, is how can you run those procedures on the P-router? Ice: Responding to Andrew: with MVPN we know our Egress border routers, Tony P: there is a good architecture, don't be pleasant, but make sure it is not painful or hack Andrew D: fundementally, if there was no MVPN, then perhaps there is a way to make this happen. You may end up nesting MVPN inside an MVPN. If there is MVPN between PEs and then we try and use MVPN procedures would be cumbersome. Jeffery Zhang: In this case the Border Routers are not traditional P routers #2: Bier Prefix Redistribute Presenter: Sandy Zhang Stig: I see a BFIR range, would it be an option to use a set? Sandy: Yes, we can change it Stig: would need more than 16 bits Jingrong: RFC makes it clear that it can support inter-AREA advertisement Sandy: No it does not Jeffery Zhang: this is a lang issue. In the use case from Sandy, there are different IGP domains, not areas. Jingrong: Does this make things more efficient when advertising the prefixes? We are not advertising one by one or are we? Sandy: Yes, we optimize #3: Global vpn-id advertisement Presenter: Sandy Zhang Jingrong: I think this is a good idea only for the non-segmented deployments. But for segmented, then the ABR needs to allocate the resource dynamically and make it confusing. Sandy: we welcome comments or suggestions to avoid a new protocl type Huwawei: Comments around protocol type. #4: bier-mtud presenter: Stig Draft: draft-venaas-bier-mtud-02 Stig: Should this be adopted for WG? Chairs: Poll the room for adoption Alvaro: concerned,.needs to get transport people on board. Make sure we get early transport area review as some of the mechanisms as we are ignoring some links. Chairs: what is the process? Alvaro: you can use the tracker to do this. And do it before we accept it for adoption #5: bier-pfm-sd Presenter: Stig Draft: draft-venaas-bier-pfm-sd-00 Homman B: question: the routers that are between PIM and BIER, packets sent to all routers? Stig: Yes, we broadcast sources so we don’t need to do a discovery Toerless: Are the joins unicast? Stig: according to PIM over BIER draft they are unicast Toerless: Why not BIER casted to the upstream? What is the best LAN procedures for the multiple upstream and down stream Stig: for reliability it would be good if both BFIR1 and 2 get the messages. Toerless: Cost across the BIER domain is not taken into account...BFIR1 and 2 in US and BFER in Europe Stig: if you want to account for cost across the BIER domain, you could add the cost to get to BFIR1 or 2 Hooman: this procedure is happing before Stig: main addition is a procedure at the egress BFER in the cache to have the S,G, and metric info Chair: do we adopt? Room: few yes Hooman: from procedure point of view, it is okay. But I am not sure what is missing to find the BFIRs as we have already added a lot of mechanisms? #6:Applicability of BIER Multicast Overlay for Adaptive Streaming Services Presenter: Debashish Purkayastha Draft: https://www.ietf.org/id/draft-purkayastha-bier-multicast-http-response-01.txt Alvaro: You are documenting how it would work there? You are not proposing anything? DP: this is an applicability document. Just how to use BIER, use BIER as an overlay Alvaro: I think it is good, but not sure of the charter. I think the chairs need to look at the charter and clarify for all of us if we are looking at the charter appropriately Tony P: Loa things that it is more in his corner Alvaro: Charter says one use case document. Tony P: Charter says "how it has been done in MVPN" Alvaro: want to be careful what door we open... Toerless: This is a good documentation for how to use BIER for a use case Andrew D: This is an information draft. It helps put ideas into peoples heads...innovation Tony P: Applicability makes sense here as it is about BIER Greg as Chair: use case helps drive other groups #7:BIER-TE-ARCH Presenter: Toerless Eckert Draft: draft-ietf-bier-te-arch-01 Toerless: We do not have an API to set BFIT etc Tony P: Wrong, we do. The YANG model does address that Toerless: what are the allowed FBMs..put a constraint. Tony P: BFR2/2 on slide 8 could be fabric in the router. This discussion belongs on the YANG draft Ice: BIFT1 and 2 are they the same table? Toerless: Yes, same table : Ice, draft says cannot be in the same table Sandy: FBM in the YANG is read and write Tony P: be careful programming the bits...it is programming in assembly! #8:BFR Tethering Presenter: Ice Wijnands Draft: draft-zzhang-bier-tether-00 Chairs: any comments? Can we go to LC. Take this draft to last call. Sandy: Control plane is good. But need more info on the data plane..want to know how packets are forwarded on router X Zhang: They are native BIER packets Tony P: think OS X when you do not see the the label, Andrew D: This will be more expensive to do at the end Tony P: It can be less, think about having to rum all multicast procedures on router X. #9: Multicast/BIER As A Service Presenter: Jeffery Zhang Draft: draft-zzhang-bier-multicast-as-a-service-00 Andrew D: 256 is not a lot, we have bigger networks. My dilemma, BIER was supposed to be simple, the draft solves some of the problems, but are we doing ourselves a favor. This is complicated. Greg S: so what you want to see is the actual use case to better understand why we need to do this? Andrew D: Yes, BIER is simple, but this makes it complicated Toerless: Is this the right time to do this? We should know if it is possible to sell BIERaaS, but do we really need to do this work now. Good to know we could do it. What does this give me as a network overlay multicast service provider ? Greg S: Can we discuss this on the list and understand it better.