Bier Status PagesBit Indexed Explicit Replication (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2015-Mar-24 —Chairs:
IETF-103 bier minutes
Session 2018-11-07 0900-1100: Boromphimarn 3 - Audio stream - bier chatroom
Session 2018-11-08 1120-1220: Boromphimarn 1/2 - Audio stream - bier chatroom
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. ______________________________________ Day 2 Thursday, 8 November, 2018 11:20-12:20 Bier-resilience draft Discuss the resilience for bier Use Case 1 E2E 1+1 Protection bier p2mp BFD Use Case 2 E2E 1+1 Protection bier p2mp active tail BFD Use Case 3 Bier local protection. Bier p2p BFD Next steps: Further research direction Read: 9 Adopt: 5 BFD for Bier Draft-hu-bier-BFD-02 Changes from version 00 to 01 Removes definition of bier OAM packet format Removes the one hop bootstap part and keeps multihop boostrap Stig: since BFD has to be as efficient as possible may be better to not use the OAM header. Doesn’t really add any value. Tony: how to nail the BFD path ZTE: goal of OAM shim is similar to well known udp port. Demultiplexing protocols. We propose to use ach BFD control message format without udp overhead. Bfir id as identifier of source. Is a tradeoff. Could use ip packet and follow 5884 and use destination ip address as loopback range and use BFD well known port. If you don’t have udp header need to identify as a BFD packet. Tony: do not remember if encaps forces you, ZTE: packet already has BFRID Tony: out of path is a problem. Greg ZTE: in terms of processing there is not much difference because you have to demultiplex anyway Stig: you have bier next header and then 4 bytes and says BFD packet and don’t see why there is the 4 bites. Greg ZTE: could have multiple points, could say next protocol is BFD next protocol is whatever. Reshad: would have to define something new. Greg: either udp or ach. Ach doesn’t have a header so only have BFD control message. What Stig proposes is to have it in the next protocol but could run out of space. Greg: don’t have to agree now but good to discuss. Bootstrapping bier BFD session Next steps we will add active tail solution Reshad: when we did LSP ping with BFD there were some issues. Greg: there will be other alternatives to bootstrap. Problem with using ping to boostrap on mcast is you might be too late. Have to do it periodically. TonY; it’s a function of the overlay whatever the overlay is. Greg; you have to give information what the descriminator is. Mike Bier v6 encap Our draft proposes bierv6 encap for ipv6 networks using an ipv6 destination option extension header. Would require a new bier destination option type codepoint from IANA. But really there are a variety of bierv6 proposed solutions, bierv6 encap and otherwise, and we should reference these options and provide clear use cases. 9 read 7 interested in work Greg: its not encap when adding bier bits to v6 Jingrong Segmented Main problem mcast join latency. More efficient in mvpn explicity tracking draft. Is this problem bier specific or more generic. GTM using IR has a very similar option, etc. Jeffrey: all the discussions convince me more that this is not specific to bier. Except the bier mvpn draft says to not to use lirpf explcity tracking when doing segmentation, anything else is generic, applies to any tunnel. Also, he loves segmentation but everytime we bring it up the customer says they have to maintain states on the segmenetation points and we are adding more here making it less attractive. Jingrong: this draft only includes the bier specific part and not the genertic part. Do you mean this draft must add more generic context and move to other wgs? If bier didn’t exist this draft would still make sense. Whether it belongs to another wg it should because it is generic. Jeffrey: we have a more generic problem don’t have to limit it to bier. If you need to do segementation and per flow label. Jingrong: perhaps have another draft that’s more generic. Jeffrey: the benefit is not worth the cost. Tony: this is putting more state in the network. You still have mldp and bier on top. Don’t think this is something this group. Would like to see a strong use case and migration scenario. Greg: thin support. Jeff: the state you put in place doesn’t justify what you are trying to achieve. Other work: Stig: join signaling. Only look at the join from looking at the join header. Either you have an implementation. Hooman: isn’t bfir id for ibbr in bier header already Stig: my point is if you look at the layers you do the bier encap first and then punt the packet but pim doesn’t have that context for explicit tracking in order to know where to forward the packet. Hooman: that’s part of the bier implementation table. Stig: pim needs to add an oif to say where to add a join. Hooman: the bier is where the oif comes from. You can note it but to me this is implementation Ice: in bier there is also sub domains it doesn’t tell you the sub domain. Its encoded in the lable but no context in the lable. Its nicer if you can add it to the pim join. Hooman: that’s fine we an add the ibbr ip address as source but then when you removet he bier header the extraction becomes an issue. Stig: when pim gets it’s a pure ip packet and the easier way is to put it into the packet itself. Hooman: the implementation has been done from our point of view we’ve had no issues just build the oif from the info you have. Stig: does pim have any state related to the oif to say what bier sent the packet to? All pim knows is to forward the packet to bier. Hooman: when you grab this from the data path you just send out with the ibbr whatever the structure is. Pim notes this and we go to the tble and field the table with new oif. Stig: you use the source of the pim join to track the receivers. Jeffrey; when you send a packet up the stack you remove the headers one by one. When pim gets the packet you just have a pim packet. Would be good to have the additional info embedded in pim. Tony: nothing wrong with implementation of that. Architecturally however your bgp and pim and bier need to be collocated and do we accept that? Its not our mandate to determine how to implement this. Hooman: the first draft that we gave out was trying tosolve this by coming out with new bier type and putting ip address of ibbr as source id. Jeffrey; you just put the signaling. I do realize yes your implementation could figure it out in implementation but easier way would be to send that information in pim packet. Stig: when wrote igmp draft just use source of bfid. You don.’t know the sub domain though.