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
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?
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
- 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)
* 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
Thomas(chair): Please continue list discussion.
* 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
* draft-morin-bess-multicast-damping, Thomas, 10' including questions
[9:32 begins - 9:37 ends]
* draft-zhuang-l3vpn-yang-cfg-00, draft-zhuang-l2vpn-evpn-yang-cfg-00, draft-zhuang-l2vpn-yang-cfg-00, Zhenbin, 15'
[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
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.
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
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
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.
Thomas (as individual): We need to look at state cost, yes. But motivation to
prevent blackholing is Very Valid.
(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]
Tapraj: for PBB-EVPN, why only ESI: can we use BMAC?
Jorge: BMAC assignment in PBB-EVPN <something>.
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
<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
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
Jorge: EVPN procedure is completely compatible with existing EVPN. Local
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.
* 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?
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?
Osama: Don't need to limit VNI to 20 bits, doing the translation anyway.
Limiting the VNI just complicates things.
Wim H: You actually want to connect VxLAN domain using Option-C to an MPLS
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.
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
Thomas (chair): Please take further discussion to the list.
* draft-rabadan-l2vpn-evpn-prefix-advertisement, Jorge, 10' including questions
[11:10 - 11:18]
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
ENNI as new interface
Ali: many ACs over one ENNI, a new [...]
Ali: if all ENNI fail [...]
Jorge: Nice draft, which I would like to extend
[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]
[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]
[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]
[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