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

Hi Joege, Wim and John, Thanks for your response. I agree with you, no need to support two encoding solutions. Yes, if multiple mac routes share same NVE MAC and tunnel type, we can pack these routes into a single BGP update message with a extended community, encoding format is comparatively ef

[bess] I-D Action: draft-ietf-l3vpn-mvpn-mldp-nlri-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes Authors : IJsbrand Wijnands

[bess] I-D Action: draft-ietf-l3vpn-mvpn-mldp-nlri-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled Services Working Group of the IETF. Title : Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes Authors : IJsbrand Wijnands

Re: [bess] Last Call Comment draft-ietf-l3vpn-end-system-04.txt

Hi, Adrian - Of course it's possible that I'm wrong - in fact, it would be great if that turns out to be the case. But my suspicion is that it will take material updates (not just editorial) to fix at least one of the issues that I described in my review. And, in-line with some of the feedback

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

Indeed we don’t need 2 solutions and what we have documented in the draft is efficient and flexible. From: John E Drake mailto:jdr...@juniper.net>> Date: Tuesday 25 November 2014 16:43 To: Jorge Rabadan mailto:jorge.raba...@alcatel-lucent.com>>, Haoweiguo mailto:haowei...@huawei.com>>, Wim Hend

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

Precisely. Yours Irrespectively, John From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Jorge) Sent: Tuesday, November 25, 2014 9:41 AM To: Haoweiguo; Henderickx, Wim (Wim); bess@ietf.org; saja...@cisco.com Subject: Re: [bess] A comment and question for the draft "draft-iet

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

Hi, I think this suggestion is ill-considered. We don't want two alternative solutions. Yours Irrespectively, John From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Haoweiguo Sent: Tuesday, November 25, 2014 8:02 AM To: Henderickx, Wim (Wim); bess@ietf.org; saja...@cisco.com Subject: Re:

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 mailto:haowei.

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,

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 mailto:haowei...@huawei.com>> Date: Tuesday 25 November 2014 10:21 To: "bess@ietf.org" mailto:bess@

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

Re: [bess] Two minor last call comments on draft-ietf-l3vpn-acceptown-community-08.txt

Hi Adrian, Adrian Farrel : - Check whether you really need the pre-RFC5378 boilerplate and remove it if possible This was handled with authors during shepherd review: all agreed to grant appropriate rights, and removal of the boilerplate should be done in the next respin. Best, -Thomas

Re: [bess] Last Call Comment draft-ietf-l3vpn-end-system-04.txt

Hi Benson, Thanks for reviewing and commenting. I'm sure the authors will address your points. I'd just like to pick up on the last one... > Otherwise, I'm not sure that this draft is ready for Proposed Standard > publication. I suspect that it may need further review and development > in BES