Hi Thomas,
2012-07-09, Thomas Narten:
>> By and large, this idea of a global VNID carried in the dataplane looks
>> to me as quite orthogonal to the explanation of the benefits of an
>> overlay solution.
>
> OK.
>
>> I think the text should go straight to the fact that using an overlay
>> allows to build a large enough number of virtual network instances
>> independently of current VLAN size limitation. This is true whether a
>> globally significant or locally significant id is used, so that aspect
>> is I think better to kept out of that section.
>
> OK.
>
> How about:
>
> The use of a sufficiently large VNID would eliminate current VLAN
> size limitations. This VNID can be carried in the data plane
> along with the packet. Adding an overlay header provides a place
> to carry this VNID.
I still think that we introduce something (global id in the dataplane)
that does not relate directly to the benefits of an overlay approach.
Strictly speaking, if one server never has more than 2**12 virtual
networks bound onto it, then a 12 bit demultiplexor in the dataplane
would be enough.
The size of the "VNID in the control plane" is actually the factor that
will make the difference.
What about:
The use of a sufficiently large VNID, present in the overlay
control plane and possibly also in the dataplane would eliminate
current VLAN size limitations.
>>> Communication between devices attached to a virtual network
>>> and devices connected to non-virtualized networks is handled
>>> architecturally by having specialized gateway devices that
>>> receive packets from a virtualized network, process them as
>>> appropriate, and forward them on to non-virtualized networks
>>> (and vice versa). A simple implementation could do as little
>>> as forward packets to/from a virtual network, while more
>>> sophisticated gateways could include full router
>>> functionality, load balancing or firewall support, etc., or
>>> have the overlay encapsulation/decapsulation functionality
>>> implemented with hardware assist for efficiency.
>
>> The above does not reflect the fact that external networks can also be
>> virtualized, and that part of the problem of designing NVO3 is so that
>> mapping an NVO3 virtual network to an external virtual network can be
>> efficient, ie. better than a VLAN-based intermediate handoff.
>
> Are you talking specifically about the case of having a single device
> take NVO3 traffic on (say) one interface and send it out on another
> (different) virtualized network (e.g., a VPN), all in one device?
A VPN is one example.
Virtualized L4-L7 service instances would be another.
> That's (IMO) clearly allowed and expected to be supported. Are you
> asking that this example be made explicitely in the text?
Yes, because so this efficiently is I think part of the problem to solve.
-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,
France Telecom - 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, France Telecom - Orange is not liable for messages
that have been modified, changed or falsified.
Thank you.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
