IETF 87 - L3VPN WG Meeting session agenda
Tuesday, Morning Session, 9:00-11:30
Chairs: Thomas Morin
Martin Vigoureux (remotely attending)
Full recording (synchronized video, audio, slides and jabber room) of the L3VPN WG session at IETF 87 is available at the following URL:
(Start time 9am)
See WG Status slides
IESG Review of draft-ietf-l3vpn-virtual-hub
No agenda changes
- Label sharing for fast PE protection
Hui Ni, 15 min
**** cancelled because of visa issues ****
- Performance Monitoring
Zhenbin Li, 5 min
Hui Ni, 10 min
Questions for all drafts saved until end of slide-set.
Poll the room, approx. 7 people read the draft [last presentation].
Thomas: request comments on list and comment on the list.
- Service-driven Co-routed LSPs
Zhenbin Li, 5 min
Thomas: Poll who read document: half a dozen.
Hui Ni, 10 min
Thomas: Poll who read solution draft, a few (same number as before).
- Open discussion on L3VPN WG activities in scope of DCs and their interconnection all, 30 min (5-10 min, overview by chairs + 25-20 min, open microphone)
o Reading material includes:
Kireeti: I think the current thinking seems to be for a waterfall, if NV03 do extensions, they need to bring them to L2VPN or L3VPN. Should work be here? No
Thomas: Previous discussion, which WG, etc. protocol extensions will be provided in the relevant WG. One draft today was presented, should this be done in advance on settle for NV03 (Slide 5)?
Thomas: Other application spaces? If I am working on something applicable outside DC, or VM, etc., can it just be done here; e.g. we are talking about DC interconnects. Thomas: I understand, but do not agree, at least 2 of these drafts are DC interconnects, which is not in scope of NV03.
David: DC is clearly NV03, interconnects is confusing, should L3VPN do DC interconnects in isolation, ignoring what is done in NVO3 o? No. Expertise for interconnect is here, less so in NV03.
Luyuan: Comment on scope, V-PE I-D, scope is not just DC. how to extend L3VPN into DC, to connect VMs. Application vPE is really applied to DC, and outside of DC, SPs are thinking of cloud offering, tech remote office, not DC related only.
Nabil: Definition of DC, if IaaS is very narrow, you could use this to provide compute, virt, etc. network based services. Question is scope, DC or not, etc. which type of DC. This needs to be clear.
Mach Chen: I know NV03 charter does not include solution work. Charter says possible it should reuse existing solutions L2VPN, L3VPN.
David: oh boy, charter scope discussions. Correct not in charter, deliberate to avoid solution work, does not mean that this out of future charter; solutions are in envisoned charter (something is Very bad idea).
Kireeti: MPLSoUDP as an example, application is DC, application of MPLS over IP, not of GRE but over UDP. If scope is beyond DC, and it’s useful then let’s do work here. Do we have to wait for NV03. Is it DC specific? If I am cloud and IaaS, then that’s DC, NFV, that is not a traditional DC. Not an easy thing, gets into charter discussion, reuse L3VPN beyond DC, if it’s useful then we can do it here. Or wait on NV03.
Thomas: Without chair hat – extensions to address space, interconnect, VDC, and IP VPNs. What if we need to define dataplane extensions to interconnect VPN with what is done in the DC ?
Luyuan: Pickup on Kireeti, NFV and vPE and VCE, these are not specifically DC only. For DC interconnects, (reference David comments) we need to address what people are using within DC (may not be L3VPN). You can terminate, translate, etc. and we do not define how DCs work.
Lucy: Relates to DC infrastructure work, vDC l3VPn overlay.
Richard: Related to DC, if principle can be applied to.
Thomas: There seems to be consensus that Applicability statements NVO3, protocol extensions here [L3VPN]. One year ago we had NV03 discussing, chairs understanding was that Applicability here, as soon as NVo3 was involved for gap analysis. (Comment to Benson – NV03). Line between NV03 and lother WGs: how you would use it here is how it would be deployed in DC, and have NVO3 do a gap analysis
Benson: With chair hat, I recognised ambiguity, gets worse if we mention NSC BoF. I suggest we sit down with ADs.
Thomas / Stewart (AD): Agree.
David: regarding the earlier comment, if you had gateway DC boundary, DC interconnect, if independent of DC internal, will do something useful, that would be the demarcation.
Thomas: without chair hat, we know VLANs, a poor solution, it does not
match the needs of operators. We need control plane interoperability, NVO3
considering federations, it make sense to work on this topic. We need
David: Agree, cooperation between WGs required.
Luyuan: overlay VPN is an overlay, could GRE, etc. that is existing.
Xuxiaohu: NV03 is performing a gap analysis, before this is finished we should be careful to avoid new extensions. We should see if we can reuse existing protocols.
Jim Guichard: use of DCin vPE and vCE is unfortunate, in fact vPE/vCE is not DC-specific..
China Mobile?: I think besides the applicability statement, NVO has use for overlay, we have requirements that cannot be addressed, we wnt to see new scenarios.
Benson: We should be careful about end-runs around WGs, co-operation is required. We need to sit down and discuss.
Thomas: We all agree collaboration is required.
Kireeti: Echo Luyuan, NV03 is not well … overlays, it is really about virtualisation in the DC. We can use other technologies, etc. NVo3 is interesting, but overlays is less interesting. If it fits with the orchestration, etc. That’s why applicability statement needs to sit in NVO3.
Nabil: Just about to say what Kireeti mentioned. Gap analysis, is an example. As a result of the analysis, there could be extensions, Data or control plane, these would go to relevant WG, as ADs mentioned.
Benson: to corroborate, that’s the right approach, depressingly it was a year ago.
Thomas: whatever the WG is, draft name, etc. We should have joint adoptions and joint WG last calls.
Benson: agree. It is conceivable, there may protocol work that does not fit in a WG, which is a scenario in NV03.
Thomas: Two comments wrt. gap analysis being proposed to NV03 as proposed individual drafts: should it be based on L3VPN current specs or on data plane extensions for new encaps ? Should they be considered? I think yes.
Benson: I agree, gap analysis should be complete as possible. As long you are open to new work, then we are always going to add things into NVO3.
Thomas: it is hard to take into account without a spec to point at.
Nabil: Do you reject completely if non-standards, or standards (???). Need to acknowledge that VXLAN is becoming a de-facto standard.
Florin: No body is mandated to standardise (?). We need to standardize these new encaps somewhere: recharter NVO3 or another working group and move forward. Gap analysis needs to move faster.Thomas: Maybe a comment of NV03 session, it would be useful to specify just the encap for VXLAN.
Keyur: are you going broaden for NSC and SR.
Kireeti: question between L2 and L3, assuming VXLan is standardised, they should use the same encapsulation as far as possible. Here you have two drafts EVPN, IPVPN over VXLAN. I want to use signalling and data plane to alike as possible.
Ali: L2VPN was rechartered it for DC and cloud, I would like these efforts to be recorded. Calls for coordination.
Stuart Bryant (AD): Could you summarise for this for a poor AD?
Thomas: Yes, it is clear protocol extensions will be done here, and applicability statement and gap analysis would be done in strong cooperation with NVO3, with a possible agreement to to joint last calls and adoptions. The Scope questions of what is considered “in the DC” and what is considered “out of the DC” apparently needs to be discusseds between chairs and ADsStuart Bryant (AD): Thank you.
Thomas, poll second question in slide: “do you think L3VPN WG should contribute to developing solutions for the scope of DC and DC interconnections ?”
[15-20 hands raised.]
Thomas: Who thinks l3vpn should not… ?
One person says no (see below).
No other“should not”.
Senad: I think these should be separate: DC in NVO3, DC interconnects here.
John Scudder: “contribute to” is a loop hole, open to interpretation.
Thomas: todays discussions show what contribution would mean “contribution *with* NVO3 for everything that is common with NVO3”.
Luyuan: Yes, when technology is purely L3VPN. In addition to app/gap, minor changes discussions, based on L3VPN, it should be here.
- mVPN - BGP as PE-CE protocol
Keyur Patel, 10 min
Thomas: without hat – Interesting, reducing contention between PE routers. Having input on load reduction would be use to have, numbers would help.
Thomas: Who read the draft, good number (~10 hands).
- mVPN C-bidir with ingress replication
Jeffrey (Zhaohui) Zhang, 15 min
Thomas: good that there was discussion on the list
Poll: a few hands raised (5)
- mVPN state dampening
Thomas Morin, 10 min
Andrew: This is trying to solve a problem we are seeing. We should work to progress this.
Adrian (AD): Is this a protocol solution document?
Thomas: no, local behavior.
- mVPN MTrace
Robert Kebler, 10 min
Stig: You are attempting to compait (??), rather than using MTrace V1. Is this just PE-to-PE, customer network, host.
Robert: P2 to PE, extending MTracev2.
Robert: We are trying not to show all details, to provider network.
Stig: I agree we need to limit what is exposed
Thomas: comment regarding location of doc. MBONED is where the protocol extension would be done I assume. Feedback is nice from l3VPN, to match provider needs, etc. Nice to present document in both WGs.
Stig: MBONED is trying not to protocol work.
- multicast 6PE
Zhenbin Li, 10 min
Thomas: just to be clear, the use case is non-VPN and thus out of charter.
Jeffrey: Existing LVPN procedure can be used to support V6 over V4, there is no need to introduce packet standards. If you use mVPN procedures. If you remove RTs, leaf AD routes, you still need to use RTs.
Zhenbin: #2 If you multicast you have to use, separate unicast and multicast, must be channelled into private instance
Thomas: to do 6PE for multicast, you can use existing VPN procedures.
Zehnbin: we will look at your draft.
Ice: If you set the RT to 0, then we are done.
- mVPN role-base state advertisement
Hui Ni, 10 min
Thomas: Context is mVPN, but we do not have manual provision of mLDP for mVPN. For traffic replication, we already have S-PMSIs… So we already have features, you may need to investigate features to make sure you are not reinventing the wheel.[Minutes taken by Daniel King, completed by Thomas Morin based on notes and recordings.]