Hello, Linda
Here is my comments on the first draft:
- Section 4 describes how to swap the VLAN ID after a VM is moved. Is this a
solution choice? Or is it NVO3 requirements? This is a standard track draft, it
may not be too good to limit the implementation options. To resolve VLAN-IDs
usage in L2 access domains, other options (e.g. overlay only) shall be allowed.
Propose to reword: "One of the solution is ...."
- Section 5.1, I won't call L2 extension as a "problem". To extend underlay
connections is the precondition of setting up any overlay network.
- The optimization routing text under section 6 is good. But it is better to
make it clear that this definition is based on the assumption that hot potato
routing police is used in the DC.
- 6.1, preserving policies shall be the requirement of VM mobility. It shall be
supported even there is no routing optimization, right? Propose to move this
section into a generic section.
- Same comments on 6.2. ARP updating procedure is not only to optimize the
routing. It is also part of the optimization on the VM mobility procedure.
Propose to move this section into a generic section.
- From the NVE perspective, after VM mobility, the new NVE needs to have an
inner-outer mapping table configured in order to forward the VM traffic. The
default GW address is used for forwarding any outgoing TS traffic at the NVE.
Additional mapping rules are needed for inter-VN traffic, if triangular routing
would like to be avoided. This procedure looks easy if ARP proxy is supported
by the NVE. Otherwise, I agree with the draft, there are too many issues.
- 6.2.1 and 6.2.2, I see the only different is the NVE has the default GW MAC
address configured or not. Or from the TS perceptive, the attached NVE MAC
address is a bridge or default GW. I don't like the pDGW name. as a L3NVE with
embedded dGW function, its MAC address is the next hop address in TS view. From
L3 function level, there is no difference between a dGW and pDGW?
- 6.3, this is no optimization but enabling the host routing only, right? And I
don't think the NVE announcement is the right way to go in NVO3. It needs NVA's
involvement anyway.
- Section 7, I agree that it can be very mess in a very fragmented network. But
this is no solution except host routing.
- Section 10: We have to assume that the new location (including the network
connection between the new and old location) has the same security level as the
old location. Otherwise, the VM mobility shouldn't be allowed. With that
assumption, I do not see any additional security issues at VM mobility? If you
agree with me, I can provide some rewording on this section.
Have a nice day
Zu Qiang
>-----Original Message-----
>From: nvo3 [mailto:[email protected]] On Behalf Of Linda Dunbar
>Sent: Friday, October 24, 2014 1:40 PM
>To: [email protected]
>Subject: [nvo3] FW: New Version Notification for draft-merged-nvo3-ts-address-
>migration-01.txt
>
>Thanks to the review comments received from the NVO3 interim meeting and
>from the emails. We updated the section for L3 Address Migration and removed
>BGP solution from the draft.
>
>Hope this draft is ready for WG adoption.
>
>Linda
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>Sent: Friday, October 24, 2014 12:28 PM
>To: Rahul Aggarwal; Wim Henderickx; Ravi Shekhar; Luyuan Fang; Linda Dunbar;
>Rahul Aggarwal; Luyuan Fang; Wim Henderickx; Ravi Shekhar; Yakov Rekhter;
>Yakov Rekhter; Linda Dunbar; Ali Sajassi; Ali Sajassi
>Subject: New Version Notification for draft-merged-nvo3-ts-address-migration-
>01.txt
>
>
>A new version of I-D, draft-merged-nvo3-ts-address-migration-01.txt
>has been successfully submitted by Linda Dunbar and posted to the IETF
>repository.
>
>Name: draft-merged-nvo3-ts-address-migration
>Revision: 01
>Title: Overlay Network Tenant System Address Migration
>Document date: 2014-10-24
>Group: Individual Submission
>Pages: 21
>URL:
>http://www.ietf.org/internet-drafts/draft-merged-nvo3-ts-address-
>migration-01.txt
>Status: https://datatracker.ietf.org/doc/draft-merged-nvo3-ts-address-
>migration/
>Htmlized: http://tools.ietf.org/html/draft-merged-nvo3-ts-address-
>migration-01
>Diff: http://www.ietf.org/rfcdiff?url2=draft-merged-nvo3-ts-address-
>migration-01
>
>Abstract:
> This document describes the schemes to overcome the network-related
> issues to achieve seamless Virtual Machine mobility in data centers.
>
>
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
