Hi Alvaro, We have updated the draft according to your comments and suggestions. Thanks again for your AD review of this document.
The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-bess-virtual-subnet-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-virtual-subnet-03 Best regards, Xiaohu From: Xuxiaohu Sent: Monday, November 02, 2015 1:04 PM To: Alvaro Retana (aretana); draft-ietf-bess-virtual-sub...@ietf.org Cc: VIGOUREUX, MARTIN (MARTIN); bess-cha...@ietf.org; bess@ietf.org Subject: Re: AD Review of draft-ietf-bess-virtual-subnet-02 Hi Alvaro, Thanks for your detailed AD review. We will update the draft according to your comments soon. Best regards, Xiaohu (on behalf of all co-authors) ________________________________ 发件人: Alvaro Retana (aretana) [aret...@cisco.com] 发送时间: 2015年10月28日 5:38 收件人: draft-ietf-bess-virtual-sub...@ietf.org<mailto:draft-ietf-bess-virtual-sub...@ietf.org> 抄送: VIGOUREUX, MARTIN (MARTIN); bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> 主题: AD Review of draft-ietf-bess-virtual-subnet-02 Dear authors: I just finished reading this document. All of what is described in this document is straight forward, so much so that it requires no change to existing technology, which makes me think that users/operators have been able to do this all along. Is that correct? Is there anything special that was missing that this document brings to light? Being one of several possible solutions for "network virtualization overlays within and/or between data centers", I'm wondering about the value of publishing what amounts to a set of use cases without even discussing when their use would be suitable (declared out of scope). I reviewed the discussions on the lists (l3vpn/bess) and can clearly see why the Shepherd characterized the document as "could have been considered controversial". Had I reviewed the document at adoption time I probably would have ended up in the rough side of the consensus. There's obviously no need to revisit the topic of what do to with this document since clearly the WG Chairs believe there is consensus to publish. I do have some other comments (below). In general some of the text could be made easier to read (see some nits below). I would like to see my comment about rfc2119 language addressed (and an update published) before starting the IETF Last Call. Thanks! Alvaro. Major: 1. The use of rfc2119 keywords is not required. Note that in general these keywords "MUST only be used where it is actually required for interoperation", but you're using them to apparently express requirements w/out specific guidance or to restate what is normal network operation . For example: * In Section 3.3. (CE Host Discovery) the text reads: "PE routers SHOULD be able to discover their local CE hosts… PE routers could accomplish local CE host discovery by…ARP or ND…LLDP…VDP), or even interaction with the data center orchestration system…" There is no specific mechanism mandated that supports the use of "SHOULD". * In Section 3.4. (ARP/ND Proxy): "PE routers SHOULD only respond to an ARP request or Neighbor Solicitation (NS) message for a target host when it has a best route for that target host in the associated VRF and the outgoing interface of that best route is different from the one over which the ARP request or NS message is received." Isn't this how proxy ARP already works? Am I missing something that requires the use of "SHOULD" in this document? * Section 4.3. (TTL and Traceroute) describes a limitation and then says "…unless special TTL processing for such case has been implemented (e.g., if the source and destination addresses…belong to the same extended subnet, neither ingress nor egress PE routers SHOULD decrement the TTL…TTL of such packet SHOULD NOT be copied into the TTL of the transport…" In this case the rfc2119 keywords are used as part of an example (e.g.)..which doesn't really support the use of "SHOULD/SHOULD NOT". Is the intent to specify this "special processing" in this document? If so, why "SHOULD" and not "MUST"? Algo, given that the text appears in the Limitations section, if you're mandating the "special processing" then it wouldn't be a limitation anymore.. Minor: 1. I think that RFC4761, 4762, 4659, 5798 and 6513 should be Informational references. 2. You first use "VS" in Section 3.6. I'm assuming this is related to "virtual subnet", but there's no explicit association. 3. Multicast. Section 3.2. (Multicast) says that for "IP multicast between CE hosts of the same virtual subnet, MVPN technologies [RFC6513] could be directly used without any change". I'm assuming that you're not referring to link-local multicast (between hosts on the same subnet) because later (Section 4.2) you say that "link-local multicast traffic cannot be supported". Please clarify in 3.2 what type of multicast you're talking about, and/or which you're not. 4. Section 4.3. (TTL and Traceroute). What does this mean: "traceroute output would reflect the fact that these two hosts belonging to the same subnet are actually connected via an virtual subnet emulated by ARP proxy, rather than a normal LAN"? I think I know, but please be specific in the text. Nits: 1. Section 1. (Introduction) * s/commonly used in those situations/commonly used in situations * There are a couple of very long sentences that could be simplified ― they make sense, but other reviewers may not capture the essence. Just a suggestion * OLD> * * As a result, the traffic from a cloud user (i.e., a VPN user) which * is destined for a given server located at one data center * location of such extended subnet may arrive at another data * center location firstly according to the subnet route, and then * be forwarded to the location where the service is actually * located. This suboptimal routing would obviously result in an * unnecessary consumption of the bandwidth resource between data * centers. Furthermore, in the case where the traditional VPLS * technology [RFC4761] [RFC4762] is used for data center * interconnect and default gateways of different data center * locations are configured within the same virtual router * redundancy group, the returning traffic from that server to the * cloud user may be forwarded at layer2 to a default gateway * located at one of the remote data center premises, rather than * the one placed at the local data center location. This * suboptimal routing would also unnecessarily consume the bandwidth * resource between data centers * NEW> * * As a result, the traffic between a specific user and server, in different * data centers, may first be routed through a third data center. * This suboptimal routing would obviously result in an * unnecessary consumption of the bandwidth resource between data * centers. Furthermore, in the case where traditional VPLS * technology [RFC4761] [RFC4762] is used for data center * interconnect, return traffic from a server may be forwarded to a * default gateway located in a different data center due to the configuration * in a virtual router redundancy group. This * suboptimal routing would also unnecessarily consume the bandwidth * resource between data centers. 1. Please be consistent on how "Layer 2" and "Layer 3" is used..it is not consistent now. My personal preference is "Layer x". 2. s/CE hosts/hosts 3. s/ARP proxy/an ARP proxy 4. Missing references: "Link Layer Discovery Protocol (LLDP)", "VSI Discovery and Configuration Protocol (VDP)"
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
