Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 13 Aug 2016 16:41:49 +0200

Review for the document as per your request.

I would like to thanks the authors and the WG for this work.

In general this document is about data centres DCs, and using IP
architecture, so this document is an architecture of the overlays above
such network purpose. The management among both architectures is very
essential for the best DC performance. The IP architecture is implemented
in the network infrastructure but the NVO3 architecture is a Software
Defined Network SDN architecture. Furthermore, DC virtualization has many
advantages but increases complexity in all standard design. However, the
draft needs more defining of the connection between the both architectures
(i.e, implemented and software-defined) needs to be clarified in terms of
interactions in both planes (data and control).

 My comments are as below, and suggestions are with the AB sign:-

Comment-1
The approach of the document needs to be more clear, as mentioned in the
introduction:-

introduction>

It should be possible to build and implement individual components in isolation
and have them work with other components with no changes to other
components.

AB>amend> It should be possible to standardize and implement individual
components in isolation and have them work with other components with no
changes to other components.

introduction> This document differs from the framework document in that it
doesn’t attempt to cover all possible approaches within the general design
space. Rather, it describes one particular approach.

AB>  The introduction needs to answer:- Why you are having one such
approach as mentioned above?

AB> If this document is for special approach, this needs to be for special
use case which needs to be mentioned in title, because just saying '' an
architecture'' is not clear.

Comment-2

AB> When defining an architecture we need to define all general components,
connections, protocols, frames/packets, and services. VN and NV are
explained used in this document, but still not well defined in terms of
requirements, design-approaches, and network programming. The document does
not define general/special nodes, links, and interfaces of such virtualized
networks per control-data (d/c) plane approach. The document does not
include virtual DCs and SANs in the definitions. However, looking into
other documents under progress worked by the NVO3-WG, it is recommended
that this architecture document should be referencing such work in
progress.

Comment-3

The document needs to clarify the NVO3 architecture is it centralised,
distributed, or hierarchical distributed for each d/c plane.

Comment-4

How to identify each VM and configure its policy. or how to identify
virtual DCs which have SAN and LAN. How to configure, Links that have LAN
traffic and links that have SAN traffic, and links that do both traffic.  Is
it using VN tagging only?

comment-5

Virtualization is for security, but why the nvo3-architecture addresses are
using MAC and IP which is not good for security. Also this node
identification was not mentioned in security consideration.

Comment-6

The ip architecture underlying needs to include IPv4 and/or IPv6, in one
section you mention TTL which is only for IPv4, but what about IPv6.

comment-7

Figure 1 must show the TSI as it showed the TS!!

Figure 1 should say: L3 overlay networks, instead of: L3 overlay network,
or mentioning that there may be VNs and NVDs. Also to show local and remote
TSs and remote NVE.

comment-8

section 3.1.1> To provide complete virtualization the network should
provide similar properties to the computing layer. The network
infrastructure should be able to support arbitrary network topologies and
addressing schemes. Each tenant should have the ability to configure both
the computing nodes and the network simultaneously.

AB> IPv6 cannot be used by the VMs of a tenant if the underlying physical
forwarding devices support only IPv4. The section should be clear about
this issue.

comment-9

section 3.1.1> Just as in the case with ports on Ethernet switches, a
number of settings could be imagined.

AB> why use the word, imagined. I suggest to change it.

comment-10

In security section, it was not taken consideration/recommendation of
using the IPsec technology, why.

Editorial comments:

draft>Tenant System Identifier

AB> amend> Tenant System Interface

draft>Domains be funneled through a particular device

AB> amend> Domains be Tunneled through a particular device

draft>Packets

AB>Change to> NVO3 packets

AB> You mention also TS packets. so that TS packet could be any protocol
packet.

Thank you, and sorry for the late submit of the date 12 August, it was due
to many electricity breaks.

best regards

AB

kk

