IETF 108 Singapore BIER WG Minutes November 21, 2019 draft-zwzw-bier-prefix-redistribute-03 Sandy This draft has been presented 3 times and would like adoption. Jingrong: ItÕs useful. BFR-id imported from outside the area with summary route. This should be the prefix because RFC8401 requires that Bier info required with host prefix but bier architecture says bier info should be advertised by ip address (host prefix). Sandy: When the host prefix can be advertised by different areas 1 by 1 the host prefix and BFR-id can be advertised at same time. But if we need to use default or summarized route across many areas need to use a new method so we propose new extension point so two solutions can be used together. If you only advertised prefix 1by1 you can use the existing advertisement but if you want to use summarized or default route you must use a new method otherwise you canÕt carry the BFR- ids. Hooman: this is an interesting problem. CanÕt understand the summarized or default route. Are you proposing the ABR track the BFRs? Or BFIRs? On one area? And create TLV with all BFR-ids and send to the second area? How to propose summary route will advertise all BFR-ids in core area into area 1 or 2. You would need to advertise an entire list of BFR-ids. Sandy: would like to merge all areas into one bier domain. R3 and R4 donÕt need to be the BFIR/BFER. Just BFR in the forwarding plane. We use advertisement for prefix redistribute into core area. Just advertise summary route into the core network. Just a control plane IGP advertisement, an extension to IGP. Homman: as long as summary and BFR-id in the access areas are flat. If you have BFR-ids that are very sequential and flat in one area it will work because you have the BFR-id range. If BFR-ids are not flat you will have to go one by one. That would be a large packet going back and forth. Sandy: ItÕs just a configuration/administration requirement. If you can configure with same range in one area it can be advertised with only a few summaries. It depends upon your configuration of the BFR-id. Most continuous BFR-ids is the most efficient way. Jingrong: I assume for R3 and R4 it should support bier forwarding. R3 should advertise its own BFR-id and its own bier encapsulation, bier label with imported BFR-ids into the area. Sandy: if we build the whole network into one bier domain just flood the extension in the network. Jingrong: it has to advertise the bier encapsulation sub TLV. That sub-tlv including the sub-tlv and sub sub tlv is the same as rfc8401. Sub tlv should use the same host prefix as the sub sub tlv. Sandy: if R3 would like to advertise multiple prefix you should carry the associated ids of BFR routes. If R3 would like to advertise multiple prefix in one advertisement such as summary you should carry the associated BFR-ids Ice: the summarization is only an optimization. You can flood them through and they are 1:1. Its only 256 updates anyway. But if you do summarized that ABR will put its own loopback as the BFR-id. ItÕs not complicated. Stig: do you allow sub sub tlv with the bier sub sub tlvs. Example: mtu. If you do mtu sub sub tlv for bier prefixes it would be helpful to do so here as well. It may be helpful to use the current sub sub tlvÕs to be used with this. Sandy: MTU extension is welcomed. Future version. Jingrong: summary route may work in some cases, need to update bier architecture because it requires ip address. Sandy: the IGP usually uses summarized ip prefix. Jingrong: I will point this out on the list. Greg: majority of the room read the draft. All readers think it should be adopted. Dozen or so. Bier pim signaling v8 Š Hooman Updated text for ECMP and pim signaling join attribute AF Next steps: solutions considered complete. Wglc? WeÕve done wglc on this draft twice. Greg: 10 or so people have read it and feel it is ready. Wglc will be accelerated. Stig: it should be good from pim perspective. Will send email to pim wg. Will do last call together. Mankamana: will it be two weeks last call? Greg: no it will be accelerated. mldp signaling over bier Š Hooman Trying to extend any legacy multicast protocol over a bier core w/o affecting the access legacy multicast protocols. Received some comments to clarify certain aspects of the draft. Asking for wg adoption. Greg: who has read the draft 8. Who thinks itÕs ready: 8 Draft-venaas-pim-igmp-mld-extension Š Stig Bier extension to igmp/mld as an overlay. Good to identify the bier ingress routers. Who the join came from. Extend igmp/mld messages. DonÕt want to make changes to the protocols. Draft probably belongs in the pim wg since it defines an igmp/mld extension and registry. Greg: in other examples we brought the work here and completed the protocol work in the protocol groups. Same can be done here. Stig: we think it is good to have an extension type in case there may be multiple extensions for multiple purposes. Stig: may have one extension/registry document in pimwg on why we need to extend igmp/mld. And then a separate document on the use of it in bierwg. Toerless: the world pim should be removed from the title Stig: it could be a pim wg document Toerless: we still have this with bier, why to do the overlay vs pim. When would this be preferable over pim. Every edge router doing pim also supports igmp. Greg: if you have host connected networks. You would do pim if connecting pim domains otherwise its religion. If you are just going to use it as signaling independent of what your edges are then not certain why you would pick one over the other. Toerless: more natural in pim to have the concept of RP. This one is helpful if I want to kill of pim and simply to ssm. If there is any chance to give guidance. pim or igmp. We are giving so many alternatives and want to make bier successful. CanÕt implement everything at once. Give guidance. Stig: running bier to the edges you donÕt need a pim implementation on the routers. Draft-venaas-bier-pfm-sd-00 Š Stig We have this flooding source info for pim today and would be nice to work with bier as well. This could be useful for pim overlay as well. New PFM BIER ingress TLV. Similar to BSR, no RP needed. If you have bier in the middle between two pim domains and make use of pfm. You need pfm messages to pass through the bier domain. The minimum functionality is for the messages to be encap through bier. But also add this new tlv could be used for bier routers to decide where to send the pim joins. To help decide who is closest to the source. Could come up with some sort of hashing. Sandy: works for bier overlay. Used to collect the (S, G) info across the bier domain, right? Stig: if you have pim and have bier in the middle and deploying pim signaling over the bier and then this extension can be used for the pim signaling to decide where to send the joins. But also if you have deployed pfm in pim to begin with and want bier in the middle you need this for pfm to function. Also if you deploy pim signaling overlay this can help you to determine where to send the joins, what the bier ingress routers should be. Sandy: you should send messages from BFIR nearest to the source. What destination in the bier header? Stig: we want the receiver side router to determine which way to send joins. Sent all the bier routers. Set all the bits. Alvaro: You getting the metric from IGP in the bier domain? Stig: yes. TLVÕs are not modified as you go through the bier domain. Alvaro: you are going through multiple areas that have multiple metrics and routing protocols. If you were to pass that and use the metric inside the bier domain it may be weird. ThereÕs functionality in BGP that tries to do the same thing. Accumulated ip metric. Closest isnÕt always going to be who gave me the route. Take a look at that. Sandy: if metric is going to be from many ways, maybe we can add a section in the draft. Stig: one thing to consider just have a simple draft that describes the pim functionality and the metric can be something addition if we feel itÕs useful. Stig: please read the draft and provide feedback. draft-nainar-bier-flex-algo-00 Š Mankamana How to use flex algo in the bier domain. More details at next ietf. Hooman: this is something we definitely need to work on in the bier wg. Need more thinking. Tony: how the algorithms are managed are not that important. Ice: the lable just describes the bift-id. Sandy: bier use igp as underlay. Just can use these igp extensions to achieve flex algo. DonÕt understand if not more should be doing bier. Mankamana: igp extension will give. Sandy: there will be a mapping. Greg: 6 have read the draft and all six feels it should be adopted. draft-ietf-bier-evpn-02 Jorge Jeffrey has presented this a couple of times. Request feedback Ready for wglc Mankamana: did you take this to bess as well? Good idea. Sandy: we will inherit all the encapsulation types. Only see 3 tunnel types, vxlan, geneve, gre but there are many tunnel types. Will you expand draft to include all of the tunnels? Jorge: we are interested in the ip destination address. Sandy: the main idea is to use the tunnel encap for the data packet. Want to use tunnel encap for data packet. Many tunnel encaps can be used. If we only specify 3 types of tunnels after the bier header. Jorge: this is mainly done work in bess. Ip overlay tunnels. These are the 3 main tunnel types specified there. This draft just focuses on those. Alvaro: the tlv has a bunch of other stuff you donÕt care about. Eventually please write what should happen when you receive a tlv when a tunnel type is not support. Greg: 5 have read. 5 support. Bier-te-arch - Toerless Wglc since 104 More reviews welcome so we can finish the last call. Greg: please review. We will restart the last call. draft-ietf-bier-ipv6-requirements Š Mike Update requirement section since last IETF. During this process pros/cons wording have been removed. There are two draft being worked on. All reference to SRv6 would be removed from document Solution summary would be moved to appendix. Review expected from WG and feedback would be helpful to make document proper. Currently 12 requirement discussed, more discussion in list. Tony sent detail email about 2, 3, and 9. 4, 3, 2, 11 needs discussion. It does not require fragmentation. It changes architecture. We would need more discussion. Jumping multiple hop is like tunneling technology. BIER is layer 2.5 solution. It has not been made clear in RFC BIER. BIER RFC allows fragmentation. Jingrong: there are many operators where number of end host are really in high numbers. Network is IPv6 ready, it might be good have BIER for those network. There are some limitation in this draft. ItÕs not ready for WGLC yet. Requires some more work before it gets ready. draft-xie-bier-ipv6-encapsulation Š Liang Have improved the draft a lot. Hooman Š ipv6 is a hot topic. Sooner or later we need to have one solution. DonÕt make unicast mistakes. Very close to bier in 6 draft that is going on. Maybe combine drafts? Security aspect Š that is very interesting. For bier do we want to entertain all the v6 quirks including security? Ipsec, etc will come into play. Mike Š Need to decide if we entertain the two primary solutions drafts along with requirements draft or wait until requirements draft is wglc. Really two drafts primarily worked on, should consider adopting both and later submit one draft to iesg. Ice - doing this in extension header doesnÕt add value. Bier in 6 removes the extension header. Too early to ask for adoption, just want one solution moving forward. We could adopt two at first but probably better to adopt one to begin. Greg Š Merging beforehand would make more sense but nothing preventing us from adopting two drafts. Aijun Wang Š China Telecom. Extension headers has accelerated adoption of ipv6 so itÕs a good approach. Liang GengŠ DA field is for bier. We could discuss oam for bier offline. Tony Š bier has a full oam layer. ItÕs a 2.5 layer solution. And now you are extending to a L3 tunneling technology and extending it on the fly. You are trying to replace it with ipv6 oam. Needs an architecture document. Jingrong Š agree with Hooman. Converging two solutions is possible. Only some differences between the two solutions. Greg: encourage constructive comments. Show us how itÕs helpful. Adjourn