Minutes IETF101: bess
minutes-101-bess-00

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