Hi Thomas, I agree with you. Will update the document ASAP. Thanks weiguo ________________________________________ From: BESS [[email protected]] on behalf of [email protected] [[email protected]] Sent: Friday, July 24, 2015 22:52 To: Haoweiguo; [email protected] Subject: Re: [bess] comments on draft-hao-bess-inter-nvo3-vpn-optionc
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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
