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

["Larry Kreeger (kreeger)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Sunday, October 20, 2013 9:50 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>, Thomas Narten <[e-mail]<mailto:[e-mail]>>, David Black <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [nvo3] Suggested additional requirement to be added to "draft-ietf-nvo3-nve-nva-cp-req-00"

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 <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 20, 2013 2:31 PM
To: Larry Kreeger <[e-mail]<mailto:[e-mail]>>, Thomas Narten <[e-mail]<mailto:[e-mail]>>, David Black <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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