Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"

["Henderickx, Wim (Wim)" <[e-mail]>]

Indeed we don’t need 2 solutions and what we have documented in the draft is efficient and flexible.

From: John E Drake <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 25 November 2014 16:43
To: Jorge Rabadan <[e-mail]<mailto:[e-mail]>>, Haoweiguo <[e-mail]<mailto:[e-mail]>>, Wim Henderickx <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, sajassi <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"

Precisely.

Yours Irrespectively,

John

From: BESS [mailto:[e-mail]] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Tuesday, November 25, 2014 9:41 AM
To: Haoweiguo; Henderickx, Wim (Wim); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"

Hi Weiguo,

If all the mac routes share the same NVE MAC and tunnel type for the same tenant, you can pack all those routes into a single bgp update. You don’t need a separate extended community per route.
It is actually a very efficient solution.

Thank you.
Jorge

From: Haoweiguo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 25, 2014 at 5:01 AM
To: "Henderickx, Wim (Wim)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"


Hi Wim,

Yes, the design has flexibility. But for most scenarios, we don't need this flexibility, we want to more compact encoding method. If all MAC routes advertised from a egress NVE share same NVE MAC and tunnel type, the two BGP Extended Communities carried with each MAC route is redundant, egress NVE only needs advertise its NVE MAC and tunnel type only once.

I think we had better provide two alternative solutions, one is for flexibility, another one is for compactness. Depending on different scenarios, the vendors can choose one for implementation.

Thanks

weiguo

________________________________
From: Henderickx, Wim (Wim) [[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, November 25, 2014 19:02
To: Haoweiguo; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"
The reason we did this is providing the most flexibility because depending on the use case you need one and not the other. Hence we optimised for flexibility.

From: Haoweiguo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 25 November 2014 10:21
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, sajassi <[e-mail]<mailto:[e-mail]>>
Subject: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00"


Hi Ali and other Co-authors,



In the EVPN IRB draft, Route Type-2 is used to advertise TS's MAC and IP. Two BGP Extended Communities are carried with each RT-2 route. The first community carries tunnel type, the second community carries NVE MAC. In normal case, all RT-2 routes from a remote NVE share same NVE MAC, so in this case the Route information encoding isn't compact.
So a new compact encoding method is introduced as follows:

1. Add tunnel type field in Route Type-2.
2. Introduce a new Route Type to exclusively advertise tunnel type,NVE MAC and L3 VN ID.
3. Ingress NVEs correlate the new Type Route and RT-2 routes advertised from egress NVE to get the NVO3 encapsulation information for inter-subnet IP traffic forwarding.



Maybe there are other more compact methods. I would like to hear your co-authors opinion on this point.

Thanks

weiguo