BIER WG Minutes - Session 1 0-Welcome, Notewell, Agenda bash5minChairs Greg(chair): Apologies for the delay in posting the agenda. But all good now. Tony on jabber. Sign blue-sheets. Note well, noted. Let's start with stig. PRESENTATIONS #1: 1-draft-ietf-bier-mtud10min Stig (Cisco): Few open issues raised during the adoption call. Stig (cisco): Reading BIER IGP drafts, its hard to tell if ABRs advertise prefix across area. It seems optional? Les Ginsberg (Cisco): At least for ISIS, early drafts did't support it. But later we added support to advertise across area. Stig (Cisco): Is this advertisement across area optional ? Les (Cisco): subject to configuration. Stig (Cisco): Ok, so the understanding is, as long as we advertise the bier prefix across area, we advertise the sub tlvs as well Les (Cisco): Yes Stig (Cisco): Is there any other issues other than whats listed here? ok, so we will update the draft addressing the open issues in next rev. Greg: When do you think we can call for last call Stig (Cisco): Address all the issues and potentially in next ietf Greg: ok, then, we will not take in to the list for now Les (Cisco): Have we decided which way to go? PMTU vs This one. Combine or take one path? Both are work group drafts ? Stig (Cisco): There is a difference between these two draft. May be we can update the text in drafts to explain the relation between these two. Greg: Do you think we can combine ? Tony: What exactly is your suggestion Les? Les (Cisco): There may be some people who ask why do you do both ? Greg as chair: Stigs suggestion is that each draft have their use cases, so it's better we doc separately. Is that reasonable? Greg: How many thinks we shall do individual doc ? 6-7 hands Greg: How many thinks we should merge? 1 hand Greg: Ok, we will take this discussion to the list Alvaro (AD): It would be great if both drafts progress/advance together Greg: Thank you #2: 2-draft-ietf-bier-mld 5minStig Venaas Stig (cisco): No slides, Nothing had changed past few ietfs. Stig (cisco): Need help - people to review and give suggestions/comments Greg: Who's read the draft ? - 2 to 3 hands Greg: Who thinks it's ready lets take to list. 2 to 3 hands. Ok, same guys who read the draft. Greg: Lets take it to the list for Vote. #3: 3-draft-dhanaraj-bier-lsr-ethernet-extensions10minSenthil Dhanaraj Senthil(Huawei): No doubt this is required. We need to discuss to confirm the bift-id adv scheme. Call for adoption? Greg: How many read the draft? - 6-7 hands Greg: How many think its ready for adoption - 6-7 hands Gerg: How may think, its not ready for adoption- No hands Greg: Room support. Let's take it to the list. Tony(juniper): Add a additional sentence which says that the BIFT-ids in MPLS and this draft is completely different. Tony(juniper): Same BIFT-ids in mpls and this, does't mean they are same. Its one sentence, but it'll prevent people from doing crazy stuff. Senthil(Huawei): Okay #4: 4-draft-purkayastha-bier-multicast-http-response15minPurkayastha Purkayastha: Additional details added. Seek feedback and thinking of adding other interesting use-cases applicable here. Jeffrey (juniper): Im little confused. Do you use ip at all for this or not? Purkayastha: We don't specify. Http response over bier. Overlay over bier Greg: What's the stats of this draft, you have got use-cases to add ? Purkayastha: We are open for comments and i have listed some of the uses-case if interested can be taken in to draft Greg: Hands to contribute to use-cases - no one ? Greg as chair: So far what we've got is good use-cases. Im little hesitant to add more. Greg: Request authors to put in list and ask feedback from list. Part of process anyway. #5: 5-pim-signaling-0510minHooman Bidgoli Hooman: Good discussions with eric, stig and others. Hooman: Added more details. If there are no other comments, we want to ask for LC. Greg: Who's read the draft? - many Greg: Lots of discussion and sounds like we have converged. Greg: Who think its ready for LC? - Many Tony: 5 hands Greg: Lets take to list. #6: P2MP mLDP signalling (Hooman) Hooman: Not going to present. Hooman: Had a discussion with jeffrey. We will brainstorm again and come up with alternate soln. #7: 6-bier-ospfv3 5min Nagendra Kumar Nagendra(cisco): Seek comments. We think it's ready. Call for adoption. Greg: OSPFv2-Bier-Extn origniates here. Did it finished here or in LSR? Room: Yes, it originated here and adopted here in BIER WG Greg: Ok. It makes sense to do this here. Greg: Who read this draft ? - 4 - 5 hands. Greg: Who thinks its ready for adoption ? - 4-5 hands. Greg: Same set of hands as read. Greg: OK, lets take it to lst #8: 7-draft-merling-bier-frr-00 10minMichael Menth Michael: Need extensions to BIFT table. Working prototype exist based on P4. Need inputs from WG Jeffrey: At the top you mentioned, BIRT traffic resume after underlay converges. Jeffrey: At the bottom you also say, with FRR we can fast re route. Whats the difference ? Michael: In case of failures, the routing underlay need to converge. If we have FRR, then traffic can go over backup path immediately. Michael: After a while, normal forward entries repaired after underlay convergence. Jeffrey: BIFT entries include backup path itself. Very advantage of BIER is we can reuse the underlay. We don't need do anything special. No need extensions. Jeffrey: So I'm not sure why we need this document. Jeffrey: When you say, you need BIFT extensions, do you mean we need extension for protocol or your internal implementation ? Michael: Additional fields to BIRT. Some space to store. Michael: Link failure are easy, Node failures are different Jeffrey: My understanding is, unicast node protection can be reused here and special things are not required. Ice: After failure, you are rewriting the bits, right? May be its required only with BIER-TE Michael: No Ice: Why bitmask need to change for normal BIER Michael: Use underlay FRR to not to send failed next-hop Greg as chair: That's BIER-TE, in normal BIER, transit do not have bits Hooman: Echo Ice comments. FRR make before break. But here, you try to go over next next. Hooman: Why not use IGP for protection? Underlay IGP can take care of everything? Michael: We use it to send to next next hop Hooman: Detect failure by 2 ways.. BFD or link fail-hop. IGP takes care of it. I don't see how you can make it any faster than IGP way Greg: you cant specify a bit to specify the next-hop in normal bier. Thats BIER-TE. Hooman: rsvp-te requires signaling to setup FRR. BIER uses IGP. Hooman: As WG, we need to make the stand clear whether we need improve on BIER failure detection time. From implementation, we see BIER is as fast as IGP Rajiv Asati(cisco): Typical challenge with any tunneling based FRR is it increase the traffic in the so called backup tunnel. Common problem with RSVP-TE. Rajiv Asati(cisco): We already have BIER-TE FRR, what's different in this ? Michael: We use IGP here. Jeffrey(Juniper): Does it required any protocol extension ? Michael: Im not sure. We have implemented. It's a local mechanism, so not required. Jeffrey: Thats what i thought, this is about local implementation and does not required standardization Michael: We may need other solution. Jeff Tantsura (Apstra): When we talk about FRR, you rely on BFD or link failure. We don't wait for igp-convergence. Need discuss in routing WG. Stig: Just want to comment on MTU part. Path changes, MTU may change, so PMTU may not work well. Thats why the other solutions for MTU is required. Tony: Quick summary. Complete agree with Ice, Hooman, Jeffrey, Jeff. Tony: I was thinking about controller based solution, it can directly program the silicon. So dont see this need. Tony: We have R-LFA, TI-LFA, .. Can do this Tony: It might just be educational #9: 8-ietf-bier-bgp-ls-bier-ext-04 R.chen: Seek LC. Greg: How many read the doc ? - 3 hands Greg: Ready for LC ? - 2 hands Greg: Lets take it to list to get opinion and last call #10: 9-draft-chen-pce-bier-04 Jeff tantsura (Apstra): Why present here? It should be in PCE WG? Greg: Its fine to present here, but it should also be presented in PCE Jeff tantsura: Yes Tony: Should be possible to program bift via controller. Discussed with sandy. Should sync with yang closely. We need to present same model. Greg: Is it informational here? Are you intend to adopt in PCE WG? Dhruv(Huawei): Yes, adopt in PCE WG Ice(Cisco): I think its good for BIER-TE. But i think, there no underlay, no IGP. FRR? Tony: Use pce for both bier-be and bier-te R.Chen: Now we though only about te Tony: Thats my comment, we can do both. Benefit from the same stuff. #11: 10-draft-ietf-bier-bier-yang-0420minRan Chen R.Chen: Change - Added ethernet, ipv6 encap type. R.chen: Seek WG LC Tony: BIFT programming is very important. Its not added yet to yang model. BIFT is only readable or can be programmable e.t.c ? Tony: We need discuss and take it forward. Definitely, not ready for LC definitely Senthil(huawei): You have added support for new ipv6 encap. Which type (MPLS in ipv6 like 6PE or Bier in IPv6 or BIERv6) you are referring to ? Sandy(ZTE): MPLS and non-MPLS Greg: Question is which ipv6 encap you are referring? Senthil(Huawei): For example, in the model, i still see mpls label fields under ipv6 encap ? Sandy: Okay, we will address this Jeff(Apstra)/Dhruv(Huawei): is it NMDA compatible ? Yang must be compatible with NMDA Sandy: Yes, We can discuss. Greg(Chair): For the WG to discuss further. #12: 11-draft-zhang-bier-te-yang-07 5minSandy Zhang Sandy: Implemented in ODL and verified. This is the 2nd time we are presenting. We think its ready for WG adoption. Any comments ? Greg(as chair): How many of you read the doc ? - 5 hands Greg(as chair): How many for adoption ? - 5 hands Greg(as chair): Room supports. Take it to list #13: 12-draft-hu-bier-bfd-03 10minQuan Quan (ZTE): Discussed in WG several times. Updated to 03 version. Comments addressed. Hooman (Nokia): General question. With p2mp bfd already there, what are you trying to solve here ? Quan (ZTE): p2mp bfd does not solve bier bfd. For bier, it need some extensions to bootstrap bier bfd based on p2mp bfd Hooman (Nokia): In bier, there is no deterministic root/leaf. So not sure what we solve Sandy (ZTE): BIER bfd to enable monitoring of egress nodes, we think it can be used for bier-mvpn failure cases. Jeffrey (Juniper): Same question as Hooman. With bier, we think it's not needed. Jeffrey (Juniper): When you use igp to bootstrap.. why don't use bier sub-tlv isntead of cap tlv Sandy (ZTE): Good point, we can modify Hooman (Nokia): This is oam over bier. Not oam over mpls over bier Tony (Juniper): It is 2nd. It looks like an mixture btw p2mp bfd (not adopted) and s-bfd. To me its look like s-bfd Tony (Juniper): Agree to hooman, could't figure out #14: 16-draft-ietf-bier-te-01 10minToerless Eckert Toerless: All open action items closed. Ask for WG LC. Toerless: Target is experimental. Greg (as chair): Is experimental ok ? Or Can we do standards track ? Alvaro (AD): I would rather do standards track Greg (as chair): To toerless, why is it experimental, to lower bar and get it adopted ? Toerless: Primarily because, not much experience in terms of deployment with BIER-TE. It could be standards track as well if complies charter. Alvaro: I do not remember anything mentioned in charter - about deployment being required for Standards track Greg: Original charter needs working deployments for standard docs as we set the bar higher. Greg: But as we move ahead, with vendors going ahead with whispers of deployment Alvaro: Unless this goes to standard track .. Greg: If we see operator/vendor whispers support, we can go for standard tracks Toerless: Would love to see standard track - love to get feedback in implementations Dhruv (Huawei): Arch doc may be experimental. But pce/yang, we all aims for standard. Dhruv: If this arch is experimental, then all the other supportive docs also become experimental? Toerless: I don't think, thats true. Alvaro ? Alvaro: We do have published standard yang models for protocols that are experimental. Toerless: You tell us, what we should do? is deployment experience must for standards track Alvaro: Requirements to publish standards doc is based on WG interim policy Alvaro: We believe, we can't set blanket statement for each WG or area. Alvaro: What this WG wants to do - it depends? For example, you may say, we need at-least 2 inter-operable implementations or just one implementation or may be no implementation. Alvaro: We want WG to discuss Greg: It's up to us. Our work, our decision. Alvaro: You think this WG needs no implementation for standards doc? Greg: No, what i meant is we need discussion in the WG. Ice (Cisco): DETNET - Use this BIER-TE arch. Is that experimental ? Toerless: Not sure. I think no dependancy. They like readymade rfc to use. Tony: i don't think so, that they use BIER-TE. Not yet. Toerless: Personally like to see standard Jeffrey (Juniper): When first draft came out - i thought i dod't scale. I have not followed since then. Can it scale better now ? Toerless: Not much changed in terms of scale. We need to gain experience. Not everything is PS backbone. Jeffrey (Juniper): Raised this because to decide exp/std track Greg: How many read? - 8 hands Greg: How many thinks it's ready for LC? - 7 support Greg: We have room support. Let's take it to list. Other discussion we need to decides - experimental or standards track. BIER WG Minutes - Session 2 PRESENTATIONS #14: 13-draft-mcbride-bier-ipv6-problem-statement Mike (Huawei): Goal is to be solution unbiased and help WG to make a decision how to go about BIER v6 Greg: Are you saying srv6 works on bier multicast? Mike (Huawei): No, im saying srv6 (ipv6 encap) is progressing in spring WG Greg: What do you mean by native ? Mike: Encapsulate within v6 header. Greg: We are talking about both encode and encap, not only encap Mike: That's right Jeffrey: A comment on ipv6 native. Because bier uses its own header, no matter how you do it, we cannot call it ipv6 native Tony: What is this draft supposed to be as we move forward ? Mike (Huawei): Requirements doc help deciding the solution Rajiv(Cisco): Yes, it should really capture the requirements and any additional use-cases that come out of ipv6. Ice(cisco): Thanks. It's useful to see different options proposed for v6 in one place. Ice(cisco): I think, overall problem is to use bier in ipv6. Many ways to do that. Ice(cisco): As jeffrey mentioned, no matter how do you put it, we would do replication based on bier forwarding. Cannot call as native. Ice(cisco): I feel bier-eth is clean way to do it. People may say bier-eth is not ipv6, but its just perception. Tony(Juniper): Either you use the bytes used for v6 or just put bier after v6 header and dont use the globally significant v6 address. Thats trouble. Ice(Cisco): DA is most native. But there are issues with draft Mike(Huawei): Can address some issues via this draft if it proceeds. Toerless (Huawei): We need to wait for the result in SRv6 arch and encap work as they consider 8200 requirements during review. It applicable to hear as well. Stig (Cisco): I agree about native or not discussions. But i do like using ipv6 tunnels connecting bier domains. Mike (Huawei): Thank u we may add this use-case. Jeffrey(Juniper): ipv6 tunneling of bier packets is not bier forwarding. Jeffrey: MTU issues? Tony(Juniper): Fragmentation in IPv6 is the least of the issue Rajiv(Cisco): Lets not get in to solution mode and lets focus on requirements and use-cases Tony (Juniper): Requirements should in fact been the first slide. Toerless(Huawei): I like the requirements. But what i mention is, there are solution like adding extension header mentioned in the doc Tony: Thoses need to be argued out, the different solutions. Thats the reason for this draft. Toerless(Huawei): Waterfall model? Requirements first, then find solutions? so wondering how to go about it ? Greg: In our discussions, we know we blur encode/encap Toerless: Not ipv6 anymore, Can say same about srv6? Greg: I agree that each extenion header have the purpose. But in case of bier, we do multicast Jeffrey(Juniper): No matter what option you chose, you need new HW Tony: link local Jeffrey: no matter what you do, to do bier forwarding, you need bier hardware Rajiv: From ipv6 point of view. That last 64 bits can be used in many different ways, So use last 64 bits is not a far fetched solution Ice(Cisco): One more point about HW support, We can't assume, if you support BIER we can support other bier solution like ethernet we have discussed here. Ice(Cisco): Where to put the bits? With SRv6, one of things is extention can be put in by application, because it's L3. It something we need to check and put in requirements list. Ice(Cisco): But for routers, its a pain as the bits are so far inside the packet and it needs read deep inside Greg(Cisco): Apps can as well construct BIER header no matter where it is? Ice(Cisco): Need socket support, root access Tony: (use link local) BIER in IPv6 - Bier can be done in control plane slowly for low end hardware. Toerless: I was wondering, no extension headers, it will take away the pain of 8200 stuffs Toerless: But then we may have to re-write the source and destination address at each hop Tony: BIER in 6, will be refreshed Greg: Summarise Greg: Requirements list - good, That we should do Greg: Solution included in the draft - Add reference to the original the docs if they are alive Mike(Huawei): Should we be solution agnostic ? or should we put pros/cons of each solution ? Greg (as contributor): Thats adds more value. As a WG doc, we feel thats what exactly we should do? Toerless (Huawei): I think it's valuable. Greg: Lets take it to list. Re-structure, may be problem statement, requirements first and then the solutions Mike(Huawei) : Request to chairs, To kickstart things, is this the doc that WG wants to adopt? Greg : Who read the draft? - 8-9 Who support for adoption? - 8 - 9 Greg: Solid support from room. Let's take it to list. #15: 14-ietf104-slides-bier-ipv6-encapsulation 20minMike McBride Tony(Juniper): Is the DA is link local scope? Senthil(Huawei): Currently we did't mention about it. We say FF0X, where X could be any scope. Tony(Juniper): Well, it makes a huge difference right. That's ok for now, the discussion are open. Lets go on.. Toerless(Huawei): One of the interesting question is, whether you are allowed to change the bitstrings at transit without calling the operation be decapsulation and re-encapsulation. Toerless(Huawei): And if we call it as the later one, should the node which re-encapsulate are required to change the source-address? Senthil(Huawei): RFC8200 says that, options type data carried by destination options header, the content is allowed to change. Toerless(Huawei): Thats basically for 6man to review. Whether transit can do that, without having to change the source-address. Senthil(Huawei): What we say is that source address is not required to change Toerless(Huawei): Need confirm/review by 6man Rajiv(Cisco): 8200 allow changing the content. IIPM we have similar proposal where the OAM data change each hop, but without changing the source-address. Rajiv(Cisco): But let's still confirm Toerless point. Jeffrey(Juniper): How does multicast DA works in LAN env ? Senthil(Huawei): Need think about it. Jeffrey(Juniper): If you use unicast DA, does the packet be sent to control plane? Ice(Cisco): It has to be a well known multicast address. Other wise igmp snooping will kill this. Tony(Juniper): About unicast DA to bypass non-bier capable nodes, Tunnel exist and it works. Dont do shortcuts Greg: Lets work on problem satement first. Then will get in to these pieces. Jeffrey(Huawei): Use unicast DA in LAN. When you use multicast DA, it's like tunneling on each Hop. Toerless(Huawei): Need consider presenting 6man WG to get feedback. Bier in IPv6 draft is simillar to this. Should we merge? Tony(Juniper): If 6man allows you to not change SA, thats cool. But i think, putting it inside options is overruled. Next-proto = BIER is far more practical. Its kind of similar, we can think abut merge. #16: 15-draft-xie-bier-ipv6-mvpn-00 10minJingrong Xie Jingrong(Huawei): Request feedback Greg: Let's work on problem statement draft and will comeback to this.