Subject: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

From: <[email-masked]>
Date: Thu, 23 Jul 2015 14:34:16 +0200

Hi,

(Without my chair hat,) I have the following comments to offer on 
draft-hao-bess-inter-nvo3-vpn-optionc-01.

I think the proposal has a merit in that it defines how to do Option C 
in a context where we want one of the AS to use an IP transit rather 
than MPLS, and this is done preserving the scaling advantages of Option 
C over Option B for ASBRs.

I have a few comments though. on things that would deserve to be improved.

The term multi-hop EBGP designates an eBGP session between peers 
separated by multiple IP hops, in an inter-AS Option C context, sessions 
between RRs of the two ASes are multi-hop eBGP, but the session between 
ASBRs to carry RFC3107 routes is *not* multi-hop. However, your draft 
wrongly refers to sessions between PEs as "multi-hop EBGP", which I 
found very confusing.  (Section 4, Section 5.1)

Having to configure as many IPs on ASBR-d as there are PEs in the WAN 
seems to me as being a very strong drawback. I think that it would be 
better to use a combination of one ore more ASBR-d IP address and 
multiple destination UDP ports, to reduce the configuration overhead on 
ASBR-d related to having multiple addresses. With multiple UDP ports one 
IP will be enough for large number of PEs (e.g among the 64k possible 
ports, you can easily take a few thousands and cover a deployment with 
thousands of PEs).  For an MPLS-over-GRE encap, you could use the GRE 
Key field instead. The only encap which I think cannot be addressed this 
way and would thus require multiple IP destination addresses would be 
NVGRE (because it already uses the GRE Key field).

Last, to setup the overlay segment of the PE-to-NVE transit path, I 
think that, rather than introducing a new SAFI, it would make sense to 
use a plain IP route to /32 of each WAN PE advertising an IPVPN route, 
associated to a BGP tunnel encap attribute indicating which encap to 
use, with which destination IP address and which UDP Port / GRE key to 
use.  (this combination of BGP Tunnel Encap attribute with a 1/1 
AFI/SAFI is not allowed by RFC5512, but will be allowed assuming 
draft-rosen-idr-tunnel-encaps progresses in IDR).

Best,

-Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Haoweiguo <[email-masked]>
Date: Fri, 24 Jul 2015 06:58:02 +0000

Hi Thomas,
Thanks for your good comments and suggestions. Pls see inline with [weiguo].
weiguo

