l2vpn - ietf78 /agenda bashing /wg status l2vpn-sig still held up by norm references but resolved LDP status codepoint conflicts some IESG discuss ARP mediation: writeup ready MIB: passed wg LC context-map-mib: need to determine where this at IPLS novel use of fec 128 for mp2p pws Luca: we have a wg draft on p2mp pws in PWE3, let's see how we can make the two work together "race condition" text imported from arp-med Joel had a comment on v6 or/+ v4. Shane: other comments on that point? mcast vpls being reviewed by Wim, pim snooping expired OAM work still on Service convergence / mhoming Scalability: need to also progress these /BGP-based VPMS A-D and Signalling Rahul presents the motivations for the draft draft covers BGP based VPMS auto discovery and signalling description of procedures: Sender and Receiver sites sets defined by policy. Policies implemented using route targets advertised in the corresponding BGP A-D routes redundancy also covered. inter-as and ms-p2mp-pw applicable to bgp signalled p2mp-pws Lizhong: I sent comments on list but see new draft does not take them into account should also consider return path from leaf to root Rahul: How do these procedures support a return path is a Valid point. Return path could be set-up quite easily. Wim: AFI/SAFI used are the same than for bgp-vpls? Rahul: would be ideal, but requires further discussion Wim: indeed as we are overloading these AFI/SAFI already Rahul: we'll reuse at least tunnel attribute Wim: for reverse path we might want also to signal option to do it or not Rahul: if leaf PE advertises a tunnel then you'll have it. Wim: [missed] Rahul: very important question. Relates to the discussions on e-tree and vpms What is the encaps that vpms supports is an important question indeed. Lucy: you talk about root signalled, what about leaf initiated sig? Rahul: nothing prohibits a leaf PE to advertise tunnel (for return path) Lucy: if leaf wants to join afterward, will there be root based signalling? Rahul: leaf will receive BGP update Luca: this draft is about auto-disco. The title is misleading. Rahul: we should rename when WG adopts it Shane: how many read? (~20 hands) how many support BGP signaling of P2MP PW's inside this L2VPN draft? 6 hands how many against? 0 hands 7 hands for wg document no objections /Requirements for MEF E-Tree Support in VPLS draft is about functional reqs for mef etree support in vpls Fred presents MEF definitions two mp service types defined by mef (e-lan/mp2mp & e-tree /rooted-mp) e-lan: roots only, any to any connect e-tree: roots and leafs Then presents e-tree use cases, the generic e-tree service the problem statement and the requirements Nurit: (on slide5) First of all, think E-Tree is an important type of service. e-tree is rooted mp service (i.e.: unicast root-to-leaf is primarily in scope), you should emphasize this and also mention that multiple roots can exist. Rafi: bakward compatibility: you mention the use of CW. there is silicon in the field that would not support this. need to think about other procedures. For backwards compatibility, two PW could be used as fallback. Luca: on use cases. video is not really suited for this service. other use cases can be/are done differently. need to pin point the most important uses cases Rahul: we are confusing issues. E-Tree comes from MEF. What are the reqs for e-tree? strong req for hub and spoke, I agree. we need to decouple that from e-tree. two ways of doing it: * vpls with some changes * vpms Shane (as co chair): I do not believe e-tree is in our charter. Luca: Can define this group as BGP VPLS focused or different. Rahul: there is a req for hub and spoke vpls. if not in charter, it should be. Rahul: the only case for which current mechanisms do not work are on slide 7 of the presentation. Shane: dangerous for l2vpn to take up a wg item for which we do not have consensus for a feasible underlying technology solution(s) PWE3 and L2VPN and ADs need to get together to discuss path forward. Rahul: problem on slide 7 does not need use of CW. Shane: true but we do not have a solution for leaf and root ACs on same PE inside the same Bridge Module Luca: looks like internal/local implementation Ali: Demand is clear. shane is right that current vpls model does not support. need to better understand the reqs. Florin: Agree with Rahul, multiple ways to solve it. In the end we need one way of doing the solution. Interoperability is key. Yuanlong: PE/VLAN model, proposed at last meeting, covers general aspects. Dave A.: this group should not redefine what e-tree is. MEF has very good definition and we should stick to it. /Routed VPLS using BGP & BGP MPLS Based MAC VPN Ali presents the vaious requirements all active mhoming mhomed network mcast optimization with mp2mp lsp (in add ition to p2mp) ease of provisioning new servicve interface fast convergence flood supression ... Kireeti: before going into the solution. The charter talks about multi-homing, optimized convergence. So from one PoV it is in the charter. Shane, whay is your opinion? Shane: in my view it is not. we are significantly behind on existing milestones. am concerned taking additional work will not help finish overdue work items. Marc: There should be a standalone, crisp/concise requirement document Shane: later slides discuss a split of the reqs and solutions Rahul presents the solutions. Many commonalities between two drafts. convergence towards single set of bgp encoding. builds on bgp/mpls but needs additions: MAC address advertisements in the control plane (principles borrowed from IP VPNs) next steps: lots of interest, seems to fall within l2vpn Linda: why do you need cp to do remote learning? Rahul: you can do for e.g. load balancing Ali: if DP mac learning then run into the issues mentioned earlier in the presentation Fred: when deploying VPLS, SPs take care not to take part of customer's IP scheme and customer's IP signaling. Here we need a signaling between CE's and MESs to advertise the MAC@? Rahul: they do not put particular new requirements on CEs DP learning between CEs and MESs is not mandatory Shane: document should contain applicability statement wrt positioning "ethernet vpn" with regards to traditional VPLS VPN's. Marc: agree. applicability should be clarified. we should further not come up with news terms. Ali: that solution does not exactly fit in vpls model. Florin: applicability is important. active-active but also data centers. Dave A.: is preserving frame order guarantees a requirement? Rahul: does mpls provides this guaranty? Ali: on a per flow it preserves. Rahul: in almost all cases, yes. There are cases where out of order packets could occur, cf: MPLS Fast Re-Route. Ali: congruency does not guaranty order. Shane: order is not guaranteed for different types of packets over LAG's in certain types of VPN's, e.g.: unicast vs. multicast traffic ... depends on outcome of hash. Kireeti: In the current VPLS solution, there is potential reordering between flooding an unlearned MAC over a p2mp tunnel and unicast of the same MAC over a p2p tunnel. This problem is "solved" if using ingress replication for flooding. Nothing changes between VPLS and MAC^h^h^h Ethernet VPNs on this front. Shane (hat off): did not see anything about v6. I recommend that you cover this. Shane: how many in favour of taking work item? 20 p against: 2p Stewart, your opinion on whether it is or not in charter? Stewart: I suggest we discuss together. Linda: difference between l2vpn and e-vpn? Rahul: this is terminology. this solution is addressing requirements. Shane (hat on): as I see it e-vpn is used as a "marketing term" to differentiate it from VPLS, because it's solving a different need. Puneet: the VPLS framework RFC does not describe the situation for this solution. Shane: framework documents are meant to evolve, cf: VPMS framework, PBB framework, etc. /Linda on scalable AR for DCs and CC. Teaser for the ARP222 Bar BoF -no comments-