Minutes of BESS meetings during IETF 91

=============== Wednesday, 0900-1130 =========================

Meetecho recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_BESS&chapter=chapter_0

* Administrivia and intro, chairs, 10'

Loa: Not necessary to respin just to change the name
Thomas(chair): We'll ask for all documents to be renamed as -bess, whenever they're to be
 updated
Loa: Oh, OK
Dave Allan: clarification. L2VPN drafts that have passed LC, what is status in BESS? some was not assigned shepherd yet.
Thomas(chair): business as usual/ no draft naming change, will find shepherd for those passed WG LC
Andrew: Will datatracker show linkages between old and new name documents?
Thomas(chair): Yes
Ram Krishnan: Connection of federated controllers, in-scope or out?
Thomas: Maybe. Do you have a specific proposal? Case-by-case basis. If it involves
 the BGP VPN control plane, probably in-scope.

* draft-ietf-bess-vpls-multihoming, Senad 5' including questions

[9:14 begins]
- Had to change BGP route selection algo to allow for active/passive PE selection, to
  mitigate potential for loops.
- In 2013 deployments exposed use cases which caused route oscillations, problems with
  inter-AS connectivity. Had to modify BGP selection algo again.
- Split into path selection and DF election processes. Fixed the problem.
- Ready for last call.
(The above is pretty much on the slide)
No Q/C

* draft-dolganow-l3vpn-mvpn-expl-track  Andrew Dolganow, 10' including questions
[9:17 - 9:26]
Thomas(chair): IPR contribution done virtually the same day as the contribution, please follow
 their example.
Thomas(chair): Please continue list discussion.
No Q/C

* draft-morin-bess-mvpn-fast-failover, Robert, 10' including questions
[9:27 - 9:31]
Martin(chair): who has read it?
Martin(chair): authors, when you have done the merge, please advertise it on the list and
 solicit discussion
 
* draft-morin-bess-multicast-damping, Thomas, 10' including questions
[9:32 begins - 9:37 ends]
No Q/C

* draft-zhuang-l3vpn-yang-cfg-00, draft-zhuang-l2vpn-evpn-yang-cfg-00, draft-zhuang-l2vpn-yang-cfg-00, Zhenbin, 15'
[9:37 begins]
[9:51 QA ("Discussions" slide) ...]
Dean Bogdanovic: I'm in favor of simple models and then augmenting. All vendors will
 have to translate from IETF models to their proprietary models. So let's start
 simple. 
Jeff H: IDR hasn't chosen a specific BGP config. You chose zhdankin. Is it possible
 this work is premature -- should you wait until IDR chooses a BGP model? IDR
 currently has four different proposals. As a proof of concept this is good, but 
 maybe premature to progress. Otherwise you have to realize you may have to change
 your work after IDR chooses a model.
Sue Hares (IDR co-chair): I encourage Robin to continue. Operators have formed a
 group to provide requirements. I expect it will proceed rapidly. We will have 
 interims to move IDR to have a chosen model soon.  [Suggests BESS reviews IDR BGP model]
Dean B: Let us not rush a prototype to RFC though. It will be frustrating for 
 authors to have to revise their work repeatedly.
Adrian (AD): +1 to all that. Key word is "coordination". Everyone should assume
 their document will not be adopted but that their work will contribute to 
 exploring the solution space and coordinate with other authors.

* / extra time for discussing Yand datamodels for BESS, 10'
        
Thomas(chair): Interesting to see work starting on Yang, it's in our charter.
 However two points: first coordination is very important. Use Yang coordination
 mailing list. It's unlikely we'll adopt this work but it's very helpful to see
 early attempts, thank you.
Jim Uttaro: our approach is to drive Yang model from what's actually configured
 in our network. I see that you canvassed various providers, but I don't see them
 represented in draft.
Dean: This is the config model, not the service model. You need both. The service
 model would be responsive to AT&T.
[10:00]
Robin: Service model proposed in ONF. No appropriate group in IETF.
Jim: What vendor's configuration model did you start with?
Jeff H: The model is based off draft zhadankin, in turn based on cisco. Will require refinement based on reality.
Dean: Routing Yang mailing list not enough. Will also need FW filter, queue, etc.
 Currently on netmod. Base models all over, still a lack of coordination.