On Sat, Jul 30, 2016 at 1:06 AM, The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Network Virtualization Overlays
> WG (nvo3) to consider the following document:
> - 'An Architecture for Data Center Network Virtualization Overlays
> (NVO3)'
>   <draft-ietf-nvo3-arch-06.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2016-08-12. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document presents a high-level overview architecture for
>    building data center network virtualization overlay (NVO3) networks.
>    The architecture is given at a high-level, showing the major
>    components of an overall system.  An important goal is to divide the
>    space into individual smaller components that can be implemented
>    independently and with clear interfaces and interactions with other
>    components.  It should be possible to build and implement individual
>    components in isolation and have them work with other components with
>    no changes to other components.  That way implementers have
>    flexibility in implementing individual components and can optimize
>    and innovate within their respective components without requiring
>    changes to other components.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/ballot/
>
> The following IPR Declarations may be related to this I-D:
>
>    https://datatracker.ietf.org/ipr/2320/
>    https://datatracker.ietf.org/ipr/2538/
>
>
>
>
>
>

---

From: "Black, David" <[email-masked]>
Date: Sun, 14 Aug 2016 12:41:54 +0000

AB,

Thanks for the review.

David> Comments inline ...

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Saturday, August 13, 2016 10:42 AM
To: ietf
Cc: [email-masked]; [email-masked]; [email-masked]; Alia Atlas; Matthew Bocci
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

In general this document is about data centres DCs, and using IP architecture, so this document is an architecture of the overlays above such network purpose. The management among both architectures is very essential for the best DC performance. The IP architecture is implemented in the network infrastructure but the NVO3 architecture is a Software Defined Network SDN architecture. Furthermore, DC virtualization has many advantages but increases complexity in all standard design. However, the draft needs more defining of the connection between the both architectures (i.e, implemented and software-defined) needs to be clarified in terms of interactions in both planes (data and control).

Comment-1
The approach of the document needs to be more clear, as mentioned in the introduction:-

introduction>

It should be possible to build and implement individual components in isolation and have them work with other components with no changes to other components.

AB>amend> It should be possible to standardize and implement individual components in isolation and have them work with other components with no changes to other components.

David> That would be incorrect, as many components (e.g., NVAs) can be expected to have additional non-standard protocol (and other) interfaces beyond those specified  by the NVO3 standardization activity.   The focus of NVO3 standardization is specific protocols that interface between components, see Section 13 of the draft.

introduction> This document differs from the framework document in that it doesn’t attempt to cover all possible approaches within the general design space. Rather, it describes one particular approach.

AB>  The introduction needs to answer:- Why you are having one such approach as mentioned above?

AB> If this document is for special approach, this needs to be for special use case which needs to be mentioned in title, because just saying '' an architecture'' is not clear.

David> This is where the NVO3 WG chose to focus.   I’ll add mention of that to the introduction.

Comment-2

AB> When defining an architecture we need to define all general components, connections, protocols, frames/packets, and services. VN and NV are explained used in this document, but still not well defined in terms of requirements, design-approaches, and network programming. The document does not define general/special nodes, links, and interfaces of such virtualized networks per control-data (d/c) plane approach. The document does not include virtual DCs and SANs in the definitions. However, looking into other documents under progress worked by the NVO3-WG, it is recommended that this architecture document should be referencing such work in progress.

David> Please suggest references.

Comment-3

The document needs to clarify the NVO3 architecture is it centralised, distributed, or hierarchical distributed for each d/c plane.

David> That’s not necessary, as all three structures are possible, particularly for the control plane.

Comment-4

How to identify each VM and configure its policy. or how to identify virtual DCs which have SAN and LAN. How to configure, Links that have LAN traffic and links that have SAN traffic, and links that do both traffic.  Is it using VN tagging only?

David> VM configuration is handled by the VM Orchestration System - see Section 3.4.

David> Virtual DCs are not part of the NVO3 architecture.

David> Traffic identification is handled by VN identification via a Context ID.  This could be clearer - while Section 3 already indicates that  the Context ID serves this purpose,  I’ll also add text to item 4 in section 4.3 to indicate that VN identification is the purpose of the Context ID.

comment-5

Virtualization is for security, but why the nvo3-architecture addresses are using MAC and IP which is not good for security. Also this node identification was not mentioned in security consideration.

