Subject: Re: [nvo3] Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 21 Oct 2013 04:50:14 +0000

Hi Linda,

Please see my replies inline below.  I'd like to hear Thomas and David's opinions on this as well.

Thanks, Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 20, 2013 2:31 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

Larry, Thomas, and David,
Going through your current “draft-ietf-nvo3-nve-nva-cp-req-00” to enhance our “http://www.ietf.org/id/draft-dunbar-nvo3-nva-gap-analysis-01.txt”, I noticed that there are several detailed NVE<->NVA control plane requirement not yet identified in your draft.
Some requirements of TRIL/LISP directory mechanism described in “draft-dunbar-nvo3-nva-gap-analysis” are applicable to NVE<->NVA control plane requirement because TRILL/LISP directory mechanisms are also about distributing “inner-outer” address mapping to edge nodes .
Here are the some suggested additions to the current “draft-ietf-nvo3-nve-nva-cp-req-00”, to make the NVE-NVA requirement draft more complete and easier for gap analysis.

1.      The first paragraph of Section 4 describes the characteristics of NVEs. Since this draft is about control plane requirement between NVE and NVA, it is beneficial to add some description for the characteristics of NVAs. Here is my suggested addition after the first paragraph of Section 4:
“NVAs can be centralized or distributed with each NVA holding the mapping information for a subset of VNs. Centralized NVA could have multiple entities for redundancy purpose.
LK> I'm pretty sure this is covered in the architecture document, but we could do some repeating here.  Regarding "each holding the mapping information for a subset of VNs", part, this gets into federation of NVAs.  I think we can leave that part in the architecture document since it will probably open more questions, than provide answers.  Also, it is not relevant to the NVA to NVE protocol since a single NVE only uses a single NVA.

A NVA could be instantiated on a server/VM attached to a NVE, very much like a TS attached to a NVE, or could be integrated with a NVE. When a NVA is a standalone server/VM attached to a NVE, it has to be reachable via the attached NVE by other NVEs. A NVA can also be instantiated on a NVE that doesn’t have any TSs attached. The NVE-NVA control plane for NVA being attached to NVE will require additional functions on NVEs than NVA being instantiated on NVE.”
LK> I don't agree that the NVA should be connected to an NVE.  I see no benefit to this.  The NVA should connect directly to the underlay, just as the NVEs do.  Now a single device could contain both NVE and NVA functionality, but they would both connect to the underlay directly, with no need for the NVA functionality to have its communication path forced through the NVE functionality.  NVE VAPs are meant to connect to TSI, not the NVAs.  This is an architectural discussion.

2.      Section 4 should add the following additional requirement on how NVEs and NVAs discover each others, and which NVA for NVE to send pulling or pushing requests.

·        NVEs requesting for Push Services after restart: In the Push Model, it is necessary to have a way for NVE to request NVAs to start the pushing process, e.g. when the NVE is initialized or re-started.  Or it can be like a routing protocol where it just happens automatically. The request for Push Service from NVE should be VN scoped, i.e. including the range of VNs that are enabled on the NVE.

