Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution
draft-ietf-bess-virtual-subnet-07

[Ballot discuss]

(1) Surely extending a subnet from one to many data centres should
only be done if inter-data-centre traffic is all encrypted and
authenticated? I don't get why there isn't a MUST-like statement
here for such protection, and going a bit further, why some
interoperable form of protection for such traffic (e.g. IPsec,
MACsec) isn't recommended as being MTI in such cases. The huge
variety of potentially and actually sensitive traffic being handled
by VMs these days and which ought not be, and probably is not,
understood by folks doing routing seems to very strongly imply that
such protection should in fact be turned on all of the time. (But
stating that would be going beyond current IETF consenus on MTI
security as expressed in BCP61.  It'd still be a good idea I think
though.)

(2) I'm guessing one reaction to the above discuss point could be
"sure, but this is the wrong document." In that case, please show me
the right document and then tell me why a reference to that is not
needed here.

Note: none of the above is about RFC2119 MUST/SHOULD etc terms
even though I use them above. Just normal english that makes the
point would be fine.

[Ballot comment]

The secdir-review [1] raised a similar issue, but I don't think
the response to that is sufficient really. (The secdir reviewer
did think so.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06217.html

[Ballot comment]
I support Alia's Discuss. I see that there's proposed text to resolve that position.

I will remain a No-Objection if that proposed text is adopted, but I would be more comfortable if the proposed text was more specific than "may not work properly" - is there anything else that can go wrong, besides unbounded looping?

[Ballot discuss]
Thank you for a clear and well-written document.  I have one point
that is peripheral to most of the draft.

In Section 4.3, it says:

" In addition, for any other
  applications that generate intra-subnet traffic with TTL set to 1,
  these applications may not work properly in the Virtual Subnet
  context, unless special TTL processing for such context has been
  implemented (e.g., if the source and destination addresses of a
  packet whose TTL is set to 1 belong to the same extended subnet,
  neither ingress nor egress PE routers should decrement the TTL of
  such packet.  Furthermore, the TTL of such packet should not be
  copied into the TTL of the transport tunnel and vice versa)."

The idea of not decrementing TTL is quite concerning.  I can conjecture
cases where there is a routing loop between the relevant PEs - during
reconvergence when a host moves from one datacenter to another is
a trivial case. 

One approach may be to ask why a packet would have a TTL of 1 and
determine if this case must be resolved.  Another might detecting a loop
back to an out-of-datacenter PE and dropping the packet.  I'm sure you can
develop other good ideas and solutions.

[Ballot comment]
Just a couple of editorial comments:

- section 1, first paragraph, 2nd sentence:
The sentence is confusing, and may suffer from an editing or copy-paste error.  I'm not sure what "costly at the risk" of means.
Also, who "generally admits" this to be true?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-bess-virtual-subnet-03.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: aretana@cisco.com, bess-chairs@ietf.org, martin.vigoureux@alcatel-lucent.com, bess@ietf.org, draft-ietf-bess-virtual-subnet@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution) to Informational RFC


The IESG has received a request from the BGP Enabled Services WG (bess)
to consider the following document:
- 'Virtual Subnet: A BGP/MPLS IP VPN-based Subnet Extension Solution'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-11-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-virtual-subnet/ballot/


No IPR declarations have been submitted directly on this I-D.

Review sent to the authors:

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:

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:

I think that RFC4761, 4762, 4659, 5798 and 6513 should be Informational references.

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

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.

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:

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.

Please be consistent on how "Layer 2" and "Layer 3" is used..it is not consistent now.  My personal preference is "Layer x".

s/CE hosts/hosts

s/ARP proxy/an ARP proxy

Missing references:  "Link Layer Discovery Protocol (LLDP)", "VSI Discovery and Configuration Protocol (VDP)"

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational RFC is being requested, which is the proper type for this Document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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

Working Group Summary

  This document has generated a lot of discussions within L3VPN/BESS Working Group
  up to the level where this Document could be have been considered controversial.
  This was due to the existence of certain limitations of the solution described in this Document.
  The consensus nevertheless was in favour of the adoption, with the objective for the WG to then
  describe the limitations within the Document. This has been done.

Document Quality

  The Document Shepherd is aware of one implementation of this specification.

Personnel

  Martin Vigoureux is the Document Shepherd
  Alvaro Retana is the Responsible AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Shepherd has review the Document from both technical and editorial perspectives and found no issue.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concern. The Document has been intensively discussed and thus reviewed by the WG.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No need for such review

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern. The issues which arose that the time of WG adoption were resolved.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Every author and contributor has stated not being aware of any IPR relating to this Document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR has been disclosed against this Document

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

Following the resolution of the controversial limitations of the solution the consensus is quite solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No such extreme position was expressed publicly or privately

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The ID nits check is clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No need for such formal review

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All Normative References are RFCs

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downward reference

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This Document does not change the state of any other document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The Document does not require any action from IANA

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registry

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No section requires such automatic checks.