David> Virtualization is for much more than security, please see RFC 7364 (Problem Statement: Overlays for Network Virtualization).   The key identifier  for NVO3 security is the virtual network identifier, as opposed to node identifiers such as MAC and IP.  There’s also a  good discussion of security requirements in this area in the NVO3 Framework (RFC 7365) - I’ll add a reference to that discussion rather than repeat it here.

Comment-6

The ip architecture underlying needs to include IPv4 and/or IPv6, in one section you mention TTL which is only for IPv4, but what about IPv6.

David> Definitely a problem - that’s section 3.1.2, and it will be corrected.  Thanks  for noticing!

comment-7

David> Figure 1 says that it is “Generic” - that figure is aligned with RFC 7365, and TSI is clearly defined in Section 2.  It would be better to retain commonality with RFC 7365.

Figure 1 should say: L3 overlay networks, instead of: L3 overlay network, or mentioning that there may be VNs and NVDs. Also to show local and remote TSs and remote NVE.

David> The L3 overlay network supports multiple Virtual Networks (which may provide L2 or L3 service), so singular “network” is correct.

David> What are NVDs?  That term is not used in this draft.

comment-8

section 3.1.1> To provide complete virtualization the network should provide similar properties to the computing layer. The network infrastructure should be able to support arbitrary network topologies and addressing schemes. Each tenant should have the ability to configure both the computing nodes and the network simultaneously.

AB> IPv6 cannot be used by the VMs of a tenant if the underlying physical forwarding devices support only IPv4. The section should be clear about this issue.

David> Actually, IPv6 can be used in that case.  NVO3 is one of a number of technologies that are capable of encapsulating IPv6 in IPv4.

comment-9

section 3.1.1> Just as in the case with ports on Ethernet switches, a number of settings could be imagined.

David> Ok, will change “could be imagined” to “are possible”

comment-10

In security section, it was not taken consideration/recommendation of using the IPsec technology, why.

David> It’s one of a number of possible ways to address the security requirements - I’ll add mention of it as an example with a reference to RFC 4301.

Editorial comments:

David> That’s an embarrassing lapse, thanks for finding it, fixed.

David> “funnelled” is correct in this context, “tunnelled” would be incorrect (e.g., tunnels may hide traffic from a firewall).

draft>Packets

David> A global change to “NVO3 packets” will likely detract from clarity, so that seems like a bad idea.  Are there specific instances that should be changed?

AB> You mention also TS packets. so that TS packet could be any protocol packet.

David> It’s mentioned once, I’ll remove the “TS’ to change that instance to just “packets”

Thank you, and sorry for the late submit of the date 12 August, it was due to many electricity breaks.

best regards

AB

kk

On Sat, Jul 30, 2016 at 1:06 AM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2016-08-12. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

---

From: "Black, David" <[email-masked]>
Date: Mon, 15 Aug 2016 16:02:28 +0000

And here’s the new version of Section 3.1.2 that covers packet lifetime considerations for both IPv4 and IPv6, not just IPv4 TTL:

3.1.2.  Packet Lifetime Considerations

   For L3 service, Tenant Systems should expect the IPv4 TTL (Time to
   Live) or IPv6 Hop Limit in the packets they send to be decremented by
   at least 1.  For L2 service, neither the TTL nor Hop Limit (when the
   packet is IP) is modified.  The underlay network manages the TTLs and
   Hop Limits in the outer IP encapsulation - the values in these fields
   could be independent from or related to the values in the same fields
   of tenant IP packets.

Thanks, --David

From: Black, David
Sent: Sunday, August 14, 2016 8:42 AM
To: Abdussalam Baryun; ietf
Cc: [email-masked]; [email-masked]; [email-masked]; Alia Atlas; Matthew Bocci; Black, David
Subject: RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

AB,

Thanks for the review.

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Saturday, August 13, 2016 10:42 AM
To: ietf
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas; Matthew Bocci
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

Comment-1

introduction>

Comment-2

Comment-3

Comment-4

comment-5

Comment-6

comment-7

comment-8

comment-9

comment-10

Editorial comments:

draft>Packets

best regards

AB

kk

Abstract

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 21 Aug 2016 11:51:14 +0200

Thanks David, sorry again for late reply due to some issues.

Reply inline

