BESS WG notes  Author: John Scudder  Chairs: Stephane Litkoski and Matthew Bocci  15:50 meeting start    Chairs presenting, welcome new chairs!   Working group status ================== John Scudder: tunnel-encap status is fairly close to being advanced. [context lost due to etherpad hang :-( ] How many think it should be adopted?  (around 3)  How many think it shouldn't be adopted?  (none) (status update 3 slide) evpn-inter-subnet-forwarding Ali Sajassi: Mea culpa, I was supposed to update it, haven't yet, it's important. Ali Sajassi: draft-ietf-bess-evpn-trill -- did it around 5 years ago, interest seems to have dwindled, not going to revise. draft-ietf-bess-mvpn-pe-ce -- park? progress?  ... it will be parked draft-ietf-bess-virtual-pe -- park? progress? ... it will be parked Adrian Farrel: are you making the decisions in the room? on the list? Matthew Bocci: we'll confirm on the list, think of what we say in the room as a proposal to be taken to the list Status for: draft-ietf-bess-l3vpn-yang draft-ietf-bess-l2vpn-yang Himanshu Shah: L2VPN update. (see slides, requests WGLC) Jeff Haas: problem with policy draft and l3vpn is there is so much variability between vendors. Punted out of module. Stephane Litkowski: can't you put in some very basic functionality? Jeff Haas: isn't not just VRF properties it's policy algebra. Himanshu Shah: we don't want to predicate our drafts on the policy doc. Jeffrey Zhang: draft-ietf-bess-evpn-bum-procedure-updates progress has been made. Adrian Farrel: draft-ietf-bess-datacenter-gateway is in implementation stage. Linked to SPRING draft that explains how pieces fit together. "Getting there". Adrian Farrel: draft-ietf-bess-nsh-bgp-control-plane is fairly stable, dependent on mpls sfc, at implementing/getting stability stage. Adrian Farrel:  draft-ietf-bess-service-chaining (not an author, but have read) -- "I think it's in the field" and should be moved to some form of closure. Maybe get some of the people who are using it to speak up? Andy Malis on "MPLS/PALS WG update on TCP MD5 deprecation for LDP": (see slides, come to MPLS meeting on Thursday) Alvaro, AD: At today's Routing Area chairs' lunch, we discussed this topic. We believe many times we don't implement because of operational issues. We are starting an initiative to create templates for Security Considerations, so we can have common language agreed w/in the area and w/ the Sec ADs. For example, agreed understanding of "a domain". You are invited to participate. These templates don't remove responsibility for writing a good Security Considerations, but are intended to help.  draft-zzhang-bess-mvpn-evpn-aggregation-label-00: Jeffrey Zhang, 10min ============================================================ Ali Sajassi: inter-as option b -- global labels need to be translated, right? how to coordinate?  Jeffrey: they either get coordinated across your entire network, or you can do it at the border routers.  Ali: do you expect the controller to do that?  Jeffrey: you could have a controller for each provider. Not much different from assignment of route targets. Ali: if you have the common pool capability, you could extend the concept to underlay as well, right? But that's for a different discussion.  Jeffrey: yes, they're different issues.  Stephane: do you have customers with these scaling issues? Jeffrey: no. (anticipate it could happen, for reasons)  Ali: one other thing, typically customers use non-aggregated, even though it increases state in core, number of s-pmsi or i-pmsi tunnels are not that large. Have you actually seen a scaling issue that makes customers do aggregation? Jeffrey: no. probably because they don't have that scale yet, or can tolerate. but bier is an aggregation tunnel, so it will drive the issue. Stephane: BIER should try to solve scaling issues we have. But you're saying it introduces new scaling issues. So why should we move to BIER?  Jeffrey: the issue isn't caused by BIER, it's *exposed* by BIER.  Ice: aggregation over single tree gives you less state. BIER lets you cut state but have no flooding. Ali: with BIER you don't need aggregation because you don't have state in core. Jeffrey: I don't think that's what Ice was saying. Ali: that was my own perspective. Stephane/chair: cutting the discussion. draft-ietf-bess-mvpn-expl-track-08: Jeffrey Zhang, 15min =============================================== (?) from Huawei: benefit of less routes and less signaling overhead, I'm more concerned about join latency it brings to BIER. My main concern is if it can be useful when two segmented areas both use BIER, can this mechanism also [be] useful?  Jeffrey: (?): Segmented MVPN, two areas, both with BIER. Jeffrey: I'm not sure if it's relevant, but this solution does work with BIER. (?): Mentioned in BIER MVPN draft that it doesn't work with segmented MVPN. Jeffrey: we'll need to discuss that in more detail. It *should* work. That should have been covered. At the mic we don't have time to get to the bottom, let's talk offline. Stephane/chair: already passed WGLC, shepherd review done. I'd like to do a 1 week WGLC on the changes. Jeffrey mentioned the normative dependence of BIER MVPN on this. As far as we know there's no implementation. Unfortunately based on BESS policy we can't progress the doc. But, that'll block the BIER doc.  Ali: are you making this call per draft?  Stephane: it's case-by-case. We've discussed multiple options. This solution seems to be the simplest one. Martin V (Incoming AD): for clarification, the policy allows the WG to decide, so this isn't exactly a special case. Stephane: we'll take it to the list.      draft-ietf-bess-evpn-yang-05: Patrice Brissette, 5min ========================================== (done, ready for WGLC) No discussion. draft-ietf-bess-evpn-igmp-mld-proxy-01: Ali Sajassi, 5min =============================================== (done, ready for WGLC) Jorge Rabadan: Inconsistency in draft. (something) is sent always by PE even for local source? Ali: for local source we'll use s-pmsi. (?) will be used only for join. Jorge: If you have a PE that has rcvr and src in same bcast domain, do you still send the (?) rt? Ali: no. Jorge: you have one section that says yes and one that says no. Ali: send text. Jorge: I will Stephane/chair: please fix before WGLC starts. Jorge: second comment, I sent a list of comments to the list a long time ago. One of my comments that wasn't addressed was to simplify IGMP sync procedure. Lots of cases where you don't need whole leaf procedure, esp if you have receivers directly attached to PE, or if CE supports proxy. You can remove S,G from the MFIB. Makes leaf sync route optional for those cases. Ali: when rcvs and srcs and confined to multihoming PE? Jorge: in some cases the leaf sync route is not needed. Ali: please send text. Jorge: I will re-send. Mankamana from Cisco: will it not be difficult to have selective procedures when and when not to sync? Maybe we should discuss offline. Ali: let's look at the cases and evaluate whether we get valuable simplification from it. Stephane/chair: please discuss offline. draft-ietf-bess-evpn-vpls-seamless-integ-01: Ali Sajassi, 5min ================================================== No discussion. draft-ietf-bess-evpn-df-election-framework-00: Satya Mohanty and Jorge Rabadan, 10min ========================================================================== (done, merges two existing docs, request WGLC) Stephane/chair: we would like to proceed to WGLC ASAP, many other drafts depend on it, we need to finalize. Thanks for the work. draft-sajassi-bess-evpn-per-mcast-flow-df-election-00 ============================================ Ali Sajassi and Mankamana Mishra, 10min Stephane/individual: why pick a new type and not a new capability w/in the existing type?   Ali: It modifies the hash, so it's a new DF type.   Stephane: related to DF election framework draft, I read it quickly, don't see we have a clear definition what's a type, what's a capability.   Ali: true. DF capability works across DF types, DF type is XOR -- either this or that. Do we want to add that to the draft?   Jorge: yeah, we can clarify that. Other aspect is DF type defines the algorithm to choose the DF. Capability on its own is not enough.   Ali: capability works in conjunction with type, type can work w/o capability. Capability improves type.   draft-sajassi-bess-evpn-fast-df-recovery-01: Ali Sajassi, 5min ================================================= (done, request WGLC) draft-sajassi-bess-evpn-fxc-03: Ali Sajassi, 5min ======================================= (done, request WGLC) draft-sajassi-bess-evpn-virtual-eth-segment-03: Ali Sajassi, 5min ==================================================== (done, request WGLC) Stephane/individual: useful work Stephane/chair: you're requesting a lot of WG adoptions. Do you have a priority order? Ali: yes, I'll send it to you. draft-boutros-bess-evpn-geneve-02: Jorge Rabadan, 10min Jorge presenting on Sami's behalf slide 4 Ali: clarification, BUM bit purpose is described in EVPN-overlay, in RFC Ed queue. We can reference that.  Jorge: fair enough. draft-brissette-bess-evpn-mh-pa-01: Patrice Brissette, 5min Jorge: are you saying that you only need ES routes, and not the EAD routes, or is that just my interpretation? Patrice: can work just for L3 as well. Jorge: but for L2 you do need EAD routes? Patrice: yes Jorge: it's confusing. Jorge: don't we need a new ____ type? Patrice: IMO it's just a new load-balancing mode. Jorge: ... Patrice: ... Jorje: it should work. What about hRW and DF election framework presented earlier? Patrice: if your q is to add a new type to that framework, I'll take a look Ali: between capability and type, I think in this situation it's a bit of a wash. I'd lean toward the capability. The functionality requires is pretty minor, not a new algorithm, can work w/ VLAN carving, HRW, preference, we just want to do it on a per-link basis. Jorge: I agree. On a PE basis, no change. ACDF capability must not be turned on. Patrice: want me to clarify? Jorje: yes, read the framework draft Patrice: Let me go through the DF framework  Jorge: you have a section on the IRB, right?  Patrice: should we take it offline? Stephane: go ahead and discuss Jorge: You want to drive IRB based on ES? Seems weird if not wrong. Patrice: Yes Ali: I see where you're going. Multiple ESes for a single BD. Let's take it offline. Patrice: ok Ali: did you say that we need to have the DF AC off? Or preference? Jorge: if you have the AC DF on, you can't rerun the election. Ali: It's AND of both. You configure the VLAN on both. This is on a port basis. Whenever the port becomes active and the VLAN is active, that VLAN is on. Jorge: If one is active, and the other goes down, we don't want to switch. Ali: we can take it offline draft-mohanty-bess-evpn-bum-opt-00: Satya Mohanty and Sandy Breeze, 8min ================================================================= Sandy presenting Ali: I'm concerned regarding bang/buck with this proposal. In the final solution, for vast majority of deployment, multihoming is dual-homing. No gain with dual-homing? Sandy: correct Ali: if we have multihoming, if we have more than one CE multihomed for a given bcast domain, the number of CEs is 1-2 order of magnitude higher than PEs Sandy: this slide is my requirements Ali: if you have many CEs, DF election tries to be fair, spread election across CEs. You'll end up with all PEs becoming DF. Sandy: my specific problem isn't well-described by this diagram. My PE topo is NVE [...missed...]. Attachment circuit is VXLAN, one Ethernet segment : 1 ESI. So I'd get good load-balancing. Between CEs, connected to a ToR. Ali: your PEs are NVE running VXLAN, your CEs connect to them. How many CEs for a given VNI? Sandy: Segment tied to one L2 VNI in each case. Ali: only one? Sandy: what you don't see is [...missed...] Ali: there many be many CEs. If for the same segment there are many CEs, all your PEs will become DF.  Sandy: the diagram doesn't represent my problem. Ali: we can take it offline. I'm struggling to understand the problem. I'd love for you to go over it with me. Sandy: we know hashing is per Ethernet segment. In our VXLAN deployment we have [...missed...]. We will never have more than one ethernet segment per ESI.  Ali: if you have 1:1 mapping, no MAC lookup needed. Why not use VPWS? Sandy: for tunnel endpoints downstream of PE, we have many:1 per segment. Ali: in that case it boils down to 1 CE per bcast domain. Because VNI is bcast domain. 1 segment per bcast domain. Sandy: 1 segment per ESI. Ali: ESI or VNI. Sandy: same thing in my world. Ali: seems like limited applicability, we can talk about your situation. If there's single-homing, that PE's going to drop traffic, period. All the optimization will go out the door. Sandy: I know. Satya: I want to clarify the figure isn't wrong, even if you take another CE and that CE is mulithomed to the same PEs. Ali: for the baseline I agree, for 7432 it's the same. For the new DF framework it'll be different. [back and forth between Satya, Ali, Wen, some not into mic, not captured] Wen: Even the DF election algorithms, 7432 won't end up with the same PE as the DF, because if we have two different ESI ethernet segments, DF election is based on VLAN/BD so for different BDs... Ali: it's based on a single BD. that's the context. Jorge: seems more informational than standards track. Robin: four years ago in London we proposed another draft, in L2VPN WG multicst state advertisement, similar use cases. Stephane: which draft? Robin: I'll send it to the mailing list. [...missed...] Ali: There are some similarities, but they're different things. The proposal Robin is talking about is for optimizing on ingress. v0 of EVPN draft (the individual draft) it was mentioned there and removed. Sandy is talking about doing it on the egress. It's different things for different scenarios. draft-mohanty-bess-ebgp-dmz-00: Satya Mohanty,  12min ================================================ Jeff T: I don't think you need to create knobs. You need to update the draft. We brought up that the attribute needs to be non-transitive. Let's update, take it to IDR, be done. Satya: that doesn't talk about cumulative. Jeff T: Yes it does, and it's in IDR anyway. Jeff H: the link bandwidth draft this started from, you guys revived, great. It's permissible for nontransitive extended communities for you to re-originate it. The interesting caveat is that we (Juniper) deployed transitive version and we don't use the nontransitive version. We wouldn't interoperate properly. We were planning to approach the authors. Furthermore we implement this and will release it soon. From our perspective it's a local behavior, but offer the caveat link-bandwidth is like many "magic" communities this group tends to spit out, you expect to have just one of them. What do you do if you have multiple link bandwidth communities in a received route? Satya: point I take is don't do away with knobs, make link bandwidth transitive? Satya: how will we distinguish. I receive an attribute, modify and send. Now I don't know if it came that way or if I modified it. Jeff: it's an internal detail. Satya: the receiving guy won't know who changed it. Jeff: how would you NOT know? Ali: this is a small increment to link-bandwidth. the middle hop that gets the link bandwidth sums them, in the transitive case. that wasn't mentioned in the previous draft, we had two choices, add a section to the prev draft on have a new one. this was the easier option. Jeff: nothing stopping you with the core link bandwidth draft with treating it as a re-origination, which makes it effectively transitive. This is similar to bgp no_export, it's the expected behavior. For procedure, nothing new needed. For wanting transitive behavior, we already implemented, accumulation behavior is reasonable to document and we'd be happy to join you on the draft since we already implement. 17:12 Stephane/chair: end of session, will get on with WGLC, WG adoption ASAP