IETF 94, Yokohama, Japan BIER WG Agenda Fri, November 6, 2015, 09:00 - 11:00 Room 413 GregS: meeting starting. Welcome, Notewell, Agenda bash Chairs 5 min Note well applies. draft-ietf-bier-isis-extensions-01 TonyP 5 min Tony P presenting. GregS: what is your feeling on how matyre this is, when cal LC it? Tony: there is a minor thing to split on the architecture line., GregS: architecture draft likely will stay open for a long time. Tony: no intention to rush it. GregS: Alia mentioned not wanting to run WGs forever. Tony: ... GregS: it used to be a requireement. Tony: you cannot LC it before you have an implementation. GregS: anyone paid attention to this document in the room? draft-wijnands-bier-mld-lan-election-00 Ice Wijnands 10 min Ice presenting. GregS: this is a problem, although not convinced that this is the source problem. It should be membership triggered. Whatever the control plane is, it should select A or B Ice: only if you have S,G. GregS: how those two routers know ..... They both can start from the same domain. Ice: therefore the need for DF election. GregS: this seems to be an BIER requirement and issue, what about the mLDP? Ice: MLDP is not used that way. Stig: We should do it in PIM because it is generic problem, and extension to IGMP. We have experience with DR election and load balancing. We have the expertise on working on this problem. Jeffrey Zhang/Juniper: agree on PIM. There are also additional proposale, PIM DR procedure, and those could be merged. Ice: wouldn;t it then put tre requirement to run PIM? Jeffrey: proposed PIM could be ..... just enhance this and then require using it as generic announcements. Stig: It is not specifically PIM but a generic problem. GregS: is that looking at rebuilding the mechanisms fdor runnign the interfaces? Stig: it is about how you gracefully switch to another DR. There is also a solution for load balancing, different DRs for different groups. TonyP: similar is being worked on EVPN. Non-revertive bits, etc. That would be a good place look at. Sandy/ZTE: poer group DF election - hoiw does that work per group? Ice:L group based election needs those procedures specifired. Sandy: Is that IGMP hello> IceL yes. Weiguo/Huawei: for the access scenario, active/stby and actv/actv solution - is it only for actv/stby, or for actv/actv too? Ice: we haven;t specified the provcedurers yet. GregS: have you red the drafr? This is a problem statement, not a solution now. Ice: we look at the procedures and will come with the solution. GregS: and that will be a common solutins. TonyP: this is not homenet, please do not invent protocols on the mike. Toerless: there may be IGMP on one side and PIM on the other, will this be adressed? IceL yes. Ilya Vershkov: will snooping procedures change? Ice: snooping will be affected, yes. GregS: anyone needs any feeling that this work needs to be placed here? Any has objections to move it to PIM? GregS: I like to delegate this ti PIM. Stig: the draft can be presented in both groups, and please talk to PIM WG. GregS: that is a good idea if it gets more people across boundaries. Ice: who was in PIM yesterday? GregS: there is some overlap already. GregS: Stig - do you see this as an item to adopt? Stig: there is little content in the document, we cannot discuss adoption yet. There was interest in the room, I don;t see a problem adopting it later. GregS:.... Stig: there is one drafts that is abiout to be adopted, also load balancing drafts too. GregS: thiose all are the extensions. Ice: if you modify IGMP, and make that look similar to what PIM does, we can reuse the mechjanisms. GegS: Do we have an AD here? Who is assigned AD for this? Alia: Alvaro. I would like to focus on essentials. TonyP: They need to coordinate. Dave Allan: trill has teh same issue. GregS: does trill have the active efforto to solve it? We need to control this problem. We need to consolidate work. JeffreyZ: this is different from the trill. Alia: I can take a look at the draft and talk to Alvaro. If it has more generic applicability than BIER it should be in PIM. This does not seem to be that central. Ice: does anyone feel that this should not be done in IGMP? Speak now or stay silent forever. GregS: no objections raised on this. draft-mirsky-bier-path-mtu-discovery-00 Greg Mirsky 10 min GregM presenting. Loa Andersson: hasn't this problem solved in IPv4 multicast? GregM: there is no mechanisms in the ipv4 multicast a mechanism to indicate which nodes to respond. Toerless: that is the reason that it was recommended to use the minimum size frames. I do not see this being very different in BIER. GregM: using BIER bitstring we can explicitely specify the BFERs that we are we are targetting and thus limit which nodes to respond. That reduces the number of PMTUD responses in the given subdomain. Toerless: is this OAM thing only, or coupled to application? Would it ever do fragmentation? GregM: currently BIER for MPLS does not do fragmentation, and this is for OAM. Toerless: I do not believe that PMTUD is defined only for OAM. Erik Nordmark: IPv4 has noting because there are no ICMP error resturned for errors. If I recall there is packet too big ro IPv6. The question whether this is OAM only or application is intersting. Loa Andersson: If you you send to E, F, and G only, will that resolve in different MTU size ithan if you sent ot De, E, F. G? GregM: yes. Loa: then you need to keep state of where it was sent and who rersponded. Greg: that is per subdomain. Loa: the for each subdomain you need to tract MTU size? GregM: yes. We may select the minimum of all MTU that we discovered. Loa: I think you will be forced to do that if yiu have non-compatible BFR in the path. GregM: noncompatible would be the one that does not support this extention. There should be some heuristics on decreasing the proe size. Andrew Dolganov. You can do this per channel. This would be used either base don discovery, or base don the channels that you distribyute. TonyP: would we nned to standartize this? Andrew: we would standardize the procedure, but not the mechanisms how to do it specifically. GregM: if we have two distribution trees, we run it per tree and the minimum will be lowest of them. Loa: I am fine with that. Toerless: we havent done that for OAM in other networks, the requirements doecument does not talk about this. Would be noce to write up the need and use cases for it. GregM: BIER provides instrumentation that allows to do it in a n effective way. GregS: this is topology MTU, not really a path MTU. All the MTU mechanisms that I am aware they are based on the application, thisa seems to be standalone to the network. GregM: I do recall in some other encapsulations - VXLAN, maybe SFC - they do path discovery. draft-chh-bier-bier-yang-01 Ran Chen 15 min Ran presenting. TonyP: would like some discipline - has this been run through the validation tool? Alia - do you think this needs YANG doctor assigned? Alia: yoiu can send to YANG doctors and check how mature it is, there is also a Sunday YANG editin session, please bring it there. TonyP: BIER is AF -independent and model will need to be aligned to that. Ice: we associate BFR id with loopback, and you need to lookup that in particular table. TonyP: I was referring to the subdomain AF independence. Ice: if you configure which AF you support. TonyP: subdomain can carry multiple AFs. Ice: should it be the other way around? TonyP: we can carry MPLS frames too. this does not seem to be deeply looked at. ?/ZTE: we defined different BFR per AF?? TonyP: but the label will be the same, and I do not see a need for specifying that. We are inventing protocol on the mike, it does not seem that this model has been depply reviewed. TonyP: who wants to work on YANG models, people, this is your career. :-) Alia: given that BIER is a new technology and how it progresses, and given the progressing of YANG models, it is good to make shure that model mathches the architecture. Please review it. Toerless: it is even more important as there is a lot more conifguration that needs to be pused. GregS: who things this needs to be adopted. Will take to the list. draft-chen-pce-bier-00 Ran Chen draft-eckert-bier-te-arch-02 Toerless Eckert 10 min Toerless presenting. Ice: in TE there is no set id, there is subdomain and bit positions. Toerless: there is, I will explain that in later slides. Ice: it seems that you are mixing semantich of SPF BIER and TE that are not compatible. An example of set ids .... if you use that same BFR ID for TE, you can reach that node if the bit position is the same on all nodes along the path, and you need to engineer for that. Toerless: I do not get that. Ice: BFR ID is transalted into a bit position. Al the nodes in the path do not need to use the same bit? You need to configure on each node a set id for a particular next hop. But tha it is not how it is configured, it is automatically generated. You are mixing set id and subdomain. Toerless: the intention was to make it easy for flow overlay solution. Ice: as it is dynamically generated and configured, you should use subdomains for it. ToerlessL in normal BIER, I am not getting an ideal forwarding. TonyP/hat off: I do not see anything wrong with using different subdomains. Mixing the semantics in the same domain - it iwll make the cost of hardware to go exponentially. Toerless: there would be two labels bound for the sma subdomain, TonyP: but then you reinvent subdomains. We have discussed this before. It is a distinguising of the servite taht you ruin in the subdomain. Toerless: I am open to have BIER and BIER-TE in the same domain. Let's see whether there are technical reasons that would preclude this to work. TonyP: I do not think that you can mix TE and normal BIER semantics. Toerless: the simple case - subdomain has BIER or BIER-TE only. Flow overlay cannot deal with one parameter in a simple way. I am not sure there is anythign that would break. Ice: BRF ID is just a value, but you need to know which set id it is. Toerless: that is an interpretation. I would like to take whatever I can get out of IGP. Sandy: You divide BIER domain into several areas - do they directly map to IGP areas? Toerless: there is no necessary relationship, they could match but that is not required. Sandy: usually we cannot use IGP area directly? ?? Toerless: that seems to be relaed to the management aspects. If you have an IGP area, that would be a similar approach in the area in BIER-TE. draft-zhang-bier-designed-routing-00 Sandy Zhang 10 min Sandy presenting. TonyP: it is cute but unfortunately does not work. You cannot express the DAG via a topological sort. This will lead to packet replication. We can keep it on the email, or you can implement and experiment with it. draft-wang-bier-vxlan-use-case-00 Linda Wang 15 min Linda presenting. Toerless: I do not undesstttand teh use cases. And also uncertain about the scalability. DC has millions of VMs and 100000s of identifiers, and some use cases that would indicate the scale numbers would be needed. If this is in the context on the unknown traffic, then flooding may be good enough. Linda: thank you,. Jeffrey Zhang/Juniper: today VXLAN can use PIM to do this functionality. Why cannot we just BIERinstead of PIM trees, everything else stays the same? No changes would be needed in this case neither in BIEr, nnor in PIM. Linda: BIER could also be used for connecting other NVEs. ??? This seems to be a discussion about PIM and BIER positioning. Jeffrey: you do not run PIM at all, just use the groups, and use BOER for forwarding. TonyP: the membership discovery is overlay problem, and trying to put it in BIER layer will make it melt, there will be changes flooded for every VM membership change. draft-want-bier-lite-ospf-extensions-00 Linda Wang Linda presenting. GregS: any comments? TonyP: who has read the draft? Selected few. Ice/Cisco: you need to be careful if you introduce another data plane encapsulation for BIER as it is expensive to implement across platforms. Not certain whether MPLS could not solve this problem. We have discussed this before and I am not convinced that we need to work on this. GregS: this particular deployment does not support MPLS. What is missing in label encapsulation that could be used here? We just want an ethertype and not using MPLS as such here. Ice: this will likely require replicating a lot of forwarding code that is already there. Pat Thaler/Broadcom & IEEE 802 vice chair. Before we do this we need to show this to IEEE 802 and see how they feel about it, I would request to send a liaison to IEEE 802. GregS: encourage to read the document and see whether the use case is good. Will keep the discussion on the list, and please read and review the document. GregS: Encourage reading on what is there and please discuss. End of meeting.