On Sun, Aug 14, 2016 at 2:41 PM, Black, David <[email-masked]> wrote:

> *From:* Abdussalam Baryun [mailto:[email-masked]]
> *Sent:* Saturday, August 13, 2016 10:42 AM
> *To:* ietf
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; Alia Atlas; Matthew Bocci
> *Subject:* Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture
> for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC
>
>
>
> It should be possible to build and implement individual components in
> isolation and have them work with other components with no changes to other
> components.
>
> David> That would be incorrect, as many components (e.g., NVAs) can be
> expected to have additional non-standard protocol (and other) interfaces
> beyond those specified  by the NVO3 standardization activity.
>

I do not understand why incorrect, usually having an architecture is making
standards

>   The focus of NVO3 standardization is specific protocols that interface
> between components, see Section 13 of the draft.
>

This draft is not proposed-standard, so it is informational, so engineers
can start with as basic points. The components of the NVO3 need to
be determined, so the figure 1 needs to add NVAs, furthermore, the
interface to NVO3 should be determined. IMHO architecture should define all
components in the system and their interaction but also the
interface requirements or interface protocols. Overall, this is an
informational document, so if we explain that  you mentioned now above it
can show what is out of scope.

>
>
> introduction> This document differs from the framework document in that
> it doesn’t attempt to cover all possible approaches within the general
> design space. Rather, it describes one particular approach.
>
>
>
> AB> When defining an architecture we need to define all general
> components, connections, protocols, frames/packets, and services. VN and NV
> are explained used in this document, but still not well defined in terms of

draft-ietf-nvo3-use-case-08
draft-ietf-nvo3-gue-04

> particularly for the control plane.
Ok, so could we clarify this in the draft as you mentioned now, because
IMHO when we don't mention it in the draft it can mean that it was not
included in such approach.

> David> Virtual DCs are not part of the NVO3 architecture.

but vDC was defined in the document, so I suggest you mention that it is
not allowed in nodes of NVO3.

>
>
> David> Traffic identification is handled by VN identification via a
> Context ID.  This could be clearer - while Section 3 already indicates
> that  the Context ID serves this purpose,  I’ll also add text to item 4 in
> section 4.3 to indicate that VN identification is the purpose of the
> Context ID.
>

Ok, thanks,

>
>
> comment-5
>
>
>
> Virtualization is for security, but why the nvo3-architecture addresses
> are using MAC and IP which is not good for security. Also this node
> David> Virtualization is for much more than security, please see RFC 7364
> (Problem Statement: Overlays for Network Virtualization).   The key
> identifier  for NVO3 security is the virtual network identifier, as opposed
> to node identifiers such as MAC and IP.  There’s also a  good discussion of
> security requirements in this area in the NVO3 Framework (RFC 7365) - I’ll
> add a reference to that discussion rather than repeat it here.
>
> ok

> David> Figure 1 says that it is “Generic” - that figure is aligned with
> RFC 7365, and TSI is clearly defined in Section 2.  It would be better to
> retain commonality with RFC 7365.
>

it is not same as the figure in 7365, NVA is missing in the draft.

> David> The L3 overlay network supports multiple Virtual Networks (which
> may provide L2 or L3 service), so singular “network” is correct.
>
>
>

I mean devices or nodes, so we can know the node's principle functions, but
from the draft it was not clear to me. As what it can do and cannot do, I
usually in virtual environment want to know what it must not do.

> David> Actually, IPv6 can be used in that case.  NVO3 is one of a number
> of technologies that are capable of encapsulating IPv6 in IPv4.
>

ok, that needs configuration issues I think, depending on the hypervisor
system.

> David> It’s one of a number of possible ways to address the security
> requirements - I’ll add mention of it as an example with a reference to RFC
> 4301.
>

For security consideration in virtualizations, imho communication methods
and programming methods are both important. The interfaces with NVO3 will
determine these issues.

> David> “funnelled” is correct in this context, “tunnelled” would be
> incorrect (e.g., tunnels may hide traffic from a firewall).
>
>
>
> draft>Packets
>
> David> A global change to “NVO3 packets” will likely detract from clarity,
> so that seems like a bad idea.  Are there specific instances that should be
> changed?
>
yes agree not global, only when needed, as to have a unique packet method
for NVO3,

