IETF 83 - L2VPN WG
Meeting Chairs are Giles Heron and Nabil Bitar

Agenda - http://tools.ietf.org/wg/l2vpn/agenda?item=agenda-83-l2vpn.html

Giles introduction

Only one meeting this time, NVO3 now has it's own slot.

 

TRILL for DC interconnect, we believe that is within the L2 scope as the existing TRILL drafts are for intra DC and this draft is for Interconnect over L2.

Note Well on screen for all to read, no need to read this out.

Updates on where we are with the current drafts.

No RFC's this time, but should be some coming next time. ARP-mediation is almost there and L2VPN-L2VPN is almost there also.

There are a few more to get through last call.

Nabil talking

vpls-mcast draft, past last goal, awaiting chairs comments and then write up and move to RFC


vpls-l2vpn P2MP draft, issues with that draft, awaiting Point to Multipoint process, until this is resolved there is no progress.

Giles talking

VPMS - Expert review being arranged for this, and should have some update by next IETF


PIM Snooping we hope will be presented at the next IETF. Jeff and Olivier have agreed to pick this up.

MAC optimisation draft. Florin points out that there have been some recent exchanges and it can go to final call.

Nabil talking:


Macflush loop detection for LDP.  Issued last call.  Nobody really responded.  Got expert review and chairs reviewed.  Not ready to go for AD's, as use case hasnÕt been documented. Authors requested to go back and start with the usecase and then document how it is addressed. Seems to be more of a misconfig problem of spoke pseudowires/VPLS mesh pseudowires. Looking for a better use case as the one documented also causes forwarding issues and thereÕs really no VPLS service at that point. Once use cases documented we can bring back to WG.

Giles talking

Multihoming - Kireeti at the Mic, feedback from SP and Chairs, solution is now using normal BGP mechanisms for path selection (not AFI/SAFI specific), need a write up and then ready to do another cut and then move to last call.  Hopefully done before next IETF meeting.

New drafts

E-VPN - requirements draft, we can't find it. Ali S @ mic - missed the deadline, will publish. E-VPN and PBB-EVPN being presented today by Ali (see WG IETF 83 slides) Because of the delays with the Charter, these drafts are pretty well baked now.

E-TREE - looking for the WG to decide on which way to progress, we had had multiple competing solutions and we have had the authors together to try and hash this out. We would like to go through this at the end of the sessions, as the WG needs to have consensus on which is the way forward, as it is not job of the chairs to pick a winner.

Giles - "Is there an AD in the house?" - Call for Stewart - no Stewart (or Adrian) in the room.

Doc Status Summary - 3 unadopted drafts, being presented today. WG needs to decide if we drop them or progress them.

End of Status updates.

DRAFTS

BGP MPLS Based Ethernet VPN
http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-00

Ali Sajassi talking

There has been a lot of discussion around how we can simplify E-VPN. Lots of complexity, this draft is intended to simplify and align with L2VPN.

Ali presents his slides...


Explains the problem statement, and the solution with forwarding modes, as per the slides. (See Slides)

Giles - "Ali you might be running out of time for this presentation, only 3 mins left"

Questions

*unknown - Question on multi-homing and active-active, it might work only in theory and not in practice for 2 CPEs connected to 2 PEs. CE will learn the MAC address and only use that single MAC address for forwarding.

 
Ali - no this is for MC-LAG and for active / active. Would like to make this clearer in the draft for the 2 CPE on 2 PE scenario. One of the SPs on the draft is looking at multi homing and multi CPE for this in the future.

Giles - Out of time - 10 mins for next draft.

----

PBB E-VPN
http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-evpn-01

Ali Sajassi talking

Ali presents his slides...

slide 7 - following a discussion amongst the authors, they want to spit the TRILL section away from the existing draft and call it TRILL-EVPN.

Kireeti - in the previous talk, DF election, would like path selection to be as AFI/SAFI independent as possible


Stewart - which working group specifics TRILL over wide area?

Giles it's not in TRILL,

Stewart, but it's not in L2 charter either. IESG might like to see if you are adding to the charter.

Giles, yes but we will check the existing charter.

Ali - TRILL added before it became WG draft, whilst they want to simplify and make it so, some authors wanted to split out TRILL.

Giles - yes, but need to check the charter

----

A Stateless Transport Tunneling Protocol for Network Virtualization
http://tools.ietf.org/html/draft-davie-stt-01

Igor Gashinsky presents his slides.

Discussion

Stewart - concerns about repurpose of TCP header. The Transport area does not usually buy into changes as to how TCP works. We need to talk to Transport AD.


Igor - this is a valid TCP header

Stewart - you can look up the interactions on this with the transport AD, you can look up flowspec to see how this went.

