Thank you, Yizhou. All of your suggestions look good and I think will be 
helpful in the document.

Best regards,

Sent from my mobile device

> On Feb 22, 2018, at 3:52 AM, Liyizhou <> wrote:
> Hi Kathleen,
> Thanks for your comments. Please see inlines with [yz].
> Rgds,
> Yizhou
> -----Original Message-----
> From: Kathleen Moriarty [] 
> Sent: Thursday, February 22, 2018 12:07 PM
> To: The IESG <>
> Cc:; Matthew Bocci 
> <>;;; 
> Subject: Kathleen Moriarty's No Objection on 
> draft-ietf-nvo3-hpvr2nve-cp-req-15: (with COMMENT)
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-nvo3-hpvr2nve-cp-req-15: No Objection
> When responding, please keep the subject line intact and reply to all email 
> addresses included in the To and CC lines. (Feel free to cut this 
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for your work on this draft.  In light of Spectre and Meltdown, I am 
> wondering if there needs to be more explicit text in the draft on tenant 
> isolation.
> Could you expand the pros and cons of the choices listed out in the security 
> considerations section in the following sentence?  Additional context would 
> be helpful for the reader.
>   One design point is whether the hypervisor
>   should supply the NVE with necessary information (e.g., VM addresses,
>   VN information, or other parameters) that the NVE uses directly, or
>   whether the hypervisor should only supply a VN ID and an identifier
>   for the associated VM (e.g., its MAC address), with the NVE using
>   that information to obtain the information needed to validate the
>   hypervisor-provided parameters or obtain related parameters in a
>   secure manner.
> [yz] I am thinking to add the following after the abovementioned text for 
> better explanations. 
> "The former approach can be used in a trusted environment so that the 
> external NVE can directly use all the information retrieved from the 
> hypervisor for local configuration. It saves the effort on the external NVE 
> side from information retrieval and/or validation. The latter approach gives 
> more reliable information as the external NVE needs to retrieve them from 
> some management system database. Especially some network related parameters 
> like VLAN IDs can be passed back to hypervisor to be used as a more 
> authoritative provisioning. However in certain cases, it is difficult or 
> inefficient for an external NVE to have access or query on some information 
> to those management systems. Then the external NVE has to obtain those 
> information from hypervisor.
> Since the communications happen in multiple ways, I'm wondering how isolation 
> is considered for each.  I see the text on authentication, ACLs and filter 
> rules and that is all good, but I'm wondering if more is needed (firmer 
> wording specific to isolation, etc.).  From the intro:
>   In such cases, there is
>   no need for a standardized protocol between the hypervisor and NVE,
>   as the interaction is implemented via software on a single device.
>   While in the Split-NVE architecture scenarios, as shown in figure 2
>   to figure 4, control plane protocol(s) between a hypervisor and its
>   associated external NVE(s) are required for the hypervisor to
>   distribute the virtual machines networking states to the NVE(s) for
>   further handling. The protocol is an NVE-internal protocol and runs
>   between tNVE and nNVE logical entities. This protocol is mentioned in
>   the NVO3 problem statement [RFC7364] and appears as the third work
>   item.
> Sect 4:  The authentication requirement could be stronger, is there a reason 
> it isn't?
>   Req-11: The protocol MUST allow the External NVE to authenticate the
>   End Device connected.
> If this is not in software as one option provides, there is no statement on 
> encrypted sessions, is there a reason why this is not needed?
> [yz] This document tries to address the requirement between hypervisor and 
> the external NVE, normally single hop only. The traffic isolation between 
> them is by locally significant tag, usually VLAN. Section 2.1 pp2 states 
> "Both the hypervisor and external NVE sides must agree on that tag value for 
> traffic identification, isolation, and forwarding." 
> [yz] As the protocol is used between server and ToR switch in data center 
> which is believed a trustworthy environment, encrypted session is a pretty 
> weak requirement over a single hop here.  VM migration is expected to be fast 
> and encryption session requires key exchanges which takes time and resources. 
> We do not intend to put it as a requirement. But existing mechanism like 
> MACsec is applicable if people wants secure channel. Maybe we can briefly 
> mention applicability of current secure channel mechanism in security 
> considerations section. 
> I also don't see a requirement on logging, should there be one?  If not, why 
> not? Are there security policy management functions that would need to track 
> the connections between tenant systems and external NVEs to prove isolation 
> or track the paths?
> I do see this in Sect 3.2:
>   An external NVE may report the mappings of its underlay IP
>   address and the associated TSI addresses to NVA and relevant network
>   nodes may save such information to their mapping tables but not their
>   forwarding tables.
> Is more needed?  Maybe not, but if you could explain or adjust text and 
> possibly the requirements, I'd appreciate it.
> [yz] The key "logging" information is basically the mapping information for 
> underlay<->overlay address and local tag<->VNI on NVA. The document is trying 
> to focus on split-NVE rather than NVE-NVA, so some of the interleaved 
> interaction between NVE and NVA are not specified and some like address 
> mappings are shown here and there in section 3.  I think adding something 
> like " locally significant tag and VNI mapping to be reported to NVA when 
> locally significant tag information is provided by hypervisor " to section 
> 3.1 makes sense as it is key information.

nvo3 mailing list

Reply via email to