Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, I agree on the analysis that this proposal is restricted to implementations that supports the chosen encap with non-IANA ports (which may be hard to achieve for instance on hardware implementations, as you suggest), or to context where managing multiple IPs would be operationally

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, OptionC is very useful for DCI use case. In this case, multi-hop EBGP redistributes VN routes between the end NVEs in source and destination Ass, ASBRs do not maintain and distribute the VN routes; a tunnel is built between the end NVEs in source and destination Ass for traffic

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

John, (Cc'ing IDR.) 2015-11-13, John E Drake: I spoke with Eric and Ali and we would like to change both the overlay draft and the tunnel encaps drafts as follows. For the overlay draft, replace this text in section 5.1.3: "If the BGP Encapsulation extended community is not present, then

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Fully agree Tomas’s points (below). Lucy From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of thomas.mo...@orange.com Sent: Friday, November 13, 2015 10:37 AM To: Henderickx, Wim (Wim) Cc: bess@ietf.org Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, 2015-11-13, Henderickx,

[bess] IDR accepting post-WGLC comments on draft-ietf-idr-rtc-no-rt

Hi working group, draft-ietf-idr-rtc-no-rt has passed working group last call in IDR on June 22th and the shepherd noticed that considering that specs being worked on in BESS are the primary use case, comments from BESS working group could have been solicited. Hence, IDR chairs have

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, 2015-11-13, Henderickx, Wim (Wim): Thomas, we need a solution that is implementable and will scale in control/data-plane. As such the solution I outline is standardised today and does not need new extensions in control/data-plane. Hence informational draft and can be implemented if

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

From: Lucy yong > Date: Friday 13 November 2015 at 20:42 To: Wim Henderickx >, Haoweiguo > Cc:

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

VXLAN has a dedicated UDP port and is very clear in the RFC7348 The proposal I gave works with an IP data plane Will write something on what I proposed when I get some time, not soon From: Lucy yong > Date: Friday 13 November 2015 at 17:10 To: Wim

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Hi Lucy, Did you take time to read https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-02 Its used pretty intense by DC orchestration platforms nowadays. Section 5.1 provides more insight. Brgds, G/ Sent using CloudMagic Email

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

From: Lucy yong > Date: Friday 13 November 2015 at 20:15 To: Wim Henderickx >, Haoweiguo > Cc:

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Hi John, Since the tunnel encap draft goes with encap tunnel attribute and there was no deployment of RFC5512, IMO, we should deprecate encapsulation extended community to keep a consistent method. Thus, should the overlay draft states if BGP tunnel encapsulate attribute is not present,

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Thomas, we can discuss forever and someone need to describe requirements, but the current proposal I cannot agree to for the reasons explained. More in-line. From: "thomas.mo...@orange.com" > Organization:

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Wim, VXLAN has a dedicated UDP port and is very clear in the RFC7348 [Lucy] This does not prevent other implementation to use VXLAN with other UDP port. If someone wants to stick on the dedicate UDP port, we can use the src UDP port to achieve that. WH> they are used for entropy, you seem to

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

From: Lucy yong > Date: Friday 13 November 2015 at 21:55 To: Wim Henderickx >, Haoweiguo > Cc:

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

I’ll try to write something by next IETF From: Lucy yong > Date: Friday 13 November 2015 at 22:14 To: Wim Henderickx >, Haoweiguo

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Hi Gunter, Thank you to point to the right section. This overlay draft suggests to use Encapsulation extended community to indicate the type of data plane encapsulation to be used for all EVC routes. But the tunnel encap draft proposes to use tunnel encapsulation attribute + sub-TLVs to

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Wim, VXLAN has a dedicated UDP port and is very clear in the RFC7348 [Lucy] This does not prevent other implementation to use VXLAN with other UDP port. If someone wants to stick on the dedicate UDP port, we can use the src UDP port to achieve that. WH> they are used for entropy, you seem to

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Wim, If the draft adds some description to say that the VxLAN header is decapsulated, and the MAC header is terminated. It is the inner IP data frames to be passed to the MPLS IP-VPNs. Will it clear out the confusion? Linda From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx,

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Lucy, The tunnel encap also describe how to use the extended community, in section 6. Best, -Thomas Lucy yong a écrit Hi Gunter, Thank you to point to the right section. This overlay draft suggests to use Encapsulation extended community to indicate the type of data plane

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com] Sent: Friday, November 13, 2015 2:49 PM To: Lucy yong; Haoweiguo Cc: bess@ietf.org Subject: Re: draft-hao-bess-inter-nvo3-vpn-optionc From: Lucy yong > Date: Friday 13

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Our solution also works with VXLAN-gpe encap. Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderi...@alcatel-lucent.com] Sent: Friday, November 13, 2015 3:17 PM To: Lucy yong; Haoweiguo Cc: bess@ietf.org Subject: Re: draft-hao-bess-inter-nvo3-vpn-optionc I’ll try to write something by next IETF

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Lucy, There are several implementations with shipping code using the RFC5512 bgp tunnel extended community. It cannot be deprecated. Thanks. Jorge From: Idr > on behalf of Lucy yong > Date:

Re: [bess] [Idr] One question about 'draft-ietf-bess-evpn-overlay-02' and draft-ietf-idr-tunnel-encaps-00

Jorge, Thank you let me know. Too bad, we have to live with it. Reagrds, Lucy From: Rabadan, Jorge (Jorge) [mailto:jorge.raba...@alcatel-lucent.com] Sent: Friday, November 13, 2015 3:23 PM To: Lucy yong; thomas.mo...@orange.com; Gunter Van De Velde Cc: Ali Sajassi (sajassi); bess@ietf.org; IDR

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Linda, first of all the draft does not say anything about this and 2nd I am not confused and 3rd I explained the reasons why this does not fly. So read them From: Linda Dunbar > Date: Friday 13 November 2015 at 23:18 To: Wim Henderickx

Re: [bess] One question about 'draft-ietf-bess-evpn-overlay-02'

Thomas, I spoke with Eric and Ali and we would like to change both the overlay draft and the tunnel encaps drafts as follows. For the overlay draft, replace this text in section 5.1.3: "If the BGP Encapsulation extended community is not present, then the default MPLS encapsulation or a