(Minutes taken by Jeff Haas and Jeff Tantsura, merged by Thomas Morin)

**** Document Status ***

Answer from Eric Rosen on the status of a few documents:
- mVPN mLDP NLRI needs a respin and should be ready for WGLC
- MVPN bidir work needs to integrate further review comments, and will be ready for WGLC
- Extranet document needs additional feedback.  Guidance requested from the chairs to see how it should progress?
  Chairs: Reviews of such a draft is not trivial.  We'll discuss.

Milestones.  One needs to be marked as done.  Some were optimistic.


*** Covering Prefixes ORF (draft-bonica-l3vpn-orf-covering-prefixes-00) - Ron Bonica ***

- Robert Raszuk: BGP in BGP environment, RT-C was designed to do a pull.  My question on the list is why not use it instead of ORF?  Not optimal.  Second question: Question of co-existance of RT-C and route refresh that needs clarification.
- RB: Virtual hub carrying only a small amount of state. ORF not a bad idea for what it does, small work to solve a small problem. Alternatively you could use route constraint, but you'd need to tweak it for "longest covering route".  Maybe RT-C is the right way to do it.  Either we need to change ORF, or RT-C.
- RR: We want to limit moving parts. perhaps extending RTC would be preferable: at least we'd running new SAFI instead of ORF *and* RT-C
- RB: Worth more analysis.
- Lucy Yong: I think it's a good start for BGP to have some pulling function. Refresh won't get propagated. How about if the route needed is not on RR ?
- RB: That's a feature, we want this one hop out.  There's text in this document to discuss the sceanrio.
- LY: Potentially useful for inter-as?  RB: Hadn't considered it.  LY: [...?]
- LY: How does RT get configured
- RB: locally
- Keyur Patel: I like it, but please consider RT-C.  ORF can get very long.  RT-C is a lot more graceful partially due to them being sent as prefixes.  There are well known existing mechanisms that do this stuff using different protocols.  What's different is that you're initiating a trigger from a PE that is a spoke vs. a hub.  Two questions I had was: Why do this at spoke instead of hub - the hub could detect this.  What was the difference?  If you use RT-C, the message goes to the hub.  
- RB: Spoke instead of hub - two reasons: Sometimes only the spoke is in a place to detect such a flow (example of a congestion on a link connected to the vspoke).  Sooner or later you want to get rid of the ORF.  The hub never knows when the ORF is needed - spoke is always in beter position.  ORF entries can get long - don't know if this is the case.  Spoke will only get a certain number of exceptional cases.  As for really long ORFs - not sure so, one can also use different sequence ; Since ORFs are sequence numbered, they can be incrementally maintained.
- KP - if the control plane session resets, you need to send all at the same time.
- RB: We lose the RR, we lose all flows anyway.
- KP?: Graceful restart!
- RB: Yeah, there may be an issue there.
- LY: Only targeted for hub/spoke, there may be other use cases.  I think such a mechanism in general BGP is still useful.
- Xiaohu Xu (Huawei): This draft doesn't deal with overlapping prefixes. Common issue with LISP.
- RB: Do we have enough consensus that we can adopt this as a draft?
- Chairs: Premature.  Continue on list.

*** Global Table Multicast based on mvpn protocols and procedures (draft-zzhang-l3vpn-mvpn-global-table-mcast-02) - Eric Rosen ***