LK> There is no mention of push or pull in the document so far (and I'd like to keep it that way as much as possible).  Whatever protocol is chosen, if it happens to push, it will need to do something like what you mention. That depends on the protocol.  The high level requirement in bullet 4 is to minimize the amount of processing in the NVE.  For a push model, this will most likely require the NVE to subscribe to a subset of the mapping state so it doesn't just spend time processing and discarding mappings it doesn't need..  I could add the following to 4.

"If the NVA pushes information to the NVEs, then one way to minimize the processing on the NVE is for it to subscribe to have mappings pushed to it on a per VN basis" However, I don't know if it is needed.

·        NVAs should advertise their VN-scoped availability to the NVEs who participate in the VN. There could be multiple NVAs, with each having mapping information for a subset of VNs. For each VN, there could be multiple NVAs that have the mapping information.

·        When there are multiple NVAs holding mapping information for a particular VN, a pull request can be sent to any of them that is reachable but it is RECOMMENDED that Pull requests be sent to a NVA that is least cost from the requesting NVE.

LK> The above is not true based on the architecture document.  A single NVE only uses a single NVA.  This simplifies things so this isn't required.

3.      Bullet 2 of Section 4:  More detailed requirements are needed when “inner address that NVE doesn’t have a mapping for”. I suggest adding the following detailed requirement when inner address is not available on the NVE’s mapping database:
“If the destination of a data frame arriving at the Ingress NVE can't be found in NVE’s inner-outer mapping database, the Ingress NVE should be configured with one or more of the following policies:

·        simply drop the data frame,

·        Using legacy method(s) to forward the data frames to other edges, or

LK> I don't know what "using legacy methods means" for forwarding a frame for a VN.

·        start the “pull” process to get information from Pull NVA
When the edge is waiting for reply from Pull process, the edge can either drop or queue the packet.”
LK> I think it is a bit detailed to say that the NVE can either drop or queue the packet.  I think this should be left to implementations to decide.  If we think it must be drop or must be queue, maybe it is worth saying something (but I think it should be left to implementations).

4.      Section 4 Bullet 3 has requirement on “fast detection/update of stale cache”. It would be clearer to add additional requirement on incremental update in Push Model. Here is the proposed text for “Incremental update”

·        Whenever there is any change in TS’ association to an edge (NVE), which can be triggered by TS being added, removed, or de-commissioned, an incremental update can be sent to the edges that are impacted by the change. It is desirable for incremental update to only include the changed mapping entries. However per mapping entry incremental update can cause complexity of NVA in maintaining the state of each entry. A good balance between amount of data in each incremental update and the complexity of maintaining status of entries should be considered.

LK> Hmm, it sounds like you might be trying to set some criteria to judge different protocols by.  For example, how complex are they to implement (6.), or how well do the protocols minimizing processing overhead (4.).  Based on that, it seems like this is covered (in bullets 6 and 4).

5.      Section 4 should add the following additional requirement on what NVE should do when there is no response from Pull request. Here is my suggested text:

·        There are several possibilities of the Pull Response:

o   Valid inner-outer address mapping, coupled with the valid timer indicating how long the entry can be cached by the edge (NVE).
The timer for cache should be short in an environment where VMs move frequently. The cache timer can also be configured.

o   The target being queried is not available. The response should include the policy if requester should forward data frame in legacy way, or drop the data frame.

o   The requestor is administratively prohibited from getting an informative response.

If no response is received to a Pull request within a configurable timeout, the request should be re-transmitted with the same Sequence Number up to a configurable number of times.
If errors occur at the query level, they MUST be reported in a response message separate from the results of any successful queries. If multiple queries in a request have different errors, they MUST be reported in separate response messages. If multiple queries in a request have the same error, this error response MAY be reported in one response message.

LK> Again, this is getting pretty detailed.  My thought is that the requirements are to be high level enough that many protocols might fit the bill.  Some of the above seem like they would be nice to have, but I don't know if they need to be mandatory. I hesitate to put in this level of detail.

6.      Section 4 should add the following additional requirement on the proper behavior on NVE when it loses its connection to its Push NVA. Here is my suggested addition:
If an NVE notices that a Push NVA is no longer reachable, it MUST ignore any Push mapping entries from that NVA because it is no longer being updated and may be stale.
There may be transient conflicts between mapping information from different Push NVAs, some kind of confidence level information with mapping entries can be considered in case of such conflicts. Information with a higher confidence value is preferred over information with a lower confidence.
 LK> Again, the architecture calls for a each NVE to use only a single NVA, so the above would not be relevant.
Thanks, Linda Dunbar

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 21 Oct 2013 05:33:34 +0000

Linda,

In an effort to address your comments, I propose adding the following text in section 3.

"The NVE to NVA control protocol will be carried across the underlay network.  The NVA is expected to be connected to the same underlay network as the NVEs.

Note that a single device could contain both NVE and NVA functionality, but the protocol between the NVE and NVA within that device should not operate any differently that when the NVE and NVA are implemented in separate devices.

Each NVE communicates with only a single NVA; However, the NVA can be centralized or distributed between multiple entities for redundancy purposes.  When the NVA is made up of multiple entities, maximum resiliency may be achieved by physically separating them, which may require each entity to have a different IP address on the underlay network.  For this reason, each NVE should be allowed to be configured with at least two different IP addresses for its NVA.  NVEs should be able to switch between these IP addresses when it detects that the address it is currently using for the NVA is unreachable."

Also, I propose adding the following text to bullet 4 in section 4

"For example, if the  NVA pushes information to the NVEs, then one way to minimize the processing on the NVE is for it to subscribe for having mappings pushed to it on a per VN basis.  If the NVE pulls from the NVA, then it only needs to pull information relevant to the traffic flows that are currently active."

 - Larry

From: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 20, 2013 9:50 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

Hi Linda,

Thanks, Larry

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 Oct 2013 18:19:16 +0000

Larry,
Please see my comments inserted below:

[Linda] “a single NVE only uses a single NVA”? What if the NVE is disconnected from its “only” NVA? Or its only “NVA” has failure or is going through software restart?  For the distributed case, each NVA only has mapping for a subset of VNs. It is very possible that the VNs being participated by one NVE are carried by multiple NVAs

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 Oct 2013 18:19:22 +0000

Larry,
Could you please explain the following question?
LK> I don't agree that the NVA should be connected to an NVE.  I see no benefit to this.  The NVA should connect directly to the underlay, just as the NVEs do.

[Linda] NVA has to be placed somewhere in a data center. Say a NVA is placed on a server rack. Most server racks are pre-wired with each slot to the ToR switch. In an environment where the ToR is the NVE, then the NVA is attached to the NVE.  How would you call this attachment?

Linda

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 Oct 2013 16:21:49 -0400

Hi Linda.

> LK> I'm pretty sure this is covered in the architecture document,
> but we could do some repeating here.  Regarding "each holding the
> mapping information for a subset of VNs", part, this gets into
> federation of NVAs.  I think we can leave that part in the
> architecture document since it will probably open more questions,
> than provide answers.  Also, it is not relevant to the NVA to NVE
> protocol since a single NVE only uses a single NVA. 
>  
> [Linda] “a single NVE only uses a single NVA”? What if the NVE is
> disconnected from its “only” NVA? Or its only “NVA” has failure or
> is going through software restart?  For the distributed case, each
> NVA only has mapping for a subset of VNs. It is very possible that
> the VNs being participated by one NVE are carried by multiple NVAs 

Couple of things. The terminology may not be perfect/precise, but we
need to distinguish between the term NVA (as in the entity responsible
for operating within one specific NV Domain) vs. an NVA in a broader
sense when we talk about multiple different sites (each operating
their own NVA) but that share (some) information to create NV regions.

If above you are thinking of the latter notion of an NVA, I want to
push back on that.

Within a specific NV Domain, in the current federated model, there is
exactly one NVA; an NVE always/only talks to the NVA operating that NV
Domain. If that NVA doesn't have information about a mapping, that
info simply is not available to the NVE. An NVE does not contact a
different NVA somewhere else to get that info. The whole federated
model is intended to allow information from other outside/external
NVAs to be imported into a local NVA (subject to policy). Thus, if
information from another NVA is needed, it should be available via the
local NVA.

In that sense, what you write above is not supposed to happen.

That said, even within an NV Region, an NVA will consist of multiple
entities for redundancy. In that case, and NVE may need to failover
from one NVA contact point to another. This will be needed for fault
tolerance purposes.

Have a look at the redone Section 6.3. There are some questions there
that we need to discuss and make a decision on:

> 6.3.  NVA External Interface
> 
>    [note: the following section discusses various options that the WG
>    has not yet expressed an opinion on.  Discussion is encouraged. ]
> 
>    Conceptually, from the perspective of an NVE, an NVA is a single
>    entity.  An NVE interacts with the NVA, and it is the NVA's
>    responsibility for ensuring that interactions between the NVE and NVA
>    result in consistent behavior across the NVA and all other NVEs using
>    the same NVA.  Because an NVA is built from multiple internal
>    components, an NVA will have to ensure that information flows to all
>    internal NVA components appropriately.
>
>    One architectural question is how the NVA presents itself to the NVE.
>    For example, an NVA could be required to provide access via a single
>    IP address.  If NVEs only have one IP address to interact with, it
>    would be the responsibility of the NVA to handle NVA component
>    failures, e.g., by using a "floating IP address" that migrates among
>    NVA components to ensure that the NVA can always be reached via the
>    one address.  Having all NVA accesses through a single IP address,
>    however, adds constraints to implementing robust failover, load
>    balancing, etc.
> 
>    [Note: the following is a strawman proposal.]
> 
>    In the NVO3 architecture, an NVA is accessed through one or more IP
>    addresses (ir IP address/port combination).  If multiple IP addresses
>    are used, each IP address provides equivalent functionality, meaning
>    that an NVE can use any of the provided addresses to interact with
>    the NVA.  Should one address stop working, an NVE is expected to
>    failover to another.  While the different addresses result in
>    equivalent functionality, one address may be more respond more
>    quickly than another, e.g., due to network conditions, load on the
>    server, etc.
> 
>    [Note: should we support the following? ]  To provide some control
>    over load balancing, NVA addresses may have an associated priority.
>    Addresses are used in order of priority, with no explicit preference
>    among NVA addresses having the same priority.  To provide basic load-
>    balancing among NVAs of equal priorities, NVEs use some randomization
>    input to select among equal-priority NVAs.  Such a priority scheme
>    facilitates failover and load balancing, for example, allowing a
>    network operator to specify a set of primary and backup NVAs.
> 
>    [note: should we support the following?  It would presumably add
>    considerable complexity to the NVE.]  It may be desirable to have
>    individual NVA addresses responsible for a subset of information
>    about an NV Domain.  In such a case, NVEs would use different NVA
>    addresses for obtaining or updating information about particular VNs
>    or TS bindings.  A key question with such an approach is how
>    information would be partitioned, and how an NVE could determine
>    which address to use to get the information it needs.
>
>    Another possibility is to treat the information on which NVA
>    addresses to use as cached (soft-state) information at the NVEs, so
>    that any NVA address can be used to obtain any information, but NVEs
>    are informed of preferences for which addresses to use for particular
>    information on VNs or TS bindings.  That preference information would
>    be cached for future use to improve behavior - e.g., if all requests
>    for a specific subset of VNs are forwarded to a specific NVA
>    component, the NVE can optimize future requests within that subset by
>    sending them directly to that NVA component via its address.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 Oct 2013 16:26:54 -0400

Linda,

Linda Dunbar <[email-masked]> writes:

> LK> I don't agree that the NVA should be connected to an NVE.  I see
> no benefit to this.  The NVA should connect directly to the
> underlay, just as the NVEs do.   
>  
> [Linda] NVA has to be placed somewhere in a data center. Say a NVA
> is placed on a server rack. Most server racks are pre-wired with
> each slot to the ToR switch. In an environment where the ToR is the
> NVE, then the NVA is attached to the NVE.  How would you call this
> attachment? 

Maybe I misunderstand, but I read the above as saying that the NVA
could be on its own VN and thus reachable only via an NVE. If that is
what you mean, I have to wonder why we want to do that. Some
considerations:

1) It would seem to raise recursion problems... An NVE that needs to
get address mappings attempts to contact the NVA, but it needs to
first get address mappings for the VN to which the NVA is connected, oops...
All this is avoided by having the NVA connect to the underlay and be
accessible via underlay addresses.

