Subject: [nvo3] NVA structure - Arch draft section 7.3

From: "Black, David" <[email-masked]>
Date: Mon, 19 May 2014 12:44:46 -0400

Change of subject line to focus on this topic:

>> Section 7.3: Why is it necessary for NVA to appear as one single entity? For a network that supports
>> tens of thousands VNs, each NVA may only need to support a subset of VNs. Why can't we let each NVA
>> to announce itself on the range of VNs that it supports, and let the NVE reach to the appropriate NVA
>> depending on the data frame's VN?
>
> I agree that this scenario is reasonable, although I'd prefer to think about it differently from an
> architectural viewpoint, and that viewpoint is not captured in the architecture draft, so thank you
> for raising the topic.
>
> If a single NVE implementation is talking to multiple NVAs, I would prefer to view that NVE
> implementation as consisting of multiple logical or virtual NVE instances.  My rationale is that
> I think of an NVE as controlled by the NVA, and viewing the NVA as having its own logical or
> virtual NVE instance makes the domain of control of each NVA clearer.
>
> Regardless of whether the WG agrees with this viewpoint, I think the architecture draft could use
> some text to discuss this scenario.

Based on further thought and some offline discussion, there are two relevant NVA structures from
an architectural viewpoint:

[A] A single logical NVA (e.g., from an administrative viewpoint) is actually implemented across
      multiple network nodes (e.g., for HA and/or load sharing), and the NVE communicates with
more than one of those nodes.  For load sharing, responsibility for VNs may be divided
(statically or dynamically) among the nodes that comprise the NVA.

[B] Multiple logical NVAs (e.g., from an administrative viewpoint) communicate with a single instance
      of NVE functionality.

The comment above on "multiple logical or virtual NVE instances" is about case [B].

For case [A], there is already text in 7.3 that discusses multiple IP addresses, including the
scenario that Linda asked about where "each NVA may only need to support a subset of VNs".  For
further discussion of case [A], suggestions of specific text changes would be appreciated,
as that case is covered in the current architecture draft.

In contrast, case [B] is not currently covered, but could be addressed by adapting the "If a
single NVE implementation is talking to multiple NVAs" paragraph above to add to section 7.3
of the draft.

Comments?

Thanks,
--David

From: Black, David
Sent: Thursday, May 15, 2014 12:42 PM
To: Linda Dunbar; Thomas Narten; [email-masked]; Jon Hudson; Larry Kreeger; LASSERRE, MARC (MARC)
Cc: Black, David
Subject: RE: comments and suggestions to draft-ietf-nv03-arch-01

Hi Linda,

> Here are some questions, comments, and suggestions to draft-ietf-nv03-arch-01:

Thank you for taking a detailed look.

> Section 4.2.1 (Tenant VLAN handling in Split-NVE case):  Even with virtualized
> servers,  NVE function
> could be implemented on the first switch to which the (virtualized) servers is attached.   Do you call
> this scenario "Split-NVE" case?

If I understand the question, I believe the answer is "no" - the Split-NVE case treats the hypervisor-NVE VLANs as private to the hypervisor and external NVE - in effect each VLAN is used to extend the virtual network over an unencapsulated link; they would not be visible to the TS on a VLAN-tagged interface.  More in next paragraph ...

> Under this case, the NVE should have access to the complete original packet. why does the last sentence say
> "... additional mechanisms would be used"?

That sentence is about something else - namely, if the VLAN is assigned to extend a VN by the combination of the hypervisor and NVE, then it's not carrying VLAN info within that VN for the Tenant Systems.  Adding such TS VLAN info involves additional mechanisms, such as VLAN mapping, e.g., if TSs on VNs A and B are both using VLANs 1-8 at their interfaces, then the hypervisor and NVE have to remap those VLAN tags into the set VLAN tags used for hypervisor-NVE communication - e.g., between the hypervisor and NVE, VN A's VLANs 1-8 might be mapped to/from VLANs 101-108, and VN B's VLANs 1-8 might be mapped to/from VLANs 151-158.  We could add that explanation to the draft.

OTOH, it feels like your comments are about a different model where existing VLANs are attached to virtual networks instead of attaching Tenant Systems - I'm not sure whether that's appropriate to add to the base model, as this feels like some sort of gateway between the VN and an existing VLAN, which is covered, albeit briefly in 5.3.  What do other people think?

> Section 5.1: Most Network service appliances are for applying treatment to data packets between hosts/applications,
> i.e. most likely the Network Service Appliances are in the same address domain of the overlay, not underlay