- ER: Adoption is a bit odd. The WG is not chartered for global table.
- Chairs: Not time to discuss here - will need to coordinate with other groups.  
- ER: mboned doesn't do protocols, pim doesn't do vpn.
- Shahram (Davari?): What if these aren't internet routes. What are they - service routes?
- ER: Possibly content provider routes?  Not in a VPN context.
- SD: Why just create another VPN for these content providers.
- Robin (Zhenbin Li, from Huawei): There are another two drafts, including one from me.  As an implementor, I like this solution with RD with 0.  [...] Should RD 0 be used for BGP public routes in general? (Lot's of issues(?) relted to having to copie with RFC3107 ...?)
- ER: If you want to make vpn routes with rd 0 as public IP routes - didn't see any value to this.  For mcast safi, it's a bit different since there's nothing else like it there.
- Wei Meng from ZTE - why status of draft from informational to standard?
- ER: My opinion after joining list of authors was that the list of procedures was such that it warranted it as a proposed standard.  If it was just a matter of proedures rather than protocol, then informational.
- WM: another draft using another safi, [...] another solution - why isn't it worth a new SAFI ?
- ER: Already discussed
- Chairs: Another draft in mbone. Don't want two solutions.  Need to synchronize.
- WM: proposal: solution can help with ipv4/ipv6 transition issues?  Please look at transition issues in the draft.
- ER: I think this is covered.  See RFC 6515
- Robin: How to cope with existing RFC 3107? [Due to muddying the semantics of things via RD 0 meaning public non-VPN]


*** Ingress replication p-tunnel (draft-rosen-l3vpn-ir-00) - Eric Rosen ***

Clarifications for existing specs.

Note: very short presentation due to lack of time, no time for questions.
(please read and comment)

*** Label sharing for fast PE protection (draft-zhang-l3vpn-label-sharing-01) - Mingui Zhang ***

- Robert Raszuk: Already a solved problem in another draft (draft-minto-2547-egress-node-fast-protection).
- Zhang: Not changing the P-node. [..]
- Robin (from Huawei): I presented global label solution in Berlin and think it is better. This is global label vs. context label.  One label to identify the VPN.   
- RR: How do you assure same label assigned by N-PEs? Label sync is a hard think to do, static allocation simply doesn't work
- Robin. [SDN!]  Or configuration.  
- Bruno Decraene: Agrees with RR, need discussion on mailing list to say why your solution is better.  Question to chairs: Egress FRR?  Another solution in RTWG.  Need to figure out which group to discuss in.
- Chairs: will coordinate with rtgwg


*** Virtual Subnet: a l3vpn based subnet extensions solution (draft-xu-l3vpn-virtual-subnet-01) - Xiaohu Xu ****

- Lucy Yong: In nvo3, we describe this scenario.  In order to do DCI interconnect, how do you request the DC to advertize host routes?
- Xiaohu: We can use many mechanisms (see slide 2). We use existing mechanisms such as ARP/ND. 
- ? Today, not using ebgp, isis, etc. 
- Xiaohu for local c-host mechanism, we use existing mechanisms such as ARP.  No need to run bgp to hypervisor
- Wim Hendrickx: How many times does your solution breaks TTL?
- Xiaohu: Can use existing l3vpn mechanism
- WH: You'll decrement twice.  Subnet forwarding shouldn't do that because some application use TTL=1.  You're not describing how to do this - it's not existing l3vpn mechanism.
- Xiaohu: Will look into it


*** NVGRE vxlan encapsulation (draft-yong-l3vpn-nvgre-vxlan-encap-03) - Lucy Yong ***

- Eric Norberg: Technical observation. What you're proposing with the vxlan extension can already be done in LISP header, on which VXLAN header is based.  It's a separate UDP port number.  You can already ipv4 and ipv6 packets.  vxlan spec is not only about data plane, but also control plane learning as well.  You're asking in this WG.  Nice would be if IETF figured out where we can work on vxlan and nvgre extensions.
- LY: LISP encaps is tied to LISP control plane. This is DP only, can use any CP.
- EN: Not true.  Also includes data plane learning.  Both have integrated data and control plane components
- LY: Talk to LISP people.  We also presented this in layer 3 wg.
- Florin Balus: Will break existing implementations. We need one place to discuss this.
- Chairs: Need to check the different wgs.
- ? - We need to check in nvo3.  It's a totally new encapsulation, we should talk about this in one place, not 3.
- LY: Agree that we should talk about in one place, but disagree it's totally new
- ? - Current chipsets already recognize this, but not with UDP encapsulation
- Stewart Bryant: vxlan, we're still on track for finding a fast track to publish what the industry has shipped.  When it comes to a standards track solution, we need a discusssion between LISP, NVO3 (charter change needed) and l3vpn.  LISP can already do this, why shouldn't we do that?
- LY the lisp data plane solution is tied to lisp control plane.
- SB: Let's talk to the various groups.
- Jeff Tantsura: Comments are same in different WGs: breaks things.
- Xiaohu: if types are limited to l2 and l3, we could use just use (MPLS?) no need for an ethertype.  But for other payload types, such as metadata, which may need such things.
- LY: Our objective to be generic overlay virtualization format.  
- Chairs: Feel of the room, interesting to have these encaps carrying IP traffic?  (some hands: 8)  not - one hand (Thomas Narten: "not entirely sure we need to solve this problem").
- Thomas N: Let's not put together NVGRE and VXLAN - they have different sets of issues. I'd like to see this problem solved once and with everyone in the room.
- Florin: Do we need to interconnect 2 L3VPN instances? Yes but then it should be IP over VXLAN, no MACs. Strong support to solving this problem.
- Ali: Optimizimg VXLAN?
- Nabil: Let's step back and look at the problem as a whole

*** An arhictecture of instant VPN (draft-li-l3vpn-instant-vpn-arch-00) - Zhenbin Li (aka Robin) *** 

- Luyuan: This is a subset of virtual PE. Have you read the virtual PE drafts?  If you think it's not complete, we can collaborate. Why do we need something new?
- Robin: We think vPE/vCE are only architecture drafts, we plan to describe protocol extensions
- Luyuan: vPE/vCE have the requirements for authentication ; don't see any news
- Martin Vigoureux:  Which protocols do you plan to extend ?
- Robin: BGP, I2RS, some AAA

*** Virtual PE (draft-fang-l3vpn-virtual-pe-04) - Luyuan Fang ***

- Lucy: how is this draft related to nvo3?
- Luyuan: It is l3vpn based solution
- Samita Chakrabarti: Good. Lot's of options, plans for pros and cons analysis?
- Luyuan: No, I don't want to judge, however we do provide some considerations
- Lucy: In DC we have got both L2 and L3 VPN - we don't need 2 different architectures
- Luyuan: We don't want to choose. Need to talk with her coauthors on including layer 2.
- Wim: (echoes Lucy's comment) There's a bit of L2 in the document, either clean it or fully include it. There are going to be lot's of mixed deployments, how do we address those?
- Nabil: Do we want to abstract that much ? I'm fine with the scope.

*** Virtual topologies Service Chaining (draft-rfernando-l3vpn-service-chaining-03) - Luyuan Fang ***

- Luyuan: mentions new coauthors (Adrian, Nabil soon)
- Lucy: The solution might have some scalability issues 
- Luyuan: We use RTC so distribution is constrained
- Lucy: setup by policy is very complex
- Luyuan: me and my coauthors are experiemented with policy and know the complexity
- Chairs: who has read  ? (~a dozen hands) - please push the discussion on the list