Subject: [bess] draft-hao-bess-inter-nvo3-vpn

From: Osama Zia <[email-masked]>
Date: Fri, 10 Apr 2015 22:32:32 +0000

Looking at the minutes, I think there wasn't enough time left for the draft-hao-bess-inter-nvo3-vpn that a discussion could take place.

I will explain the answer to the question that was asked.

In option C the ASBR-W will have to establish EBGP will each NVE in the DC. NVE in some cases could be a ToR and in most cases will be a software gateway in the hypervisor. In any case the number of NVEs can run in thousands. This would mean the other service provider will need to establish EBGP sessions possibly in thousands which is not practical. In this scenario Option-B will provide the architecture to address the scaling issue.

I would like to request additional comments and call for adoption.

Regards,
Osama

From: BESS [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Wednesday, April 8, 2015 2:29 PM
To: [email-masked]
Subject: [bess] Minutes for IETF 92 BESS meeting

The BESS minutes for IETF 92 session are attached (html, pdf).  Should you want to make changes to the minutes, you may edit the etherpad location.  The minutes have been upload to the etherpad for BESS 92 which is at:

http://etherpad.tools.ietf.org:9000/p/notes-ietf-92-bess?useMonospaceFont=true

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Apr 2015 00:41:40 +0200

Hi Osama,

> This would mean the other service provider will need to establish
> EBGP sessions possibly in thousands which is not practical.

That assertion is not correct.

Option C for route distribution scaling uses route reflection in each
cluster therefor eliminating the need to establish more then one (or two
for redundancy) EBGP sessions between data centers or independent clusters.

Cheers,
R.

On Sat, Apr 11, 2015 at 12:32 AM, Osama Zia <[email-masked]> wrote:

>  Looking at the minutes, I think there wasn’t enough time left for the
> draft-hao-bess-inter-nvo3-vpn that a discussion could take place.
>
>
>
> In option C the ASBR-W will have to establish EBGP will each NVE in the
> DC. NVE in some cases could be a ToR and in most cases will be a software
> gateway in the hypervisor. In any case the number of NVEs can run in
> thousands. This would mean the other service provider will need to
> establish EBGP sessions possibly in thousands which is not practical. In
> this scenario Option-B will provide the architecture to address the scaling
> issue.
>
>
>
> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Wednesday, April 8, 2015 2:29 PM
> *To:* [email-masked]
> *Subject:* [bess] Minutes for IETF 92 BESS meeting
>
>
>
>
>
> The BESS minutes for IETF 92 session are attached (html, pdf).  Should you
> want to make changes to the minutes, you may edit the etherpad location.
> The minutes have been upload to the etherpad for BESS 92 which is at:
>
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
>

---

From: Osama Zia <[email-masked]>
Date: Sat, 11 Apr 2015 02:15:43 +0000

I was talking about the base model. You are right that we may solve the scalability problem by introducing RR.

However, with the proposed solution we achieve the same thing without using RR.

Regards,
Osama

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, April 10, 2015 3:42 PM
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Hi Osama,

Option C for route distribution scaling uses route reflection in each cluster therefor eliminating the need to establish more then one (or two for redundancy) EBGP sessions between data centers or independent clusters.

Cheers,
R.

On Sat, Apr 11, 2015 at 12:32 AM, Osama Zia <[email-masked]<mailto:[email-masked]>> wrote:
Looking at the minutes, I think there wasn’t enough time left for the draft-hao-bess-inter-nvo3-vpn that a discussion could take place.

Regards,
Osama

From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Susan Hares
Sent: Wednesday, April 8, 2015 2:29 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [bess] Minutes for IETF 92 BESS meeting

Sue Hares

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Apr 2015 12:02:36 +0200

Osama,

To the best of my knowledge RRs are pretty base elements in BGP :)