2) Why would you want to do this? What benefit is there? I don't see
any advantages right off.

Thomas

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 24 Oct 2013 22:19:34 +0000

Hi Linda,

See my responses inline.

 - Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 24, 2013 11:19 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

Larry,

[Linda] “a single NVE only uses a single NVA”? What if the NVE is disconnected from its “only” NVA? Or its only “NVA” has failure or is going through software restart?

LK> As described in the architecture document, the NVA is "logically centralized".  It is expected to support fault tolerance, and be made up of more than a single entity for this reason.  There is some more discussion of this in sections 6.2 and 6.3 of draft-narten-nvo3-arch-01 (recently updated).

For the distributed case, each NVA only has mapping for a subset of VNs. It is very possible that the VNs being participated by one NVE are carried by multiple NVAs

LK> Even if an NVA is distributed, it is still logically a single NVA. Section 6.3 has some discussion on how NVEs might use multiple IP addresses to access a single logical NVA.  It is currently left very open for discussion.

Linda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 24 Oct 2013 22:23:26 +0000

Hi Linda,

See my responses inline below.

 - Larry

Larry,

[Linda] NVA has to be placed somewhere in a data center.

LK> I agree.

Say a NVA is placed on a server rack. Most server racks are pre-wired with each slot to the ToR switch.