Adrian: Yes, Dean is right. IESG has been surprised by rate of arrival of Yang
 models for services. Aware coordination needed. Benoit and Adrian to come up 
 with a plan this week so that going forward there will be a place to talk about
 service models.
Thomas(chair): To address the last few points, it's true there will be a need for a common
 data model for L2VPNs. Details are too early to say. Will need to coordinate
 with PALS.
Andy Malis (PALS chair): This draft will also be presented at PALS at 1 p.m.
Andy Malis (personal opinion): The L2VPN section, divided into VPLS and VPWS,
 I'm not in favor of this split. As for moving Yang model into PALS or splitting
 it, I'm not in favor of that either. (Agreement from Jeff H.) Too much
 commonality, we should try to take advantage of it. As for what WG, it's not 
 that important, let's just get the model right.
 
* draft-rabadan-bess-evpn-ac-df-00, Jorge, 10' including questions
[10:06 - 10:13 QC]

Ali: you're going to keep a list of PEs on a per-VLAN basis, right?
Jorge: For EVPN
Ali: you're going to have a large list, up to 4k. That comes at some expense (number of AD routes),
 I would like to see that cost justified. With reference to use cases.
 One of the benefits of EVPN is auto-provisioning, auto auto auto. With this
 kind of thing, we'd have to monitor health of individual VLANs, takes away
 some of the auto.
Jorge: Need to keep track of each attachment circuit -- need to do this on 
 remote PEs anyway.
Ali: Not in the context of DF election. Procedures get more complex.
Jorge: We can discuss that.
Jorge: Yes, EVPN is about auto auto auto, but we also have to be able to address
 things we already have in deployed BGP multihoming solutions.
Ali: Simpler in EVPN "for certain reasons". ... we need to sync up, I will
 present scenarios on Friday.
Jorge: OK.
Thomas (as individual): We need to look at state cost, yes. But motivation to
 prevent blackholing is Very Valid.
[10:18]
Robin: (with reference to "solution for pbb-evpn" slide) [understand for E-VPN, but questions why a route is needed in the case of PBB-EVPN]
Jorge: <???>
Tapraj: for PBB-EVPN, why only ESI: can we use BMAC?   
Jorge: BMAC assignment in PBB-EVPN <something>.
Tapraj: 
Jorge: Generates more BGP routes, but can constrain scope with ES-import RT.
Tapraj: If I have that per VLAN route, creates more problems per route to be 
 imported.
<lost the thread of the conversation, sorry>
...
Tapraj: Ali's draft that he will present on Friday can also solve the problem.
Jorge: That's different, uses virtual ESI
Ali: Use cases are different
Ali: VLANs, not ACs
<...>
Ali: Again the point about per-VLAN service monitoring and use cases to drive
 the solution.
Jorge: The draft states two use cases. For instance, due to human error you
 keep a particular attachment circuit shut down, or MAC VRF down
<...>
Martin(chair): Please send an email to the list with these points.
Ali: I've done better, we have a draft to present on Friday that covers the
 use cases.
Jorge: EVPN procedure is completely compatible with existing EVPN. Local
 implementation decision.
 