________________________________________
From: BESS [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, July 23, 2015 20:34
To: BESS; [email-masked]
Subject: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

Hi,

[weiguo]: Ok. The relevant discription will be modified.

[weiguo]: For VXLAN encapsulation, the destination UDP port is fixed, so it's hard for us to allocate different UDP port for each remote PE. Because normally remote PEs number is not so large, so the IP addresses on ASBR-d won't consume so much. 

[weiguo]: OK. The ASBR-d announces remote PE ip address/32 combined with local VXLAN/NVGRE tunnel attibutes to NVEs, the NVEs use the tunnel attribute for outer layer encapsulation. 

Best,

-Thomas

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

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 09:58:51 +0200

Hi Weiguo,

Haoweiguo :
> Thomas:
> [weiguo]: For VXLAN encapsulation, the destination UDP port is fixed, so it's hard for us to allocate different UDP port for each remote PE.

While an IANA assigned port is available as a default, nothing prevents 
a box from mapping a range of UDP ports so that any port in this range 
is processed as VXLAN.    As long as you have a way to let the sender 
know about which port to use, this is fine.  The good news is that 
draft-rosen-idr-tunnel-encaps introduces a way to advertise which port 
to use when the port is other than the standard.

>   Because normally remote PEs number is not so large, so the IP addresses on ASBR-d won't consume so much.

Networks with thousands of PEs are not uncommon, and this is a number 
high enough to make allocating and configuring all these IPs a 
significant drawback.   By comparison playing with UDP ports is cheap 
and easy.

-Thomas

---

From: Haoweiguo <[email-masked]>
Date: Fri, 24 Jul 2015 08:49:44 +0000

Thanks Thomas. I will accept your suggestion about allocating UDP port approach on ASBR-d to save IP address space.  However,  if the operators want to use IANA assigned VXLAN fixed port,  the IP address allocating approach maybe still should be used. So do you think we should provide two options(allocating UDP port or independant IP address for each remote PE on ASBR-d) and one of the options will to be a default choice?
weiguo
________________________________________
From: BESS [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Friday, July 24, 2015 15:58
To: [email-masked]
Subject: Re: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

Hi Weiguo,

-Thomas

---

From: <[email-masked]>
Date: Fri, 24 Jul 2015 16:52:05 +0200

Weiguo,

2015-07-24, Haoweiguo:
> I will accept your suggestion about allocating UDP
> port approach on ASBR-d to save IP address space.  However,  if the
> operators want to use IANA assigned VXLAN fixed port,  the IP address
> allocating approach maybe still should be used.

Yes, it is ok to say that ASBR-d can be configured by the operator to 
use only the standard port for the encap.

> So do you think we
> should provide two options(allocating UDP port or independant IP
> address for each remote PE on ASBR-d) and one of the options will to
> be a default choice?

To allow proper interop on a solution that does not have the drawback of 
configuring a potentially large set of IPs, I would suggest saying "For 
UDP based overlay encapsulations, NVEs SHOULD support sending traffic 
with a variable UDP port as possibly specified in received routes, and 
for GRE-based encaps at the exception of NVGRE, SHOULD support sending 
traffic with a variable Key field  as possibly specified in received 
routes".

What is the default then depends on the ASBR-d behavior, so, unless 
range of IP addresses is configured for stitching with LSPs, I think the 
default should be to use a range of UDP ports (what is the default value 
for this range can be implementation specific).

-Thomas

> ________________________________________ From: BESS
> [[email-masked]] on behalf of [email-masked]
> [[email-masked]] Sent: Friday, July 24, 2015 15:58 To:
> [email-masked] Subject: Re: [bess] comments on
> draft-hao-bess-inter-nvo3-vpn-optionc
>
> Hi Weiguo,
>
> Haoweiguo :
>> Thomas:
>>> Having to configure as many IPs on ASBR-d as there are PEs in the
>>> WAN seems to me as being a very strong drawback. I think that it
>>> would be better to use a combination of one ore more ASBR-d IP
>>> address and multiple destination UDP ports, to reduce the
>>> configuration overhead on ASBR-d related to having multiple
>>> addresses. With multiple UDP ports one IP will be enough for
>>> large number of PEs (e.g among the 64k possible ports, you can
>>> easily take a few thousands and cover a deployment with thousands
>>> of PEs).  For an MPLS-over-GRE encap, you could use the GRE Key
>>> field instead. The only encap which I think cannot be addressed
>>> this way and would thus require multiple IP destination addresses
>>> would be NVGRE (because it already uses the GRE Key field).
>>
>> [weiguo]: For VXLAN encapsulation, the destination UDP port is
>> fixed, so it's hard for us to allocate different UDP port for each
>> remote PE.
>
> While an IANA assigned port is available as a default, nothing
> prevents a box from mapping a range of UDP ports so that any port in
> this range is processed as VXLAN.    As long as you have a way to let
> the sender know about which port to use, this is fine.  The good news
> is that draft-rosen-idr-tunnel-encaps introduces a way to advertise
> which port to use when the port is other than the standard.
>
>> Because normally remote PEs number is not so large, so the IP
>> addresses on ASBR-d won't consume so much.
>
> Networks with thousands of PEs are not uncommon, and this is a
> number high enough to make allocating and configuring all these IPs
> a significant drawback.   By comparison playing with UDP ports is
> cheap and easy.
>
> -Thomas
>
>
>  Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation. If you have
> received this email in error, please notify the sender and delete
> this message and its attachments. As emails may be altered, Orange is
> not liable for messages that have been modified, changed or
> falsified. Thank you.
>
> _______________________________________________ BESS mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/bess
>

---

From: Haoweiguo <[email-masked]>
Date: Sat, 25 Jul 2015 10:50:18 +0000

Hi Thomas,
I agree with you. Will update the document ASAP.
Thanks
weiguo

________________________________________
From: BESS [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Friday, July 24, 2015 22:52
To: Haoweiguo; [email-masked]
Subject: Re: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc

Weiguo,

-Thomas