Virtual Hub-and-Spoke in BGP/MPLS VPNs
draft-ietf-l3vpn-virtual-hub-08

[Ballot discuss]
The shepherd writeup appears to have been written for version -04, and there have been two updates since then.  I find it curious, then, that the significant items called out in question 11 weren't fixed.  In particular, you need a normative reference to [RFC2119], and a reference is needed to [IANA-SAFI] that also looks like it should be normative (there are citations to both, but the references are missing).

[Ballot comment]
-- Section 2 --

  The approach described in this document allows to reduce the
  number of PEs that have to maintain all these routes by requiring
  only a subset of such PEs to maintain all these routes.

There seems to be a word missing: it allows *who* to reduce the number?  Or maybe you just meant to say that it allows the number to the reduced?

[Ballot discuss]
I really wanted to ballot "Yes" on this document: it is a "Good Thing",
and I find no issues of substance. But I am disappointed that the
document was presented for IESG evaluation with issues identified by
idnits that will require author action to resolve (rather than being
purely editorial nits that could be left to the RFC Editor).

What reference was intended for [IANA-SAFI]?  Only the authors can know
what they meant.

The IPv4 addresses used in the examples should, as far as possible, be
taken from the example ranges specified in RFC 5735. Only the authors
can correctly substitute addresses.

[Ballot comment]

I'm not convinced that there are no new security
considerations here. It may be true that there are no new
vulnerabilities, but that's not the same thing. For
example, presumably V-hubs are more attractive targets
for DoS or to subvert. That is, perhaps the impact of
existing vulnerabilites is increased for e.g. hubs which
could change the overall risk. 

And on the positive side, perhaps following this approach
might make it easier to start to deploy BGP security
mechanisms, e.g. if you start with hubs and then extend
out to spokes and vanilla PEs. 

However, I didn't really understand the thing enough for
this to be more than a fairly random passing comment:-)

[Ballot comment]
In 2. Overview

  Consider a set of PEs that maintain VRFs of a given VPN. In the
  context of this VPN we designate a subset of these PEs as "Virtual
  Spoke" PEs (or just Virtual Spokes), while some other (non-
  overlapping) subset of these PEs will be "Virtual Hub" PEs (or just
  Virtual Hubs), with the rest of the PEs in the set will be "vanilla"
  PEs (PEs that implement the [rfc4364] procedures, but do not
  implement procedures specified in this document).

I'm not parsing the second sentence. Should it be "... *while* the rest of the PEs in the set ..."? But I'm guessing.

In 5. Internet Connectivity, in the following two paragraphs:

  The first alternative is when a PE that maintains Internet routes
  also maintains a VRF of a given VPN. In this case the Internet
  connectivity for that VPN MAY be provided by provisioning in the
  VPN's VRF on that PE a default route pointing to the routing table on
  that PE that maintains the Internet routes. This PE MUST NOT be
  provisioned as a V-spoke for that VPN (this PE may be provisioned as
  either a V-hub, or as a "vanilla" PE). If this PE is provisioned as a
  V-hub, then this PE MUST originate a VPN-IP default route. The route
  MUST carry both RT-VPN and RT-VH of the V-hub (see section "Routing
  Information Exchange" for the definition of "RT-VPN" and "RT-VH").
  Thus this route will be imported by all the V-spokes associated with
  the V-hub, as well as by other V-hubs and "vanilla" PEs.  An
  implementation MUST support the first alternative.

Does this MUST apply to all PEs?

  The second alternative is when a site of a given VPN has connection
  to the Internet, and a CE of that site advertises an IP default route
  to the PE connected to that CE. This alternative has two sub-cases:
  (a) PE is provisioned as a V-hub, and (b) PE is provisioned as a V-
  spoke. An implementation MUST support the sub-case (a). An
  implementation MAY support the sub-case (b).

Does the sub-case (a) MUST *also* apply to all PEs? So, two MUSTs (and a MAY)?

In 7. Multicast Considerations

  The V-hub/V-spoke architecture, as specified in this document,
  affects certain multicast scenarios. In particular, it affects
  multicast scenarios where the source of a multicast flow is at a site
  attached to a V-hub, and a receiver of that flow is at a site
  attached to a V-spoke that is not associated with that same V-hub.
  It also affects multicast scenarios where the source of a multicast
  flow is at a site attached to a V-spoke, a receiver of that flow is
  at a site attached to a different V-spoke, and the set intersection
  between the V-hub(s) associated with the first V-spoke and the V-
  hub(s) associated with the second V-spoke is empty. It may also
  affect multicast scenarios where the source of a multicast flow is at
  a site connected to a V-spoke, a receiver of that flow is at a site
  attached to a different V-spoke, and the set intersection between the
  V-hub(s) associated with the first V-spoke and the V-hub(s)
  associated with the second V-spoke is non-empty (the multicast
  scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by
  the first V-spoke are not imported by the second V-spoke).

Does everyone (except me) understand what is meant by the several "affects" in this paragraph? Are they all saying that the same thing happens in various situations, or does what happens in each situation differ?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l3vpn-virtual-hub-06, which is currently in Last Call, and has the following comments:

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

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:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Virtual Hub-and-Spoke in BGP/MPLS VPNs) to Proposed Standard


