[bess] I-D Action: draft-ietf-bess-virtual-subnet-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the BGP Enabled Services Working Group of the 
IETF.

Title   : Virtual Subnet: A BGP/MPLS IP VPN-based Subnet 
Extension Solution
Authors : Xiaohu Xu
  Robert Raszuk
  Christian Jacquenet
  Truman Boyes
  Brendan Fee
Filename: draft-ietf-bess-virtual-subnet-03.txt
Pages   : 14
Date: 2015-11-09

Abstract:
   This document describes a BGP/MPLS IP VPN-based subnet extension
   solution referred to as Virtual Subnet, which can be used for
   building Layer 3 network virtualization overlays within and/or
   between data centers.


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


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] AD Review of draft-ietf-bess-virtual-subnet-02

[Xuxiaohu]

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
抄送: VIGOUREUX, MARTIN (MARTIN); 
bess-cha...@ietf.org; 
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