Subject: [nvo3] draft-narten-nvo3-overlay-problem-statement

From: Vishwas Manral <[email-masked]>
Date: Tue, 26 Jun 2012 16:10:30 -0700

Hi guys,

I looked at the draft and here are my first pass comments:

1. Abstract - I am not happy with the mention of NIC in the abstract, what
happens in case of LOM's. I think we should just state network hardware
instead of NIC.

2. Abstract - I agree with the idea of the statement:
Use of an overlay-based approach enables scalable deployment on large
network infrastructures.

>From the edge perspective however overlays cause scalability limitations,
however P2P models work well as the edge is not loaded (take the case of
IPsec tunnels versus MPLS VPN). So I think you may want to clarify the
statement.

3. Introduction - We talk about tenant having expectation of separation of
resources. We however only talk of traffic separation in the whole
document. Are there other resources we are considering here? If so we may
want to state them.

4. In the document the assumption seems to be that each end station can
connect to "a" virtual network. Is that what we intend to state or do we
also consider connecting to multiple networks - though for each we could
have a different MAC address?

5. Section 2.1 - In my view Multi-tenancy and elasticity impose different
requirements and should be treated as different problems.

6. Section 2.2 - Besides retaining IP/ MAc, we also need to retain the port
numbers, assume TCP.

7. Section 2.2 - We talk about "today" IP address based on ToR. I think we
should state in traditional DC etc. Also it should go before we talk about
VM/ vMotion etc.

8. Section 2.5 - I think another idea should be that we need to allow the
tenant to do addressing irrespective of the infrastructure, to have clear
tenant/ provider boundaries.

9. Section 2.6, another use case is the fact that there will be
communication required between devices in the DC and end points in the
branch/ campus network, which may not support the NVO3 functionality.

10. Section 2.7, why would sparsely populated members in a DC be highly
distributed, as a general characteristic.

11. Section 2.7, though the network infrastructure is administered by a
single domain, in my view the virtual infrastructure should be independent
of the physical one and should be operated by the tenant infrastructure.
Look at the case of Vyatta like routers that can be spun on demand.

Typo
--------
1. s/ resiliancy/resiliency
2. s/ trade offs/ tradeoffs

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 28 Jun 2012 08:41:27 -0700

Reforwarding in case it did not come through.

-Vishwas

On Tue, Jun 26, 2012 at 4:10 PM, Vishwas Manral <[email-masked]>wrote:

> 6. Section 2.2 - Besides retaining IP/ MAc, we also need to retain the
> port numbers, assume TCP.
>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 28 Jun 2012 16:55:22 +0000

Hi Vishwas,

I've included some responses below.  - Larry

From: Vishwas Manral <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 26, 2012 4:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Narten <[email-masked]<mailto:[email-masked]>>, Murari Sridharan <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, Cisco Employee <[email-masked]<mailto:[email-masked]>>, Dinesh Dutt <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] draft-narten-nvo3-overlay-problem-statement

Hi guys,

1. Abstract - I am not happy with the mention of NIC in the abstract, what happens in case of LOM's. I think we should just state network hardware instead of NIC.

I don't understand your concern.  My understanding is the term NIC covers all physical form factors and is more about the functionality. e.g. see this definition of NIC on wikipedia which includes LOM: http://en.wikipedia.org/wiki/Network_interface_controller

2. Abstract - I agree with the idea of the statement:
Use of an overlay-based approach enables scalable deployment on large network infrastructures.

>From the edge perspective however overlays cause scalability limitations, however P2P models work well as the edge is not loaded (take the case of IPsec tunnels versus MPLS VPN). So I think you may want to clarify the statement.

3. Introduction - We talk about tenant having expectation of separation of resources. We however only talk of traffic separation in the whole document. Are there other resources we are considering here? If so we may want to state them.

4. In the document the assumption seems to be that each end station can connect to "a" virtual network. Is that what we intend to state or do we also consider connecting to multiple networks - though for each we could have a different MAC address?

5. Section 2.1 - In my view Multi-tenancy and elasticity impose different requirements and should be treated as different problems.

6. Section 2.2 - Besides retaining IP/ MAc, we also need to retain the port numbers, assume TCP.

7. Section 2.2 - We talk about "today" IP address based on ToR. I think we should state in traditional DC etc. Also it should go before we talk about VM/ vMotion etc.

8. Section 2.5 - I think another idea should be that we need to allow the tenant to do addressing irrespective of the infrastructure, to have clear tenant/ provider boundaries.

Isn't that covered in section 2.2?

9. Section 2.6, another use case is the fact that there will be communication required between devices in the DC and end points in the branch/ campus network, which may not support the NVO3 functionality.

10. Section 2.7, why would sparsely populated members in a DC be highly distributed, as a general characteristic.

To take advantage of available compute resources at the time of placement or VM migration for resource optimization.

11. Section 2.7, though the network infrastructure is administered by a single domain, in my view the virtual infrastructure should be independent of the physical one and should be operated by the tenant infrastructure. Look at the case of Vyatta like routers that can be spun on demand.

I think this might be addressed by expanding section 3 point 1 to include not just separation between virtual networks but also between virtual networks and the underlying infrastructure.

Typo
--------

Thanks,
Vishwas