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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
