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

[Alvaro Retana (aretana)]

On 11/10/15, 2:18 AM, "Xuxiaohu" 
> wrote:

Xiaohu:

Hi!

We have updated the draft according to your comments and suggestions.

I just have a couple of small items.  Please see my comments below..

I'm going to start the IETF Last Call and put this document up for the IESG 
Telechat on Dec/3.  Please post an update based on the comments below by the 
end of the week.

Thanks!

Alvaro.

. . .
Major:

  1.  The use of rfc2119 keywords is not required.

You left in the rfc2119 boilerplate and reference, please take them off.

...

  1.  You first use "VS" in Section 3.6.  I'm assuming this is related to 
"virtual subnet", but there's no explicit association.

I see that you expanded in 3.6, but now VS is used for the first time in 3.8 
w/out explicitly expanding.

Solution: in 3.6  s/Virtual Subnet/Virtual Subnet (VS)

___
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]

Alvaro,

I will update it ASAP.

Best regards,
Xiaohu

From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, November 11, 2015 2:27 AM
To: Xuxiaohu; 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

On 11/10/15, 2:18 AM, "Xuxiaohu" 
<xuxia...@huawei.com<mailto:xuxia...@huawei.com>> wrote:

Xiaohu:

Hi!

We have updated the draft according to your comments and suggestions.

I just have a couple of small items.  Please see my comments below..

I'm going to start the IETF Last Call and put this document up for the IESG 
Telechat on Dec/3.  Please post an update based on the comments below by the 
end of the week.

Thanks!

Alvaro.

. . .
Major:

  1.  The use of rfc2119 keywords is not required.

You left in the rfc2119 boilerplate and reference, please take them off.

...

  1.  You first use "VS" in Section 3.6.  I'm assuming this is related to 
"virtual subnet", but there's no explicit association.

I see that you expanded in 3.6, but now VS is used for the first time in 3.8 
w/out explicitly expanding.

Solution: in 3.6  s/Virtual Subnet/Virtual Subnet (VS)

___
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<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 mult

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

[Xuxiaohu]

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 
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

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

[Alvaro Retana (aretana)]

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