If you have 1000 of endpoints within any data center please kindly observe
that it is not only ASBR option B information that they need (even if you
would establish 1000 IBGP vpnv4/6 sessions to such border router.

Such endpoints also need to exchange information between themselves and
here again RRs come to the rescue (at least for the time being).

So I recommend to look not at one particular function you are pushing, but
at entire picture then evaluate the need for RRs likely with RTC or not.

Best,
r.

On Sat, Apr 11, 2015 at 4:15 AM, Osama Zia <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, April 10, 2015 3:42 PM
> *To:* Osama Zia
> *Cc:* [email-masked]
> *Subject:* Re: [bess] draft-hao-bess-inter-nvo3-vpn
>
>
>
> Hi Osama,
>
>
>

---

From: Osama Zia <[email-masked]>
Date: Mon, 13 Apr 2015 13:13:49 +0000

Robert,

I am not sure if you have read the draft. The discussion here is not about using RR. It is about looking at how option B is used in the context of inter-as where both sides are not using MPLS. I would argue that in this solution option-C provides no real benefit. For scaling purposes we are already proposing a centralized solution.

Thanks,
Osama

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, April 11, 2015 3:03 AM
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Osama,

If you have 1000 of endpoints within any data center please kindly observe that it is not only ASBR option B information that they need (even if you would establish 1000 IBGP vpnv4/6 sessions to such border router.

Such endpoints also need to exchange information between themselves and here again RRs come to the rescue (at least for the time being).

So I recommend to look not at one particular function you are pushing, but at entire picture then evaluate the need for RRs likely with RTC or not.

Best,
r.

On Sat, Apr 11, 2015 at 4:15 AM, Osama Zia <[email-masked]<mailto:[email-masked]>> wrote:
I was talking about the base model. You are right that we may solve the scalability problem by introducing RR.

Regards,
Osama

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Friday, April 10, 2015 3:42 PM
To: Osama Zia
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Apr 2015 16:41:47 +0200

Osama,

Yes I have read the draft. It is describing a solution to problem which
does not exist in practice.

Ref: http://www.opencontrail.org/

The crux of the issue you are solving is here:

   Each NVE is a BGP speaker. Operator may configure single and unique
   VNID for each tenant network on all NVEs or configure NVEs to
   locally allocate VNID for each VRF on the NVEs, the VNID is called
   VNID-t.

If you would not mess up RFC4364 with VNIDs and use vanilla MPLS label as a
demux you would not require any additional mapping at the ASBRs hence your
option B as well as option C would work seamlessly. All over plain IP CLOS
fabric + any type of WAN.

That is my point.

Best,
r.

On Mon, Apr 13, 2015 at 3:13 PM, Osama Zia <[email-masked]> wrote:

>  Robert,
>
>
>
> I am not sure if you have read the draft. The discussion here is not about
> using RR. It is about looking at how option B is used in the context of
> inter-as where both sides are not using MPLS. I would argue that in this
> solution option-C provides no real benefit. For scaling purposes we are
> already proposing a centralized solution.
>
>
>
> Thanks,
>
> Osama
>
>
>
>
>
> *Sent:* Saturday, April 11, 2015 3:03 AM
>
> *To:* Osama Zia
> *Cc:* [email-masked]

---

From: Osama Zia <[email-masked]>
Date: Mon, 13 Apr 2015 15:32:01 +0000

Okay, so help me understand your point of view here.

Are you suggesting to use labels in the CLOS network instead of any other encap mechanism and use inter-as options in their native form?

Regards,
Osama

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, April 13, 2015 7:42 AM
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Osama,

Yes I have read the draft. It is describing a solution to problem which does not exist in practice.

   VNID-t.

If you would not mess up RFC4364 with VNIDs and use vanilla MPLS label as a demux you would not require any additional mapping at the ASBRs hence your option B as well as option C would work seamlessly. All over plain IP CLOS fabric + any type of WAN.

That is my point.

Best,
r.

On Mon, Apr 13, 2015 at 3:13 PM, Osama Zia <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Thanks,
Osama

To: Osama Zia

Osama,

Best,
r.

Regards,
Osama

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Apr 2015 17:48:59 +0200

> Are you suggesting to use labels in the CLOS network

Nope ... please ...

Transport of RFC4364 can be realized with IPv4 or IPv6 just fine.

Please see:

MPLS in IP or GRE
https://tools.ietf.org/html/rfc4023

MPLS in UDP
https://tools.ietf.org/html/rfc7510

> instead of any other encap mechanism and use inter-as options in their
native form?

Please observe that MPLS in RFC4364 is used just for demux to tenants.
Functionally it is identical equivalent to VNID hence inventing new
terminology seems in odds with deployed best practices.

MPLS for transport on the other hand which some RFC4364 deployments use has
no use in IP based CLOS fabric (of course provided that the underlay IP
numbering is done with a bit consciousness :)

So it is key to understand that transport and tenant demux spaces are
completely orthogonal and while some mix them they do not overlap
functionally at all.

Cheers,
R.

On Mon, Apr 13, 2015 at 5:32 PM, Osama Zia <[email-masked]> wrote:

> Are you suggesting to use labels in the CLOS network instead of any other
> encap mechanism and use inter-as options in their native form?
>
>
>
> Regards,
>
> Osama
>
>
>
> *Sent:* Monday, April 13, 2015 7:42 AM
>
> *To:* Osama Zia
> *Cc:* [email-masked]
> If you would not mess up RFC4364 with VNIDs and use vanilla MPLS label as
> a demux you would not require any additional mapping at the ASBRs hence
> your option B as well as option C would work seamlessly. All over plain IP
> CLOS fabric + any type of WAN.
>
>
>
> That is my point.
>
>
>
> Best,
>
> r.
>
>
>
>
>
>
>

---

From: Osama Zia <[email-masked]>
Date: Mon, 13 Apr 2015 17:12:23 +0000

Thanks for the clarification Robert.

MPLS has been around for quite a while, there are definitely solutions out there like the ones you have mentioned below. However, there are quite a number of deployments out there that do not use MPLS. In fact, if you look at the meeting minutes for NVO3 in IETF-91, you will observe that MPLS was deferred to other WGs and that led to new overlay technologies like GUE, GENEVE apart from existing VXLAN. BTW…NVO3 have just adopted them as working group documents.

http://tools.ietf.org/wg/nvo3/minutes?item=minutes-91-nvo3.html

I would also like to clarify that VNID is not something we have invented for the purpose of this draft. It is already out there and we are providing a solution that can bridge these two technologies.

Regards,
Osama

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, April 13, 2015 8:49 AM
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Nope ... please ...

Please see:

MPLS in IP or GRE

MPLS in UDP

> instead of any other encap mechanism and use inter-as options in their native form?

Please observe that MPLS in RFC4364 is used just for demux to tenants. Functionally it is identical equivalent to VNID hence inventing new terminology seems in odds with deployed best practices.

MPLS for transport on the other hand which some RFC4364 deployments use has no use in IP based CLOS fabric (of course provided that the underlay IP numbering is done with a bit consciousness :)

So it is key to understand that transport and tenant demux spaces are completely orthogonal and while some mix them they do not overlap functionally at all.

Cheers,
R.

On Mon, Apr 13, 2015 at 5:32 PM, Osama Zia <[email-masked]<mailto:[email-masked]>> wrote:
Okay, so help me understand your point of view here.

Regards,
Osama

To: Osama Zia

Osama,

   VNID-t.

That is my point.

Best,
r.

Thanks,
Osama

To: Osama Zia

Osama,

Best,
r.

Regards,
Osama

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 13 Apr 2015 19:24:46 +0200

Osama,

To be very clear ... I am not stating that this draft is inventing VNIDs ..
it is NVO3 group strategy I am questioning here :)

Also - as I am sure you know - if you look at other communities they also
have their own preferences as to tenant demux IDs and encapsulations.

All I am trying to point out that the exact functionality this draft
describes is already available and deployed without need to invent new
gateway behaviors if you happen to use in your data center one of the open
source solutions which uses IP forwarding with 4364 as tenant demux.

Moreover it works fine today with all 4364 inter-as options A, B, C or even
D leave alone other less popular flavors like C+/C- ....

Hence IMO one should really think why would we not use it and what other
then compliance with NVO3 do we really gain here technically ?

Best,
r.

On Mon, Apr 13, 2015 at 7:12 PM, Osama Zia <[email-masked]> wrote:

> MPLS has been around for quite a while, there are definitely solutions out
> there like the ones you have mentioned below. However, there are quite a
> number of deployments out there that do not use MPLS. In fact, if you look
> at the meeting minutes for NVO3 in IETF-91, you will observe that MPLS was
> deferred to other WGs and that led to new overlay technologies like GUE,
> GENEVE apart from existing VXLAN. BTW…NVO3 have just adopted them as
> working group documents.
>
>
>
> I would also like to clarify that VNID is not something we have invented
> for the purpose of this draft. It is already out there and we are providing
> a solution that can bridge these two technologies.
>
>
>
>
>
> Regards,
>
> Osama
>
>
>
>
>
> *Sent:* Monday, April 13, 2015 8:49 AM
>
> *To:* Osama Zia
> *Cc:* [email-masked]
> MPLS for transport on the other hand which some RFC4364 deployments use
> has no use in IP based CLOS fabric (of course provided that the underlay IP

---

From: Osama Zia <[email-masked]>
Date: Mon, 13 Apr 2015 17:29:54 +0000

Robert,

I respect your opinion and would urge you to take it up in NVO3. Maybe it’s too late but never too late to ask ☺

This solution is based on what is out there and published as RFC.

Regards,
Osama

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, April 13, 2015 10:25 AM
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Osama,

To be very clear ... I am not stating that this draft is inventing VNIDs .. it is NVO3 group strategy I am questioning here :)

Also - as I am sure you know - if you look at other communities they also have their own preferences as to tenant demux IDs and encapsulations.

All I am trying to point out that the exact functionality this draft describes is already available and deployed without need to invent new gateway behaviors if you happen to use in your data center one of the open source solutions which uses IP forwarding with 4364 as tenant demux.

Moreover it works fine today with all 4364 inter-as options A, B, C or even D leave alone other less popular flavors like C+/C- ....

Hence IMO one should really think why would we not use it and what other then compliance with NVO3 do we really gain here technically ?

Best,
r.

On Mon, Apr 13, 2015 at 7:12 PM, Osama Zia <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the clarification Robert.

Regards,
Osama

To: Osama Zia

Nope ... please ...

Please see:

MPLS in IP or GRE

MPLS in UDP

Cheers,
R.

Regards,
Osama

To: Osama Zia

Osama,

   VNID-t.

That is my point.

Best,
r.

Thanks,
Osama

To: Osama Zia

Osama,

Best,
r.

Regards,
Osama

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 14 Apr 2015 14:02:06 +0000

> On Apr 13, 2015, at 11:48 AM, Robert Raszuk <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/rfc4023 <https://tools.ietf.org/html/rfc4023>
> 
> MPLS in UDP
> https://tools.ietf.org/html/rfc7510 <https://tools.ietf.org/html/rfc7510>
> 

And MPLS in L2TPv3:

https://tools.ietf.org/html/rfc4817 <https://tools.ietf.org/html/rfc4817>

Thanks,

— Carlos.

---

From: Haoweiguo <[email-masked]>
Date: Thu, 16 Apr 2015 01:09:10 +0000

Hi Robert,

Just as Osama pointed out, this draft is to stitch NVO3 tunnel and MPLS VPN Tunnel at DC gateway, it is a transformed option-B defined in RFC4364 which is used for heterogenious network interworking.

As i have known, currently no hardware supports the heterogenious option-B interconnection feature, so we think it's necessary to define the behaviour on DC gateway to provide reference for the industry.

Thanks,

weiguo

________________________________

From: BESS [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Tuesday, April 14, 2015 1:24
To: Osama Zia
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Osama,

Best,
r.

Regards,
Osama

To: Osama Zia

Nope ... please ...

Please see:

MPLS in IP or GRE

MPLS in UDP

Cheers,
R.

Regards,
Osama

To: Osama Zia

Osama,

   VNID-t.

That is my point.

Best,
r.

Thanks,
Osama

To: Osama Zia

Osama,

Best,
r.

Regards,
Osama

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares

---

From: Osama Zia <[email-masked]>
Date: Tue, 21 Apr 2015 19:57:08 +0000

I would like to welcome any further comments on the draft.

Chairs, I would also like to request for adoption.

Regards,
Osama

From: BESS [mailto:[email-masked]] On Behalf Of Osama Zia
Sent: Monday, April 13, 2015 10:30 AM
To: Robert Raszuk
Cc: [email-masked]
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Robert,

Regards,
Osama

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, April 13, 2015 10:25 AM
To: Osama Zia
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn

Osama,

Best,
r.

Regards,
Osama

To: Osama Zia

Nope ... please ...

Please see:

MPLS in IP or GRE

MPLS in UDP

Cheers,
R.

Regards,
Osama

To: Osama Zia

Osama,

   VNID-t.

That is my point.

Best,
r.

Thanks,
Osama

To: Osama Zia

Osama,

Best,
r.

Regards,
Osama

Hi Osama,

Cheers,
R.

Regards,
Osama

Sue Hares