Re: [l2vpn] WG adoption call for the draft Integrated Routing and Bridging in EVPN, draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05

[Thomas Morin <[e-mail]>]

Hi working group,

(My apologies for not having found time to review this and send feedback 
earlier.)

Although the topic of inter-subnet forwarding is indeed important, I 
have a few concerns about the document as it currently is, and I do  not 
support adoption in its current form.

My main concerns are the following:
- the document describes multiple solutions, but the benefit/necessity 
of introducing each is to me not clearly spelled out, in particular the 
benefits compared to an approach that would just locally combine an EVI 
and a VRF ; I'm not saying there is no benefit, but they just aren't 
spelled out explicitly, nor the limitations of what we could do without 
these specs
- how these solutions can be combined or not is not explained, and an 
immediate worry is the question of interop of solution implementing one 
approach with solutions implementing another
- a important point would be to make it explicit that in all solutions, 
interop with routers not implementing these specs and implementing plain 
RFC4364 should be a MUST (by having NVE implementation also import and 
use IPVPN routes if any is advertised, and advertise IP VPN routes for 
the networks for which IP VPN interconnection is wanted)
- last but not least: section 5.2 depends on 
draft-rabadan-l2vpn-evpn-prefix-advertisement that is not yet a working 
group document: wouldn't we putting the cart before the horse by 
adopting draft-sajassi-l2vpn-evpn-inter-subnet-forwarding now ?

Other questions:
- section 4.3 seems to me as possibly incorrect: the proposed procedure 
consist in having the ingress NVE rewrite the destination MAC address of 
the payload before, but I can't understand how this makes sense: why is 
this needed since the packet is forwarded based on an IP VPN route (and 
can thus only be an IP packet) ? and why would the payload destination 
MAC be useful to the local WAN gateway anyway (it will do an IP lookup, 
and no MAC lookup) ?
- section 4.4 raises the same question
- section 5.1 is a lot about the use of overlays and describes how to 
use a VXLAN encapsulation, while section 4 does not (and even assumes in 
many places that LSPs are used for transit between PEs) ; this is 
editorial, but it looks like a fair amount of work is needed to make the 
document overall consistent

Best,

-Thomas



2014-10-06, Bitar, Nabil N:
> L2VPN WG,
>
> This is the start of a 2-week call for adopting the draft “Integrated
> Routing and Bridging in EVPN”,
> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05, as an L2VPN WG
> document. The draft can be found at:
> http://www.ietf.org/id/draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-05.txt
>
>  This draft was well supported in the WG meeting in Toronto, but as
> always we are taking it to the list to decide on WG adoption. Please
> reply to this email indicating your support or objection to adopting
> this draft as a WG document. Substantive comments in addition to
> indicating your support or objection are appreciated.
>
> This call will close on Monday, October 20, 2014.
>
> Thanks, Nabil & Giles
>