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 protected]] on behalf of [email protected]
[[email protected]] Sent: Friday, July 24, 2015 15:58 To:
[email protected] 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 protected] https://www.ietf.org/mailman/listinfo/bess
_________________________________________________________________________________________________________________________
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 protected]
https://www.ietf.org/mailman/listinfo/bess