The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'Virtual Hub-and-Spoke in BGP/MPLS VPNs'
  as Proposed Standard

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 2013-06-06. 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


  With BGP/MPLS VPNs, providing any-to-any connectivity among sites of
  a given Virtual Private Network would require each Provider Edge
  router that has one or more of these sites connected to it to hold
  all the routes of that Virtual Private Network. The approach
  described in this document allows to reduce the number of Provider
  Edge routers that have to maintain all these routes by requiring only
  a subset of these routers to maintain all these routes.

  Furthermore, when Provider Edge routers use ingress replication to
  carry multicast traffic of VPN customers, the approach described in
  this document may under certain circumstances allow to reduce
  bandwidth inefficiency associated with ingress replication, and to
  redistribute the replication load among Provider Edge routers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-virtual-hub/ballot/


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

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

Standard track is requested in the document header, and is the proper type of RFC since the document defines specific behavior that must be implemented by routers in a consistent manner to achieve the goal.

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

With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers.

- Working Group Summary:

Nothing particular (no objection from working group contributors during adoption, not real objection during WGLC, except for one comment challenging the scope of the document but without a follow-up from the commenter).

- Document Quality:

There are no concerns about the document quality. An extensive review was done on WGLC by Eric Rosen (co-author of BGP/MPLS specifications to which these specifications relate), which were resolved after substantive changes to the document.
No information has been provided related to current implementations or plans for implementations.

- Personnel:

Document Shepherd is Thomas Morin as l3vpn WG co-chair, and Responsible Area Director is Stewart Bryant.

(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 document Shepherd did a complete review of the document, both editorial and technical concluding that the document quality is very good from and that the document is ready for publication. A few points probably deserving editorial clarifications were noted, which can be addressed during next steps in the publication process.

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

No concerns.

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

None of the above applies, AFAICT.

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

There was one comment by Robert Raszuk during WGLC claiming that these specifications should be extended "to accomodate even further scaling enhancements not just for SP PEs but also for actual customer VPN sites.". However, the commenter did not advertise an intent to actually contribute such an extension, and either way the publication of the document as-is would not prevent such a proposal to be pursued later.

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

Yes, all authors have confirmed so.

(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 disclosure was filed relating to 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?

Beyond co-authors, a significant number of people expressed interest on the proposal, including both vendors and operators.

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

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


Some issues found with idnits 2.12.15 :
- use of RFC1918 addresses: as examples in this document, they seem legitimate since networks represented are Virtual Private Networks
- the copyright year in the IETF Trust and authors Copyright Line does not match the current year => fix needed
- idnits thinks that "'he document date (May 2012) is 310 days in the past", but this is a parsing error, the document date (Dec 12 2012) is less than 4 month ago.
- idnits finds two missing references: 'RFC2119' on line 112, and 'IANA-SAFI' on line 642 (of -04 version of the draft) => fix needed

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

N/A

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

No, all normative references are already published as 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, all normative references of this document are PROPOSED STANDARD or BCP RFCs.

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

No.

(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).

N/A (This document introduces no new IANA Considerations)

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

N/A (this document introduces no new IANA Considerations)

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

N/A