> David> It’s mentioned once, I’ll remove the “TS’ to change that instance
ok

---

From: "Black, David" <[email-masked]>
Date: Tue, 23 Aug 2016 03:44:50 +0000

AB,

The changes described previously are in the -07 version of the NVO3 architecture draft.  Summarizing remaining open issues:

-- Comment-1

Request to change “build” to “standardize” in:

>>> It should be possible to build and implement individual components in isolation and have them work

>>> with other components with no changes to other components.

>> David> That would be incorrect, ...

> I do not understand why incorrect

The proposed use of “standardize” is incorrect because in this context, a protocol is not an “individual component.”
The NVO3 activity is standardizing protocols, not “individual components,” see Section 13 of the architecture draft.

-- Comment-2

> draft-ietf-nvo3-use-case-08

While they could be added later, both of those references are currently problematic for different reasons:

The NVO3 WG is currently determining whether to publish the use case draft (which does not contain all NVO3 use cases) as an RFC.   If the NVO3 WG decides to proceed with RFC publication of that draft, it’d be reasonable to add a sentence with a reference to that draft indicating that the use case draft contains some NVO3 use cases.

The NVO3 WG is in the process of deciding what data plane or planes to standardize - IMHO, it’d be appropriate to record the outcome of that decision, but I don’t think it’s reasonable to list all the possible NVO3 data planes here (there are at least six, even though only three are being considered by the NVO3 WG for standardization).

If these situations are resolved in the next few weeks, references could be added.

-- Comment-3

>.> The document needs to clarify the NVO3 architecture is it centralised, distributed, or hierarchical distributed for each d/c plane.

> Ok, so could we clarify this in the draft as you mentioned now, because IMHO when we don't mention it in the draft
> it can mean that it was not included in such approach.

It’s mentioned, but not in that form - the following text in Section 3.3 makes that point for the NVA (key control plane component) without getting into what (IMHO) could be a long list of possible characterizations of architectures:

   The term NVA refers to the overall system, without regards to its scope or how it is implemented.

Beyond that, the relationship between the NVA and other control plane components is extensively described in the draft.

-- Comment-4

>>> … or how to identify virtual DCs which have SAN and LAN.

> but vDC was defined in the document

No it wasn’t - neither the “vDC” acronym nor its “virtual DC” expansion appear in the NVO3 architecture draft.

The rest of Comment-4 is addressed with additional text in -07 added to item 4 in section 4.3 to indicate that VN identification is the purpose of the Context ID.

-- Comment-7

This requests changes to Figure 1 (NVO3 Generic Reference Model) that depart from RFC 7365 (NVO3 Framework).

If necessary, Figure 1 could be completely copied from RFC 7365 to make it identical, but RFC 7365 does represent IETF consensus
on the contents of that model as shown in Figure 1.

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Sunday, August 21, 2016 5:51 AM
To: Black, David
Cc: ietf; [email-masked]; [email-masked]; [email-masked]; Alia Atlas; Matthew Bocci
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

Reply inline

On Sun, Aug 14, 2016 at 2:41 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
AB,

Thanks for the review.

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, August 13, 2016 10:42 AM
To: ietf
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas; Matthew Bocci
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

Comment-1

introduction>

David> That would be incorrect, as many components (e.g., NVAs) can be expected to have additional non-standard protocol (and other) interfaces beyond those specified  by the NVO3 standardization activity.

I do not understand why incorrect, usually having an architecture is making standards

  The focus of NVO3 standardization is specific protocols that interface between components, see Section 13 of the draft.

This draft is not proposed-standard, so it is informational, so engineers can start with as basic points. The components of the NVO3 need to be determined, so the figure 1 needs to add NVAs, furthermore, the interface to NVO3 should be determined. IMHO architecture should define all components in the system and their interaction but also the interface requirements or interface protocols. Overall, this is an informational document, so if we explain that  you mentioned now above it can show what is out of scope.

Comment-2

Comment-3