Chairs: [follow up on Friday's session & mailing list]

* draft-mohanty-l2vpn-evpn-df-election, Satya, 10' including questions
[10:28 - 10:36]

Thomas (as individual): You didn't cover that if you introduce this new mechanism
 in an existing network there'll be a period of time where some PEs do one thing
 and some the other. You lose consistence of DF election.
Satya: There's a community used for transition.
Ali: One clarification, the two different proposals address two different things.
 In this one we keep list of PEs the same, we change the mod function with 
 [a hash?] function. By replacing it, upon failure and recovery, the VLANs
 on the non-impacted links don't get impacted. It minimizes/avoids service 
 disruption for those VLANs.
Dave Allan: When we did SBB-EVPN we had a different election, changed to
 ordinal to align with PBB. Had similar stability property, didn't spread load
 well for small N. Your algorithm preserves stability, how is it on load-spreading?
Satya: Took algorithm from web caching context, expect good load spreading.
Dave: Please send pointers to math. Especially curious with regard to small N.
Satya: Good for large N, don't know small, will send paper.
Thomas: Even with perfect random it's hard to be good for small N.

* draft-allan-l2vpn-mldp-evpn, Dave, 10' including questions
[10:40 - 10:46]

Ali: Shared tree means single tree shared by multiple VLANs or services. Why
 doesn't aggregating [collusive|exclusive?] tree work?
Dave: I think these concepts are well aligned. Let's chat.
Ali: OK.

* draft-hao-bess-inter-nvo3-vpn-optionc, Weiguo Hao, 10' including questions
[10:47 - 11:00]
(note on "control plane protocol (2)" slide, left-hand "step 3" is a typo,
actually step 1)

Ali: have you looked at existing inter-AS text in draft-ietf-bess-evpn-overlay ?
Weiguo: This is very different. Option-C is agnostic to applications.
Ali: It mentions that if VNI is locally-assigned diff between VxLAN and MPLS
 is underlay tunneling... (interrupted) ... can have two different tunnel
 types. Maybe we can chat offline? Find what elements are new?
Weiguo: OK.
Osama <I think>: When putting a separate IP address on DC side, do you 
 expect to have a separate IP address per tenant? Separate VRF per customer 
 on ASBR? And VRF per customer on NVE?
Lucy: Yeah
Osama: Don't need to limit VNI to 20 bits, doing the translation anyway.
 Limiting the VNI just complicates things.
Lucy: Agree
Wim H: You actually want to connect VxLAN domain using Option-C to an MPLS
 domain?
Lucy: Yes
Wim: You need a gateway for that, right? You have to do the mapping.
Weiguo: ASBR is that.
Wim: We have the means already.
Ali: Section 10 of EVPN overlay draft. If VNI is global need gateway, if 
 local (such as MPLS label) then the tunnel underneath can be anything.
Thomas: This proposal addresses transport, not service.
Ali: The transport is not VxLAN, think of it as MPLSoGRE.
Thomas: In Option-C at present, you can't change transport at the borders.
Ali: I thought we could do that already. With Option-B you can.
Thomas: This is Option-C.
Saikat: Right.
Rajiv Asati: With Option-C transport can be orthogonal L to R. Draft is
 trying to address transport part. Option-C solved this many years ago. You
 can stitch GRE to MPLS, for example.
Weiguo: <didn't understand>
Saikat: As I understand it, you are assuming L side VxLAN tunnel does not 
 encap MPLS. On R side, you need a two label stack. That's why you're introducing
 this complicated IP address scheme -- you're trying to map one label to two.
 I'm not convinced Option-C is needed, but if you do then either encap MPLS
 label inside VxLAN, or use two VNIs. The IP address to label mapping is too
 complicated.
Thomas (chair): Please take further discussion to the list.
 
* draft-rabadan-l2vpn-evpn-prefix-advertisement, Jorge, 10' including questions
[11:10 - 11:18]

Sue Hares: Ali, I sent you an email asking why there are so many proposals to carry next hop information. I'd appreciate an answer.
Ali: Please re-send it.
Sue: I'm really concerned about this draft having yet another next hop. I'll send
 it to all the co-authors.
Ali: you're referring to remote-next-hop? You mean why not 5512? We are now using
 5512, not RNH.  
Sue: That doesn't cover all the points. I'm not saying your reasons aren't good, 
 but I do want to know the reasons.
Wim: ESI next hop is described in draft as a use case.
Sue: It's an architectural question, you may have considered, you don't have to answer
 it live, but I do need an answer.
Wim: The draft does cover it.
Sue: OK, I'll re-send the message. 
Wim: What in the draft is not clear enough?
Thomas(chair): Explain the motivation for ESI next hop. Explain why RNH draft is not 
 suitable? Might help?
Jorge: Regarding use cases there are four very specific ones.
Lucy: It's a L2VPN, all endpoints have different MAC addresses but "floating IP
 address" that is the same.
Jorge: Similar to VRRP.
Thomas(chair): who thinks BESS should adopt? (a few hands ~8) Who thinks shouldn't? (no 
 hands). We'll take it to the list.

