Monday, July 30, 2012 - 1540-1710 (Regency C)

Administrivia and working group status (Chairs, 5 minutes)

draft-ietf-l3vpn-mvpn-mib - mVPN MIB (Jeffrey, 10 minutes)

- Thomas Morin, co-chair: What additional work do you have?
- Jeffrey: Very little, we will re-spin a new version based on questions in the slides.
- Thomas Morin: We should identify a MIB Dr review.

draft-ietf-l3vpn-mvpn-bidir - mVPN bidir P-tunnels (Eric, 15 minutes)

- Eric: Both specifications are out of scope.
Unknown: Yes, I agree this draft is needed.
- Eric: I could have written a fluffy draft. This is more substantive. This draft completes earlier work that was started.
- Eric: There seems to be objections, regarding process, each time I present the draft. I fail to see the controversy.

mVPN extranet (Eric, 20 minutes)

No Comments.

draft-wijnands-l3vpn-mldp-vrf-in-band-signaling - mLDP inband signaling in a VRF context (Eric, 10 minutes)

- Martin Vigoureux, co-chair: Was it presented in the MPLS WG?
- Eric: I was told by the MPLS chairs that the work is for the L3VPN WG.
- Thomas Morin, co-chair: The agreement between chairs (L3VPN and MPLS) is that we (L3VPN) host the discussions.

draft-rosen-l3vpn-mvpn-mldp-nlri - mLDP FECs in BGP mVPN routes (Eric, 10 minutes)

- Thomas Morin: Without my chair hat, I think it's straightforward and useful.

draft-freedman-l3vpn-ospf2-4364-ce - PE-CE OSPFv2 (David, 10 minutes)

[due to bad audio quality, this remote presentation was postponed to the second session(see below)]

draft-hlj-l3vpn-mvpn-mrsvp-te - mVPN with receiver-driven P2MP RSVP-TE (Richard, 10 minutes)

- Wim Hendrickx: You make assumptions with current solution. If you look at the requirements for mVPN, there are extranet requirements.

- Unknown (other author?): We are still studying requirements. Not saying there is no solution, only not a good solution.

- Wim: Too many incorrect assumptions.

- Thomas Morin: (without chair hat) I think the analysis of existing solutions is not correct and that this is a solution looking for a problem. You should start by looking at what exists today and how it's used before deciding upfront that something else is needed.

- Eric Rosen: I was goind to say the same thing

Friday, August 3, 2012 - 1120-1220 (Regency D)
draft-freedman-l3vpn-ospf2 (Rob Evans)

- Thomas Morin, co-chair: you don't necessarily need to UPDATE RFC4577, you could formulate your specs as "uses the same procedures as RFC4577 but whithout such or such constraint".

- Pedro Marques: One requirement for MPLS in existing RFC for MPLS encap so that there is no loop. That is something to be further considered, that the proposal does not create loops. You can also use carrier of carriers without changing anything as in that case you don't have to relax the constraint to remove the label ret. It would be good to have OSPFv3 included in the doc as ospfv2.

On the carrier of carrier, there was a question on operation and Pedro's opinion was is that it would be operationally easier.

draft-fang-vpn4dc-problem-statement (Maria Naperiala)

- David McDysan: requirement on DC interconnect is absent in NV03 problem statement. It is important to capture. The detailed solution should be in L3VPN WG.

Bryant: There had ben discussion among the chairs on NV and the VPN WGs. There also will be Eric Grey that will overlook the merging of vpn4dc and Nv03 problem statement. When it comes to detailed work, it will happen in the respective VPN WGs where the expertise is. NV03 in essence will look at the DC requirements. Nothing should stop the l3vpn to look at the scaling and such. However, as a joint effort, the requirements should be in the NV03.

- Robert Raszuk: This work should happen here. Stewart replied that is not precluded but it is not worth a fight at this high level of problem statement

- Ali Sajassi: asked about the charter. Steart replied that working on the generally applicable solution and no need yet. If there is something to be specific DC, then that needs to be discussed.

- Thomas Morin as individual: The part related to interconnection of whatever is used inside the DC and IP VPNs seems to me as clearly belonging to this WG.

- Stewart Bryant: Work related to l3vpn whose applicability is not restricted to the DC would belong here.

- (missing name) Microsoft: SP is important. However, we should take another perspective. NV03 will be interfacing with the L3VPN or whatever.

- Pedro: time scale of provision the L3VPN service is at heart here. Stewart agreed that work can be done here.

- Nabil Bitar commented that this WG should work on IPVPN as it applies to DC. If something comes up in NV03 that should be addressed by the L3VPN WG, it should be addressed at that time. There is no reason to guess at this time, what that could be. FO instance, dynamic provision of L3VPN as mentioned on a short time scale, is an L3vpn WG problem.

- Stewart Bryant: do the work where the expertise is.

Conclusion was that authors are advised to reshape the document to focus on interconnection between DC and IP VPNs.

draft-marques-l3vpn-end-system (Pedro Marques)

- David McDysan: several items that are useful to IETF. Such as section 2 on discussion on performance. Mechanism, severa vendors proposing other mecanisnsm to configure switches etc., but this yet proposes other mechanisms. This is something that needs to be liaised with NV03. Pedro says that openflow defines very low-level programming model. Nobody is proposing here to control the forwarder at that low level, so he things there is no intersection or overlap here with openflow. There is also no intention to replace the work in NV03. McDysan mentions there is one paragraph that is worth incorporating in NV03 nd Pedro is happy if it can be incorporated in NV03 in problem statement as long as he is not directly involved.

Linda has a question on the discussion of separation of PE control and data plane as confusing. Pedro addressed that by re-explaining and asked if this is not clear that Linda can propose something that she thinks can clarify it.

- David Black: This is something interesting. His thought that there can be a uniform data model here that can be generalized

- Pedro: thinks that there are different models for L2 and L3 (or multiple of each) and not looking to unify that now.

- Wim Hendrix: Interesting. He thinks that this could also apply to l2VPN as well.

Raszuk: allow to scale PEs, and thi is mpre generic than data center as a result. This fits in this WG and thinks that this should be WG document

- Benson Schliesser: Interested in generalizing and Pedro agrees that it can be generalized

- Miller: would like this to be presented at XMPP. There are suggestions that there are things that could be better corrected reflected.
Pedro willl syncup offline.

- Thomas Morin, co-chair : Is this work interesting ? Show of hands: yes. "Not interesting ?" : no hand raised.