Hi,
I support the WG adoption of this draft.
The following are some editorial and technical comments for consideration:
1. In section 2.1. Generic Reference Model, it said“… The following diagram
shows a DC reference model for network virtualization using Layer3 overlays…”
[Xiaohu] Layer3 overlay -> overlays over layer 3 underlay? Otherwise, the
Layer3 overlay could be mistakenly interpreted as a overlay which offer Layer3
connectivity service:)
2. In section 3.1.4. Tunnel Overlays and Encapsulation options, it said“…
Different IP tunneling options (GRE/L2TP/IPSec) and tunneling options (BGP VPN,
PW, VPLS) can be used are available for tunneling both Ethernet and IP formats.”
[Xiaohu] The IP tunneling options could also include IP (e.g., MPLS-in-IP) and
UDP (e.g., MPLS-in-UDP) tunnel technologies, so it would be better to remain
the word "e.g.," (formerly used in the -01 version). BTW, what did the latter
tunneling options mean by listing BGP VPN, PW and VPLS as examples?
3. In section 3.1.5.2. Address advertisement and tunnel mapping, it said “…As
traffic reaches an ingress NVE, a lookup is performed to determine which tunnel
the packet needs to be sent to. It is then encapsulated with a tunnel header
containing the destination address of the egress overlay node.
[Xiaohu] “egress NVE”(formerly used in the -01 version) is better than “egress
overlay node”, IMHO.
4. In section 3.1.5.2. Address advertisement and tunnel mapping, it said
“…Furthermore, a control plane protocol that carries both MAC and IP addresses
and associated MACs eliminates the need for ARP, and
hence addresses one of the issues with explosive ARP handling.”
[Xiaohu] The statement of " eliminates the need for ARP " is too strong (may
cause some confusion) and the "explosive ARP handling issue" is only associated
with Layer2 NVEs, IMHO. Hence how about say something like“…Furthermore, a
control plane protocol that carries MAC and IP pairs reduces the ARP broadcast
flood across NVEs , and hence addresses the explosive ARP handling issues
associated with those Layer2 NVEs.”
5. In section 4.1. Pros & Cons, it said “…o 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 often the case when multicast is enabled
in the core network.
[Xiaohu] if “this” represents the“unicast tunneling state management ”issue,
this is STILL the case even multicast is enabled in the core;) How about say
something like“…However, if multicast needs to be enabled in the core network,
both edge and intermediate nodes need to maintain multicast states”
6. In section 4.1. Pros & Cons, it said “… o Support of a large number of
virtual network identifiers. Identifiers”
[Xiaohu] virtual network identifiers ->virtual network instances?
7. In section 4.1. Pros & Cons, it said “… o Multicast service scalability.
Multicast support may be
required in the overlay network to address for each tenant
flood containment or efficient multicast handling.”
[Xiaohu] in the overlay network -> in the underlay network?
8. In section 4.1. Pros & Cons, it said “… o 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”
[Xiaohu] The number of combinations of tunnel source and destination addresses
is just one of the factors which affect the load-balancing effect. Hence how
about say something like “…Load balancing in the core may not be optimal as the
hash algorithm performed by the core nodes could not calculate out enough
entropy values to distinguish different tenant traffic flows among a given NVE
pairs”
9. In section 4.2.1. Data plane vs Control plane driven, “…It should be noted
that the amount of state to be distributed is a function of the number of
virtual machines. Different forms of caching can also be utilized to minimize
state distribution among between the various elements.
[Xiaohu] Caching is just one option, IMHO. How about say something like
“…different FIB or RIB reduction approaches can be utilized to address the
routing/forwarding table scalability issues on the data plane and even on the
control plane.”
Best regards,
Xiaohu
发件人: [email protected] [mailto:[email protected]] 代表 LASSERRE, MARC
(MARC)
发送时间: 2012年6月19日 18:07
收件人: Joel M. Halpern; Benson Schliesser
抄送: [email protected]
主题: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02
It was certainly not a deliberate change to imply that L3 was not needed…
Could you suggest which sentence(s) need clarification?
Thanks,
Marc
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Joel M.
Halpern
Sent: Tuesday, June 19, 2012 1:27 AM
To: Benson Schliesser
Cc: [email protected]
Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02
I probably would have sent a private comment, but not bothered the list,
if it was just ToR entities. But the document has changed what the ToR
entities are connect to from being switches / routers to being switches.
It is that change which concerns me, and for which I seek explanation.
Yours,
Joel
PS: I actually agree that the common usage is ToR switch, and the common
deployment is to put L2 devices in that place in the topology.
On 6/18/2012 7:20 PM, Benson Schliesser wrote:
> Hi, Joel.
>
> I would like for the authors to respond with their own comments. But speaking
> only for myself (as an individual):
>
> I think that common usage of the unqualified term "ToR" generally refers to a
> "ToR switch". While the term "ToR" literally refers to a location, and could
> be used to describe a "ToR router" or "ToR storage array" etc, in my
> experience the definition in the framework draft is fairly accurate. (And
> moreover, "switch" isn't necessarily limited to L2... forwarding != routing,
> and encap / tunneling makes this even more confusing.)
>
> But regardless, I think the definition of "ToR" is more-or-less
> inconsequential to the framework. We should get it right, of course. But it's
> more important that we define the NVE correctly. And the NVE could perhaps be
> resident in many types of device, including a device that is not exactly a
> router but does have L3 interface(s).
>
> In the draft, the ToR concept is introduced in an "example of multi-tier DC
> network architecture". I know from experience that there are many possible
> variations on where the access and aggregation layers are located. Do you
> think the authors should make the example more generic, perhaps change ToR to
> "access" or something like that? It's not clear to me what's best here -
> suggestions would be appreciated.
>
> Cheers,
> -Benson
>
>
> On Jun 18, 2012, at 5:07 PM, Joel M. Halpern wrote:
>
>> I sent the comment below to the authors, upon reviewing the diffs from the
>> previous version of this draft. I would appreciate clarification on this
>> issue before the WG adopts this document as a basis for further work:
>>
>> In looking at the latest revision of this draft, the text seems to have
>> moved from describing the devices at the ToR as switches / routers to
>> refering to them as just switches. I can not tell if this change is because
>> the authors understand switch to include IP forwarding device (possibly with
>> IP routing protocol support), or if there is a change in capabilities
>> envisioned.
>> If the former, it should be stated explicitly, since it is an unusual usage.
>> If the later, I am confused as the document then very clearly states that
>> the data center interconnect devices (now referred to in section 1.3 as
>> switches) are L3 capable devices. In fact, the premise of the document
>> requires such L3 capable devices (usually known as routers.) Thus, teh
>> sentence "Core switches are usually Ethernet switches, but can also support
>> routing capabilities" seems very strange. switches != routers. And this
>> document and the WG charter requires those devices to support L3
>> capabilities.
>>
>> Thank you,
>> Joel M. Halpern
>>
>> On 6/18/2012 5: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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