LK> Sounds reasonable.

In an environment where the ToR is the NVE, then the NVA is attached to the NVE.  How would you call this attachment?

LK> I would expect anyone designing a ToR to make it capable of providing edge ports that are capable of being connected to either an overlay VN, or the the underlay.  For example, if the ToR is a pure L2 device, I would expect some edge ports to be configurable to connect to a VN, and other port to connect to a VLAN which is connected to the underlay network.  I would connect the NVA to the latter port.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 25 Oct 2013 20:36:51 +0000

Thomas, 

Comments inserted below:

> -----Original Message-----
> >
[Linda] I meant NVA within one specific VN Domain (as the entity responsible
for operating within one specific VN Domain). 
One NVA entity may have mapping entries for multiple VN domains. 

> exactly one NVA; 

[Linda] That is one way of doing it. But why this has to be the only way?
There are already multiple versions of running code that allow redundant entities to provide mapping entries for any given VN, e.g. TRILL's Directory &  LISP MapServer. 

> an NVE always/only talks to the NVA operating that NV

[Linda]What if the connection to the local NVA is broken?

> from one NVA contact point to another. This will be needed for fault

[Linda] that is correct. The architecture should allow the NVAs to announce their supported VNs. Each NVE can be configured (with policies) on which one is the primary NVA and which one is the secondary NVA. 