Ok, but please keep in mind that existing network service appliances can't decode the overlay/underlay encapsulation - that's a major motivation for the text in this section.

> I find the following text to comparing Appliances VN differentiation with Server virtualization
> is inappropriate, therefore should be removed from the section.

"Unlike server virtualization, however, the Network Service Appliance may not be running a traditional hypervisor and the VM Orchestration system may not interact with the Network Service Appliance."

Why?  I believe the text is correct and describes situations that may occur in practice with existing appliances.

> Section 5.3: "Gateways" should be in the overlay address domain, i.e. same as Tenant Systems.  Gateway
> is for relay traffic from one VN to another. The relay is specific to the traffic among TSs.

That is the intent - if the text is not clear, please suggest specific changes.

> In Figure 1, should add a box for Gateways. They are in the same positions as TS, i.e. outside the NVEs.

That Figure is a copy of Figure 3 in the framework draft - I would prefer not to change it for that reason, but a separate figure for gateways seems fine - do you want to try to draw one?

> Even if NVEs support Gateway function, the gateway should be a separate logical entity connected to VAP (Figure 2).

Ok, but I think a separate gateway figure would be clearer.

> Section 7.3: Why is it necessary for NVA to appear as one single entity? For a network that supports
> tens of thousands VNs, each NVA may only need to support a subset of VNs. Why can't we let each NVA
> to announce itself on the range of VNs that it supports, and let the NVE reach to the appropriate NVA
> depending on the data frame's VN?

I agree that this scenario is reasonable, although I'd prefer to think about it differently from an architectural viewpoint, and that viewpoint is not captured in the architecture draft, so thank you for raising the topic.

If a single NVE implementation is talking to multiple NVAs, I would prefer to view that NVE implementation as consisting of multiple logical or virtual NVE instances.  My rationale is that I think of an NVE as controlled by the NVA, and viewing the NVA as having its own logical or virtual NVE instance makes the domain of control of each NVA clearer.

Regardless of whether the WG agrees with this viewpoint, I think the architecture draft could use some text to discuss this scenario.

Thanks,
--David