* draft-rabadan-bess-dci-evpn-overlay, Jorge, 10' including questions
[11:24 - 11:28]

Weiguo: How to realize mass MAC withdraw ("flush") on remote PEs?
Jorge: depends on specific use case. EVPN in DC, PBB-VPLS, depends on scenario.
Weiguo: Interconnecting two NVO3 networks. One node fails. How does the local
 PE notify the remote PE of what MACs must be withdrawn?
Jorge: can we take it off-line?
Thomas(chair): Yes, please take it to the mailing list.
Thomas(chair): Should the draft be adopted? (Some hands ~10) Not adopted? (No hands)

===================== Friday, 1150-1320 ===========================
Meetecho recording: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_BESS_II&chapter=chapter_0

* draft-sajassi-bess-evpn-virtual-eth-segment, Ali, 10' including questions

(related to Wednesday's session on AC aware DF-Election)
Ali: [idea that this proposal covers the need described in  draft-rabadan-bess-evpn-ac-df]
Jorge Rabadan: different issue than mine , which is about physical ESI, how do you solve my issue ?
Ali: associate an ENNI to each VLAN [?]
Jorge: lot of overhead
Ali: <not catched>
Jorge: I think it depends on implementation
Lucy: ENNI as new interface (?)                                      
Ali: many ACs over one ENNI, a new [...]
Ali: if all ENNI fail [...]
Lucy: Ok
Jorge: Nice draft, which I would like to extend
Jorge: [suggests a use case in between [?]] association of an ESI to an RSVP-TE LSP, PWs going to different ENNIs [???], Q-in-Q being the ENNI
Jorge: comment for PBB-EPVN, C-MAC flush done with an attribute, I think it does not work well
Ali: it does work pretty well: either one B-MAC per [..] or announce in an attribute
Jorge: no, if some B-MAC with another attribute, BGP RR will only keep one.  An alternative is one RD per ESI (?)
Jorge: why not B-MAC per ESI ? used for A/A anyway
Ali: increases (...)

* draft-sajassi-bess-evpn-etree, Ali, 10' including questions
                
Ali: insists draft is old
[no question or comment]
Chairs: take it to the list / too few people in the room
                  
* draft-sajassi-bess-evpn-vpls-seamless-integ, Ali, 10' including questions
                
[no question or comment]
Chairs: take it to the list / too few people in the room

* draft-boutros-l2vpn-evpn-vpws, Sami, 10' including questions
                
Ali: asks for adoption
Chairs: need to know what was the conclusion of the call for adoption in l2vpn
                  
* draft-boutros-l2vpn-evpn-vxlan, Sami, 10' including questions
                
Jorge: one thing not explicitly mentioned: no need to use ESi label (?)
Sami: agree, we should describe that
Chairs: need to know what was the conclusion of the call for adoption in l2vpn
                  
* draft-mackie-sfc-using-virtual-networking, Ron/Kireeti, 10' including questions
* draft-rfernando-l3vpn-service-chaining, Dhanajaya, 10' including questions
* / open discussion on service chaining, 20'

discussion starting at 01:03:00 approx in the meetecho recording]
Adrian: [two drafts, some technical differences, some documentation differences, some overlap of authors, let's be engineers rather than politician and build the best solution out of these two proposals]
Dhananjaya: [agrees how to move forward, only saw the draft the day before, sees almost 95% alignment between two drafts, difference relates to tweaks to allow solution to be used in a traditional solution w.o a controller]
Adrian: [on last point: need to see where that will be deployed eventually, see what impact on existing PEs -- need to take a step back to identify target, then make protocol choice]
Dhananjaya: reminds that draft-rfernando-l3vpn-service-chaining was considered for a call for adoption
Adrian: [up to the chairs to tell us to merge first before adoption or ...]
[skipped presentation on draft-rfernando-l3vpn-service-chaining because presented already]
Thomas(chair): Please first have a discussion on the list on technical differences
xxx (Ericsson): protocol unmodified and advertises label, how about mapping between SF and label? how is this done ?
Answer: see it as concatenated VPNs
Lucy: what about multiple SF attached to one PEs ?
Adrian: yes, supported

/ meeting ended