> >    One architectural question is how the NVA presents itself to the

[Linda] The simplest approach, as done by various versions of running code, is for NVA to announce itself (via VN scoped broadcast) and send heartbeat periodically. 

> >    NVA components to ensure that the NVA can always be reached via

[Linda] That is one way of doing it. But this method requires the redundant NVAs to be in same LAN and in close proximity. Another way is to allow each NVA to announce itself. Or provision each NVE with NVAs' address for each VN that NVE is participating. 

> Snipped for ease of commenting:

[Linda] There have been deployed mechanisms of using authoritative entities to provide information to routers/switches for decades. 

Look at the mechanisms that are used by DNS, DHCP, management system/monitoring systems/controller, the common behavior is for (network) elements to be configured with one or a list of the legitimate "authoritative entities". If there are multiple "authoritative entities", either policy (i.e. provisioning) is configured on the elements to enforce which "authoritative entity" is the primary one, or the elements can choose primary one among the list of "legitimate authoritative entities". 

Why need to re-invent the wheel for something that has been deployed?

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 25 Oct 2013 20:36:56 +0000

Larry,
See my comments below:

[Linda] The underlay network is L3 based. If ToR (NVE) is a pure L2 device, who advertises the NVA’s addresses to other NVEs?
Under this environment, the NVE to which NVA is attached, has to be proxy for the NVA, i.e. announce the NVA address as if the NVA is embedded in the NVE.