Kireeti - neat trick, question is not should this be in the L2 working group but should this be in the IETF. That you will be defining an encap because you have some hardware seems alien.

Igor - We are bring it to IETF as this is now running code and other vendors, we would like IETF support, but it is happening regardless. I do acknowledge this is a cute trick but I also believe itÕs a good way to do this.

Anton Ivanov - this is a question out of curiosity. Looking at the network drivers shows that most of the cards that can do proper offload, can do TCPv6 offload.  I would not want to be the Chief Security Officer of a network that deploys this so why donÕt you just do this for something less commonly used (v6).

 

Igor – My network is dual stack.  The target audience is large-scale data centres.  For those people we are not really breaking anything as it is within the boundaries of the network, so it's not a security concern as most security functions will be at the hypervisor level.

Anton - yes good answer, but you could do it in v6.

Igor - yes we could do it with v6.

 

Stewart - the fact you think this will be constrained to a single domain does not cut it. Please see T-MPLS and TP discussions from the past.

Igor - I'm speaking from a security point of view it will be constrained to a domain.

*Redhat - done a lot of UDP work and we see improvements with some cards for segmentation offload with some cards that can do this in software if not in hardware.  What is more interesting is the communications path between the guest and the host, and this is where segmentation is critical. Neat trick, but might not require a full draft. Have you measured cards with offload available?

Igor - we have seen 2-4X performance compared to UDP or GRE, and 10 with some types of hardware.

Martin Stiemerling (incoming Transport AD) - we have a defined TCP protocol, what you are doing is hijacking and trying to solve it by changing TCP, even if you say it is minimal.  By the time you standardise this you might as well have started with UDP.  No real gain vs using UDP but itÕll mess up the network.  Even if some WG adopts this it wonÕt get through IESG review as you say youÕre sending TCP when you arenÕt.  You say you are only changing a few things and we have to change some boxes in the middle, but take a look at the SIP guys and how long they are waiting to things like middle box changes to happen.

Igor – by the time we standardise there might be UDP offload available.  But between now and when I have enough deployment of UDP-capable cards this will be faster.

 

Anoop Ghanwani - first thing that comes to mind is we need to build a gateway for this, we need to build that in hardware so I'm sensitive to the performance of this, looking at the encapsulation this could be very difficult if not impossible to build.

Igor - I'm working with at least 2 hardware vendors who would disagree with you. From onramp point of view you donÕt need to do TSO as an onramp device.  As an offramp if you have to do NAT you already have to keep state so this is not that different.

Larry Krieger - This seems optimised for host to host, for large frame sizes?   Do you expect routers and switches to have to participate?

Igor - I expect onramp boxes which will not have to handle 64k frames, and offramp boxes which will have to handle state anyway so TCP reassembly is not a problem.

 

*unknown – port number isnÕt supposed to specify a transport.  Is this a new transport or an extension to TCP (in which case youÕre in the wrong group)? Either I think you are on a road to nowhere but you need to pick one or the other.

Paul Doolan - in the interest of disclosure used to work with Bruce. But I'm reminded of the phrase "what people do in the privacy of their own home".  So asking IETF to be tolerant.

Igor - so what are the next steps?


Giles – next steps will be talking to ADs, in particular the transport ADs

----


VPLS using IS-IS
http://tools.ietf.org/html/draft-xu-l2vpn-vpls-isis-03

Himanshu Shah presents his slides.

Discussion

Stewart - I missed something, what is MAC in MPLS? Is the MPLS PW or a new construct?


Himanshu - it is a PW, but we are using the same label to all the PEs.

Giles MAC in MPLS in IP, learning against the IP not the PW label, to forwarding plane is not the same as VPLS.

Ali - it is a multipoint ethernet service, not VPLS as we know it.  IÕm not sure where to start. You use the name VPLS, but it is not that, it is requires new forwarding hardware. Instead of ISIS you are replacing with BGP. Which customers want this solution, what segment?

Himanshu - Enterprise DC wants this as it is IP tunnels

Ali - so why are we using MPLS label?

Himanshu - it's only a label...does not have to be called MPLS you can call it a tenant ID or anything.

...laughter...

Anoop - how is this different from using TRILL?

Himanshu - This is layer 3 using the IP network, and TRILL this is not the case. This is L2 over IP

Giles - Who in this group is interested in this work?

Giles "line is cut"

Giles - "Who has read it and want to work on it?"

Nabil - We are trying to gauge this work.

Giles - this question is going to the list.

-----

Node redundancy provisioning for VPLS Inter-domain
http://tools.ietf.org/html/draft-liu-l2vpn-vpls-inter-domain-redundancy-02

Ran Chen presents her slides

Giles - "Question and who has read draft"


