83 - L2VPN WG
Meeting Chairs are Giles Heron and Nabil Bitar
Agenda - http://tools.ietf.org/wg/l2vpn/agenda?item=agenda-83-l2vpn.html
Only one meeting this time, NVO3 now has it's own slot.
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.
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.
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.
optimisation draft. Florin points out that there have
been some recent exchanges and it can go to final call.
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.
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.
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.
BGP MPLS Based Ethernet VPN
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)
- "Ali you might be running out of time for this presentation, only 3 mins left"
*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.
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?
it's not in TRILL,
but it's not in L2 charter either. IESG might like to see if you are adding to
yes but we will check the existing charter.
- TRILL added before it became WG draft, whilst they want to simplify and make
it so, some authors wanted to split out TRILL.
- yes, but need to check the charter
A Stateless Transport Tunneling Protocol for Network Virtualization
Igor Gashinsky presents his slides.
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
- 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.
- 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).
– 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.
- yes good answer, but you could do it in v6.
Igor - yes we could do it with v6.
- 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.
- 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?
- we have seen 2-4X performance compared to UDP or GRE, and 10 with some types
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.
- 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
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.
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
Himanshu Shah presents his slides.
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.
MAC in MPLS in IP, learning against the IP not the PW label, to forwarding
plane is not the same as VPLS.
- 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
- 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.
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
- Who in this group is interested in this work?
"line is cut"
- "Who has read it and want to work on it?"
- We are trying to gauge this work.
- this question is going to the list.
Node redundancy provisioning for VPLS Inter-domain
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.
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.
– 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
Sami Boutros presents his slides
Nabil - Is this in the context of MPLS-TP and static PW
Sami - yes
- and the OAM message will be sent inband in the dataplane?
- 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
- 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.
- this is already covered.
- we need to take this to the list.
Sorry but TRILL Data Center Interconnect will not be presented to day due to time and that it is also being at TRILL WG.
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.
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
- 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.
– 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.
- do we have a strong preference for dual VLAN solution? 1
(plus someone who appears to be stretching). Anyone
for 2 PW? Ok none.
- Anyone prefer E-TREE to be developed? Or only authors interested in E-TREE?
– Any operators who care about E-TREE? 3 operators and 1 vendor who thinks heÕs
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.
you, we are now closed see you in Vancouver.