Bottom line, the NVE-NVA requirement should cover my suggestion being discussed  over the emails.

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 25 Oct 2013 20:37:00 +0000

Thomas, 

If NVA provides mapping entries for one VN, then the VNA should participate in this VN. 

If NVA provides mapping entries for a set of VNs, then the VNA should participate in all those VNs. 

> first get address mappings for the VN to which the NVA is connected,

[Linda] The NVA's address has to be advertised to other NVEs. When a NVA is placed on a server rack and attached to a TOR (NVE) which is a pure L2 switch, you can let this NVE to be proxy for the attached NVA. 
This is one suggestion I give to Larry on NVE being acting for the NVA. Instead of advertise NVA's true IP address, use NVE's addresses. 

Otherwise, the ToR has to announce the NVA's address to other NVEs, i.e. ToR has to support L3 routing function. 

> accessible via underlay addresses.

[Linda]    My above comment should address this issue. 

Linda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 25 Oct 2013 21:15:17 +0000

See inline with LK2>. - Larry

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 25, 2013 1:36 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Thomas Narten <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

Larry,
See my comments below:

[Linda] The underlay network is L3 based. If ToR (NVE) is a pure L2 device,

LK2> I should clarify what I meant by "pure L2 device".  I meant it provides only L2 services on its edge ports, not that it doesn't act as an IP host to connect to the underlay for communicating with the NVA.

who advertises the NVA’s addresses to other NVEs?

LK2> I don't recall any discussions about NVA address advertisements.  So far, I believe the NVEs are configured with the underlay IP address(s) of the NVE's NVA for its domain.

LK2> Again, I see no benefit to connecting an NVA to an NVE.  It should connect directly to the underlay.

LK2> Please be more specific.

Linda

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 25 Oct 2013 21:22:42 +0000

Linda, see inline with LK>. - Larry

On 10/25/13 1:37 PM, "Linda Dunbar" <[email-masked]> wrote:

>[Linda] The NVA's address has to be advertised to other NVEs. When a NVA
>is placed on a server rack and attached to a TOR (NVE) which is a pure L2
>switch, you can let this NVE to be proxy for the attached NVA.
>This is one suggestion I give to Larry on NVE being acting for the NVA.
>Instead of advertise NVA's true IP address, use NVE's addresses.
>

LK> I don't see why either of the above needs to be true.  If the ToR can
provide traditional 802.1Q VLANs in addition to the NVE function, the NVA
simply needs be connected to a port on the ToR which is on a VLAN that
eventually leads to the router providing connected to the IP underlay.
There is no reason for the ToR to proxy for the NVA or route.  It should
be no different from two separate ToRs, one To R that is only 802.1Q
capable which one VLAN connected to an underlay router, another ToR that
only provides NVE functionality.  Implementors can put both functions
inside the same ToR (I would recommend it).

>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 28 Oct 2013 01:44:33 +0000

Larry, 

What you said works, but it requires VLAN configuration on the NVE. 

If NVE and NVA are in trusted domain, you can also let NVE to announce both NVE and NVA's IP Addresses or even let NVA use the same IP address as NVE, especially when a NVE has the built in mapping database (e.g. the NVE that is co-located with GW). That is what I am referring to as NVE proxy for NVA. 

This is especially true when a GW has gets the mappings for all hosts in the DC either by a scrip file (as done by Microsoft system center), or by other off-net methods. 

Anyway, I think those points that describe various relationship between NVE&NVA   should be captured in the NVE<->NVA requirement. 

Linda

---

From: Thomas Narten <[email-masked]>
Date: Mon, 28 Oct 2013 13:20:03 -0400

Linda,

Sorry, but I'm having difficulty following this thread.

Linda Dunbar <[email-masked]> writes:

> Anyway, I think those points that describe various relationship
>  between NVE&NVA should be captured in the NVE<->NVA requirement.

Can you quickly summarize what those points are?

Thanks!
Thomas