Daniel Cohn - why did you chose ring topology between ASBRs, not mesh (which is at least as popular)?  Should consider that also.

 

Ran – yes.

Dennis Cai - I like this proposal as it uses ICCP and is simple, however it depends on configuration co-ordination between two AS domains.  If you mesh between domains thereÕs no need to co-ordinate.

 

Giles – perhaps the three of you can discuss on the list, and after that we want to see if thereÕs sufficient interest to know if itÕs worth progressing.

------

MAC Address Withdrawal over Static Pseudowire
http://tools.ietf.org/html/draft-boutros-l2vpn-mpls-tp-mac-wd-00

Sami Boutros presents his slides

Nabil - Is this in the context of MPLS-TP and static PW


Sami - yes

Nabil - and the OAM message will be sent inband in the dataplane?

Sami - yes

Giles - Dan Frost and I were chatting about this earlier. We seem to be reinventing lightweight equivalents to tcp state machines for all the OAM messages, all incompatible.

Giles – In terms of this specific draft who has read it?  a few hands raised.

Sami - We are looking at exploring the options for this draft.  May drop it.

Ticara from Infinera - lets cover the static PW redundancy as well so we cover everything LDP does.

Sami - this is already covered.

Nabil - we need to take this to the list.

-------

Giles talking

Sorry but TRILL Data Center Interconnect will not be presented to day due to time and that it is also being at TRILL WG.

E-TREE Discussion

Giles Final issue we want to discuss is ETREE, we don't want another round of my draft is better than your draft. What weÕve done is get the authors together and look at where are the drafts the same and where are they different.

Slide - showing the table.

So we have discussed with the authors about the similarities, as an example one of the goals for all approaches is not to have any PW between two devices which only have leaves.


A key difference is 1 approach has a single PW between CPE for root and leaf and a VLAN ID indicates if it is root or leaf, and the other has 2 PWE and the PWE will indicate which is root or leaf. The VLAN mode looks more like the MEF and IEEE approaches – is that a conclusive enough reason to prefer that approach? There are some scaling differences, mostly around having either 1 or 2 PWEs. There might be a silicon issue - if you want to use different vlans, then this will have to be co-ordinated between 2 PWs, but would be easier to always use the same VLAN IDs – but there might be some questions on system vendors as to whether they can do that.  Also had discussion on how the approaches block traffic from leaf to leaf.

Another issue that came up this week is OAM and ECMP, if we are in MPLS network and running LDP then most of the devices will hash on innermost label. With two PWE approach we have two labels.  So we get slightly finer load balancing, but as a group need to discuss impact on OAM and if this is a concern.


We need to hear from people who are not authors.  Especially from carriers.  Would carriers like default VLANs for dual VLAN approach?  Does hardware support that?  Is someone interested in solving this for E-VPN?  Will that look different?  Do we have any IPR issues on these drafts?

Ed, Brighthouse networks - not concerned about the overhead for VLAN config, especially if I can config the same VLANs in each VSI.  Ideally IÕd like a signaling model to propagate the VLAN IDs.  I personally like the VLAN approach as works well if you have layer 2 access with .1q tags.  IÕm concerned about the OAM complications on dual PW path.


Eric Grey, Ericsson - summary slide was cool, can put that on the mailing list to see and discuss?

Giles - fair comment, yes we will post this presso and it will be on the IETF site, also perhaps authors and I can send an email too.

 

Ali Sajassi - we have an Ether OAM RFC for VPLS already, very concerned about any solution that breaks OAM for VPLS, and the 2 PWE might break that.

Giles - can you have a read of both docs and see where it would break?

Dave Allen - did not see on the list what happens with it subtended provided bridged network, and you would need the 2 VLAN approach, we have seen this in BBF. You can't assume tagged ethernet is only over VPLS part of network.

 

Daniel – OAM aspects only came up today.  DonÕt believe any solutions will break it.

Nabil – anyone here from silicon vendors with concerns about one approach or the other?  E.g. concerns on double lookup.


Giles – probably take that to list and have vendors unicast Nabil as heÕs an operator.

 

Giles - do we have a strong preference for dual VLAN solution? 1 (plus someone who appears to be stretching). Anyone for 2 PW? Ok none.

Nabil - Anyone prefer E-TREE to be developed? Or only authors interested in E-TREE?

Giles – Any operators who care about E-TREE?  3 operators and 1 vendor who thinks heÕs an operator.

Nick Delregno - we amended the charter to include E-TREE, so we probably care.  Speaking as a provider we donÕt have a huge interest.  But I assume there was.

Giles - as a former SP IÕve seen interest.  But if you can segment root and leaf PEs thereÕs no need.  Interest is if topology forces you to have roots and leaves on the same PE.

 

Thank you, we are now closed see you in Vancouver.