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