Ok, so could we clarify this in the draft as you mentioned now, because IMHO when we don't mention it in the draft it can mean that it was not included in such approach.

Comment-4

but vDC was defined in the document, so I suggest you mention that it is not allowed in nodes of NVO3.

Ok, thanks,

comment-5

Comment-6

comment-7

I mean devices or nodes, so we can know the node's principle functions, but from the draft it was not clear to me. As what it can do and cannot do, I usually in virtual environment want to know what it must not do.

comment-8

ok, that needs configuration issues I think, depending on the hypervisor system.

comment-9

comment-10

For security consideration in virtualizations, imho communication methods and programming methods are both important. The interfaces with NVO3 will determine these issues.

Editorial comments:

draft>Packets

David> A global change to “NVO3 packets” will likely detract from clarity, so that seems like a bad idea.  Are there specific instances that should be changed?
yes agree not global, only when needed, as to have a unique packet method for NVO3,

best regards

AB

kk

Abstract

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 23 Aug 2016 15:20:05 +0200

Hi David,

> appear in the NVO3 architecture draft.
in the section 2 it is clear:
section 2 draft> This document uses the same terminology as

[RFC7365].

IMHO, it means that this draft has same terminology included in the draft
as rfc7365 (i.e, virtual DC is defined in RFC7365). It is used in many
drafts in IETF that authors don't like to repeat such similar RFC with
similar approach (even in scientific articles it is great practice to
reference related work).

AB>  the authors can mention the different terminology or that virtual DC
is not included in the architecture, but is there a reason why we should
not add an information that points to this. For me as we can have a VLAN
defined on a LAN, then we can have vDC on a DC.

Thanks for your replies,

Best Regards

AB

---

From: "Black, David" <[email-masked]>
Date: Wed, 24 Aug 2016 12:57:30 +0000

AB,

> section 2 draft> This document uses the same terminology as [RFC7365].
> IMHO, it means that this draft has same terminology included in the draft as rfc7365
> (i.e., virtual DC is defined in RFC7365).

To be precise, the term “virtual DC” would be as defined in RFC 7365 *if* that term were used.  The virtual DC term is not used in this draft and it’s also not used in RFC 7365 outside of its definition in section 1.1.

> AB>  the authors can mention the different terminology or that virtual DC is not included in the architecture, but is there a reason why
> we should not add an information that points to this.
The terminology is not different, but the virtual DC concept is not needed to describe the NVO3 architecture or the NVO3 framework.

> For me as we can have a VLAN defined on a LAN, then we can have vDC on a DC.

Sure, see section 4.3 of the NVO3 use case draft - vDC could be mentioned as a use case example if a reference to that use case draft is added.

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Tuesday, August 23, 2016 9:20 AM
To: Black, David
Cc: ietf; [email-masked]; [email-masked]; Alia Atlas
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

Hi David,

[RFC7365].

IMHO, it means that this draft has same terminology included in the draft as rfc7365 (i.e, virtual DC is defined in RFC7365). It is used in many drafts in IETF that authors don't like to repeat such similar RFC with similar approach (even in scientific articles it is great practice to reference related work).

AB>  the authors can mention the different terminology or that virtual DC is not included in the architecture, but is there a reason why we should not add an information that points to this. For me as we can have a VLAN defined on a LAN, then we can have vDC on a DC.

Thanks for your replies,

Best Regards

AB

---

From: Lucy yong <[email-masked]>
Date: Wed, 24 Aug 2016 19:56:07 +0000

Hi David and AB,

It is good to reference the use case draft for vDC. The WG original plan was to progress the architecture and use case drafts together until a concern raised recently. Hope that will be resolved soon. The use case draft is in stable stage ( need to address some comments from Allan).

Regards,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Black, David
Sent: Wednesday, August 24, 2016 7:58 AM
To: Abdussalam Baryun
Cc: [email-masked]; Black, David; [email-masked]; ietf; Alia Atlas
Subject: Re: [nvo3] Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

AB,

Thanks, --David

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: Tuesday, August 23, 2016 9:20 AM
To: Black, David
Cc: ietf; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Alia Atlas
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

Hi David,

[RFC7365].

Thanks for your replies,

Best Regards

AB