Hi Marc,
Thank you for your response!
Sorry for the non-prompt reply from my side, I'm traveling these weeks.
Please find some notes in-line.
Best regards,
Janos
On 7/2/2012 3:36 PM, LASSERRE, MARC (MARC) wrote:
Janos,
See my comments below.
Thanks,
Marc
-----Original Message-----
From:[email protected] [mailto:[email protected]] On
Behalf Of János Farkas
Sent: Friday, June 29, 2012 3:35 PM
To:[email protected]
Subject: Re: [nvo3] call for adoption:
draft-lasserre-nvo3-framework-02
Hi,
I have some comments to the draft. Please find them below
under the section header they belong to.
Snipped
4.1. Pros& Cons
"Unicast tunneling state management is handled at the edge of the
network. Intermediate transport nodes are unaware of such state. Note
that this is not the case when multicast is enabled in the
core network."
This statement may depend on the solution applied or the
terms used here
might not be entirely clear. Even if the core only provides point to
point tunnels, then those tunnels have to be established in the core,
hence maintenance of some states is required in the core
nodes. If the
core provides multipoint tunnels as well, then of course more
state is
required to maintain a multipoint tunnel in the core than a point to
point tunnel. The type of connectivity that needs to be
provided by the
core depends on the actual location of VMs belonging to the same
group/tenant. If VMs of a group are only behind two NVEs, then it is
enough to provide a point to point connectivity/tunnel by the core
independently of whether the traffic among the VMs is unicast or
multicast. If VMs of a group are behind more than two NVEs, then the
core has to provide a multipoint connectivity between those NVEs; the
way it is provided is solution dependent.
This is a generic statement about the fact no tunnel state is mantained in core
nodes for unicast tunnels - unlike mutlicast state.
It was just not entirely clear to me from the text itself. The reason
might be somewhat different use of terminology.
I think, in general, a tunnel is either point-to-point or multipiont
(including point-to-multipoint) and not unicast or multicast. A tunnel
then may carry unicast and multicast VM (user) traffic. Tunnel states
are maintained in the core, less states for a point-to-point tunnel,
than for a multipoint, but both require some states. For VM traffic
carried in a point-to-point tunnel, there is no additional forwarding
state required, but the tunnel state is enough. In case of multipoint
tunnels, however, forwarding state is also required for optimal
forwarding aside the tunnel state, except for multicast traffic
involving each end point (NVE) of the tunnel. (In some solutions tunnel
and forwarding state may 'collapse', they may be handled together in a
non-separable way.)
I'm not sure which terminology is the cleaner and easier to understand
here, please go for that. (I just thought that a framework goes for the
generic one.)
"Load balancing may not be optimal as the hash algorithm may not work
well due to the limited number of combinations of tunnel source and
destination addresses"
There are other possibilities of load balancing besides hash.
It would be better to update the sentence to "Hash-based load
balancing
may not be optimal as the hash algorithm may not work well due to the
limited number of combinations of tunnel source and
destination addresses"
Fine.
4.2.1. Data plane vs Control plane driven
"Multicasting in the core network for dynamic learning can lead to
significant scalability limitations."
Multicast should be kept within the virtual network even while it is
transmitted in the core, which can be aided by service
auto-discovery.
Having these features, the scalability limitations should not be
significant.
How about "may lead to " instead of "can lead to" then?
Sounds good. Though, the sentence might be also extended to give some
more details on the scalability limitations, e.g. s.g. like
"Multicasting in the core network for dynamic learning may lead to
scalability limitations, which can be avoided by optimized multicast."
What I mean under "optimized multicast" is that only those NVEs receive
the multicast that really need to. Auto-dicsovery may help a lot here.
"Specific forwarding rules must be enforced to prevent loops from
happening. This can be achieved using a spanning tree protocol or a
shortest path tree, or using a split-horizon mesh."
"a spanning tree protocol" is not the same category as "a
shortest path
tree" or "split horizon mesh" here. The first one is a
protocol, while
the latter two are forwarding rules as said in the beginning of the
sentence.
It would be better to remove "protocol" from the sentence or
resolve it
another way.
Fine
"the amount of state to be distributed is a function of the number of
virtual machines."
This 'function' is not that easy to draw, it depends on a lot of
factors, furthermore it is most likely that the state to be
maintained
does not depend on the way the state is installed, i.e. it is
the same
both for the control and the data plane driven cases.
For example, there is no need to maintain any state if the
connectivity
is point to point through the core, i.e. a group of VMs are
only behind
two NVEs.
We can take a look on mapping tables e.g. by having an
example of three
NVEs: NVE-A, NVE-B and NVE-C providing the connectivity
through the core
for a group of VMs. If VM1 behind NVE-A communicates with VN2 behind
NVE-B, then the mapping table in NVE-A is VN2->NVE-B, i.e.
NVE-A has to
address the packets to NVE-B for the transmission through the core if
any VM behind NVE-A sends them to VN-2. Similarly the mapping
table is
VN1->NVE-A in NVE-B. It does not matter how these mapping tables are
maintained, the same states should be there. That is, states are the
same both for data and control plane driven mapping tables.
If state here means a mapping state, then it would be better
to update
the cited sentence. Moreover, maybe this section is not the best
location for it. One way out is to remove the paragraph.
Alternatively
it can be updated, e.g. "the amount of state to be
distributed depends
on the network scenario, the grouping and the number of
virtual machines."
If the state means something else, then it would be useful to clarify
what exactly meant here.
Fine. I do not have a problem either removing this sentence or updating it to "the
amount of state is dependent upon network topology and the number of VMs".
Removal seems simpler to me. It is not easy to incorporate in one
sentence what the amount of state depends on. The updated version of the
sentence looks better. Further update might be possible if you would
like to keep the sentence, e.g. "the amount of state is dependent upon
network topology and the number of VMs and the traffic among them."
4.2.6. Interaction between network overlays and underlays
Is it really the case that the DC provider wants to give
visibility of
its infrastructure to its Tenants? Isn't it that the Tenant gets is
overlay and the underlay should be completely hidden? For example, if
the Tenant buys L2aaS, does/should it bother with the fact that L2
overlay happens to be provided by an L3 underlay? Maybe the
direction of
SLAs would be more appropriate here than providing visibility of the
underlay.
This is not about providing visibility to tenants. It is about running multiple
overlay services over a common underlay.
I know that the main point here is to have several overlays on top of
the same infrastructure.
Nonetheless, this section says "Better visibility between overlays and
underlays or their controllers"
Clarification might be useful then if the goal is not providing
visibility to the tenants.
Best regards,
János
On 6/18/2012 11:51 PM, Benson Schliesser wrote:
Dear NVO3 Participants -
This message begins a two week Call for Adoption of
http://tools.ietf.org/html/draft-lasserre-nvo3-framework-02
by the NVO3 working group, ending on 02-July-2012.
Please respond to the NVO3 mailing list with any statements
of approval or disapproval, along with any additional
comments that might explain your position. Also, if any NVO3
participant is aware of IPR associated with this draft,
please inform the mailing list and/or the NVO3 chairs.
Thanks,
-Benson& Matthew
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