From: nvo3 [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, May 14, 2014 5:51 PM
To: Thomas Narten; [email-masked]<mailto:[email-masked]>; Black, David; Jon Hudson; Larry Kreeger; LASSERRE, MARC (MARC)
Subject: [nvo3] comments and suggestions to draft-ietf-nv03-arch-01

David, Jon, Larry, Marc, and Thomas,

Here are some questions, comments, and suggestions to draft-ietf-nv03-arch-01:

*         Section 4.2.1 (Tenant VLAN handling in Split-NVE case):  Even with virtualized servers,  NVE function could be implemented on the first switch to which the (virtualized) servers is attached.   Do you call this scenario "Split-NVE" case?

Under this case, the NVE should have access to the complete original packet. why does the last sentence say "... additional mechanisms would be used"?

*         Section 5.1: Most Network service appliances are for applying treatment to data packets between hosts/applications, i.e. most likely the Network Service Appliances are in the same address domain of the overlay, not underlay.  Probably using the same VLAN tags from TS for the tenants' configuration rules.

I find the following text to comparing Appliances VN differentiation with Server virtualization is inappropriate, therefore should be removed from the section.

"Unlike server virtualization, however, the Network
Service Appliance may not be running a traditional hypervisor and the
VM Orchestration system may not interact with the Network Service
Appliance."

*         Section 5.3: "Gateways" should be in the overlay address domain, i.e. same as Tenant Systems.  Gateway is for relay traffic from one VN to another. The relay is specific to the traffic among TSs.

In Figure 1, should add a box for Gateways. They are in the same positions as TS, i.e. outside the NVEs.

Even if NVEs support Gateway function, the gateway should be a separate logical entity connected to VAP (Figure 2).

*         Section 7.3: Why is it necessary for NVA to appear as one single entity? For a network that supports tens of thousands VNs, each NVA may only need to support a subset of VNs. Why can't we let each NVA to announce itself on the range of VNs that it supports, and let the NVE reach to the appropriate NVA depending on the data frame's VN?

Cheers,
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 19 May 2014 18:38:01 +0000

David,

To get proper answers from the community, can you classify:

-          For [A] below, does the single logical NVA (that is implemented across multiple network nodes) have one single "Address" for NVEs to send inquiry to?

-          For [B] below: is there a common VN that  is in the NVA of Administrative "X" and the NVA of Administrative "Y"?

Linda

From: Black, David [mailto:[email-masked]]

Comments?

Thanks,
--David

From: Black, David
Sent: Thursday, May 15, 2014 12:42 PM
To: Linda Dunbar; Thomas Narten; [email-masked]<mailto:[email-masked]>; Jon Hudson; Larry Kreeger; LASSERRE, MARC (MARC)
Cc: Black, David
Subject: RE: comments and suggestions to draft-ietf-nv03-arch-01

Hi Linda,

Thanks,
--David

Cheers,
Linda

---

From: "Black, David" <[email-masked]>
Date: Mon, 19 May 2014 14:57:26 -0400

Linda,

> To get proper answers from the community, can you classify:

-          > For [A] below, does the single logical NVA (that is implemented across multiple network nodes) have one single "Address" for NVEs to send inquiry to?

That would depend on the NVA implementation - one or multiple addresses could be used, and there's already text on use of multiple addresses in section 7.3 of the architecture draft for scenario [A].

I would think not.  Because the administrative domains are separate, any VN would really needs to be managed by one logical NVA, and hence be handled by one of the logical NVE instances that comprise the NVE implementation that deals with multiple logical separate NVAs.
Thanks,
--David

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, May 19, 2014 2:38 PM
To: Black, David; [email-masked]
Subject: RE: NVA structure - Arch draft section 7.3

David,

Linda

Comments?

Thanks,
--David

From: Black, David

Hi Linda,

Thanks,
--David

Cheers,
Linda

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 19 May 2014 20:10:17 +0000

David,

If there are multiple addresses for the NVA, what is the reason to call it "single logical NVA"?

Even with a single address, say creating a dedicated NVA multicast address, if you don't want the NVAs on different (network) nodes all respond to the queries from NVE, you have to put in coordination mechanisms among those NVA nodes.

It is much simpler to embrace the fact that there could be multiple NVAs ( for redundancy purpose, or for scaling reasons), instead of describing the "single logical entity".

Linda

From: Black, David [mailto:[email-masked]]
Sent: Monday, May 19, 2014 1:57 PM
To: Linda Dunbar; [email-masked]
Subject: RE: NVA structure - Arch draft section 7.3

Linda,

Thanks,
--David

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, May 19, 2014 2:38 PM
To: Black, David; [email-masked]<mailto:[email-masked]>
Subject: RE: NVA structure - Arch draft section 7.3

David,

Linda

Comments?

Thanks,
--David

From: Black, David

Hi Linda,

Thanks,
--David

Cheers,
Linda

---

From: "Black, David" <[email-masked]>
Date: Mon, 19 May 2014 18:31:16 -0400

Linda,

> If there are multiple addresses for the NVA, what is the reason to call it "single logical NVA"?

It's one logical entity from the functional standpoint of VN management/administration, etc.; IMHO, that's more important than how many addresses it uses or how many network nodes the NVA's components reside on.  The NVA components behind those addresses cooperate to consistently manage a common set of VNs.

In addition, the problem statement draft is written this way, e.g., this text from section 4.5:

   The back-end NVA could provide high performance, high resiliency,
   failover, etc. and could be implemented in significantly different
   ways.

This "single logical NVA" approach is also consistent with the framework draft's language about a single control plane.

> Even with a single address, say creating a dedicated NVA multicast address, if you don't want the NVAs on different (network) nodes all
> respond to the queries from NVE, you have to put in coordination mechanisms among those NVA nodes.

Section 7.3 already discusses use of multiple addresses; there's no restriction there to a single address, multicast or otherwise.

> It is much simpler to embrace the fact that there could be multiple NVAs ( for redundancy purpose, or for scaling reasons), instead of describing the "single logical entity".

Section 7.3 already embraces use of multiple NVA components with different addresses for redundancy and/or scaling.  Among the reasons for treating the components as part of a single logical NVA is the need for "coordination mechanisms among those NVA nodes" as stated in the first paragraph of Section 7.3 ("consistent behavior across the NVA and all other NVEs using the same NVA").

I believe that requirement applies in case [A] regardless of whether "single logical NVA" language is used - do you disagree with that requirement?

Thanks,
--David

From: Linda Dunbar [mailto:[email-masked]]
Sent: Monday, May 19, 2014 4:10 PM
To: Black, David
Cc: [email-masked]
Subject: RE: NVA structure - Arch draft section 7.3

David,

Linda

From: Black, David [mailto:[email-masked]]
Sent: Monday, May 19, 2014 1:57 PM
To: Linda Dunbar; [email-masked]<mailto:[email-masked]>
Subject: RE: NVA structure - Arch draft section 7.3

Linda,

Thanks,
--David

David,

Linda

Comments?

Thanks,
--David

From: Black, David

Hi Linda,

Thanks,
--David

Cheers,
Linda