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

["Ali Sajassi (sajassi)" <[e-mail]>]

Thomas,

Thanks for the review, please refer to my reply inline

On 10/17/14, 9:14 AM, "Thomas Morin" <[e-mail]> wrote:

>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

The document describes two broad approaches for IRB: Asymmetric and
Symmetric. Symmetric approach is the one that expects each node to have
both EVI and VRF. Are you asking for a description of pros/cons of these
two approaches?

>- 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

The two approaches are interoperable. I¹ll add a section to describe the
inter-operability between the two.

>- 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)

There is another draft for this: draft-sajassi-l2vpn-evpn-ipvpn-interop

>- 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 ?

The dependency is minimal and the section 5.2 is just an extension of
section 5.1 where now there are some prefixes sitting behind TS¹s

>
>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) ?

You¹re right. It is more of adding a new MAC header than re-writing the
existing one. I¹ll correct it.

>- section 4.4 raises the same question

OK. I¹ll fix it.

>- 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

I¹ll try to make them consistent.

Thanks again for your review,
Ali

 
>
>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-0
>>5.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
>>
>