BGP/MPLS IP Virtual Private Networks (VPNs)
draft-ietf-l3vpn-rfc2547bis-03

[Note]: '2004-10-29:Document approved and in RFC queue, but it has a normative dependency on draft-ietf-idr-bgp-ext-communities-07.txt, which is still in the IDR WG. Thus, document cannot be published until bgp-ext-communities is also in the RFC queue.' added by Thomas Narten

[Ballot discuss]
draft-ietf-l3vpn-rfc2547bis:

The abstract is very long -- too long?  There are *far* too many authors.

There are many unexpanded acronyms; among these are DLCI, VC, VLAN, and NLRI.

13.2: Give the proper citation for TCP-MD5.

[Ballot comment]
draft-ietf-l3vpn-rfc2547bis-01:

  The Abstract is very long.  There must be a way to make it shorter.

  Please spell out acronyms the first time they are used. 

  In section 1.6: s/privacy/confidentiality/

  In section 13.1: s/Cryptographic privacy/Cryptographic confidentiality/

  Please rename section 13 to "Security Considerations."  To be consistent,
  you might consider adding "Considerations" to the end of the section 14
  and section 15 titles too.

draft-ietf-l3vpn-as2547-05:

  In the Abstract, please replace "[BGP-MPLS-IP-VPN]" with the RFC number
  once it is assigned.

  Please rename section 6 to "Security Considerations."

[Ballot discuss]
Discuss in tracker:
asrfc2547bis-07.txt

The QoS discussion is too much of a sketch - as the protocol
document says, though QoS is not the primary topic in rfc2547bis,
it's "key component of any VPN service".  So this document should
expand "hose model", which is not explained here or in RFC 3270,
and why it is the natural fit.

rfc2547bis-01.txt

minor fix - the RD is IANA registered with IETF Consensus, but
that's not given with a citation to RFC 2434.

[Ballot comment]
DISCUSS by Steve already covers my concerns and concerns received
from the ops directorate. For completeness sake, I list the comment
that I received from Pekka Savola from the opsn directorate:

rfc2547bis
----------

(I didn't read this document, just scanned through the typical nits.)

editorial
=========

- cut down the abstract!  40+ lines is ridiculously long.  I'd say
10-15 is the maximum!  Most of this could probably go at the top of
the Introduction.

- maybe rename Authors' Addresses to "Contributors" and tail down the
list a bit; take off Erik and Yakov to a separate "Editors' Addresses"
section?

- there is no Security Considerations section.

applicability statement
-----------------------

substantial
===========

- security considerations section is missing.

- more verbiage on security issues for section 1 should be added;
  maybe add something like the follows as the second-last paragraph:

  If the customer's network has high security requirements and/or the
  customer cannot trust the service provider to be able to secure its
  network sufficiently so that the VPNs would neverbe compromised, the
  customer may want to consider using a different approach for VPNs,
  e.g., IPsec-protected CE-CE VPNs [IPSEC-VPN].  Doing the VPNs on
  your own may also be an attractive approach if the customer is
  worried that the service prodiver might be performing or be forced
  to perform (without telling the customers) wire-tapping, "lawful
  interception", intelligence gathering, etc. which would compromise
  the confidentiality of the intra-site communications.

(the key point here, compared to the already existing paragraph, is
the trust in the SPs ability to secure the network properly, and the
trust to in the SP to provide confidential service.  With all kinds of
wiretapping etc. getting more and more common, I think this should be
spelled out.)

editorial
=========
- some of those normative references have not been approved yet (just
stating to call it out explicitly that the doc won't be published
before the others are done as well)

- the abstract seems a bit half-assed ("..  and other documents
listed in the References section"

- includes some use of uppercase keywords, which may be inappropriate
for an applicability statement..

- the text in section 7 of non-support of IPv6 might not hold the
test of time, i.e., if this ends up being published as an RFC, the RFC
might be factually wrong in a year or two.  Maybe a reason to reword,
and to look for similar issues elsewhere in the doc ?

- section 14 on QoS might mention traffic shaping (or similar) at the
egress interface (i.e.: traffic from the Internet to the site),
because that's what's the more ifficult problems, worms, DDoS etc.
considereed.  Of course, there are no MPLS/VPN -specificity there.

nits
====
- old boilerplates
- reference in the abstract
- in section 2, s/In an IGP/If an IGP/
- in section 3, s/wherea/where a/
- in section 6.2, s/routers to/routers do/
- in section 15, s|RFC BGP/MPLS|BGP/MPLS|

[Ballot comment]
document: draft-ietf-l3vpn-as2547-05.txt
- references section has:

  [IF-MIB] "The Interfaces Group MIB using SMIv2", McCloghrie,
  Kastenholtz, RFC 2233, November 1997
  Should point to RFC2863 instead since 2863 obsoletes 2233!

- references section also hs:

  [RFC2570] "Introduction to Version 3 of the Internet-standard Network
  Management Framework", Case, Mundy, Partain, Stewart, RFC 2570, April
  1999

  [RFC2571] "An Architecture for Describing SNMP Management
  Frameworks", Harrington, Presuhn, Wijnen, RFC 2571, April 1999

  [RFC2572] "Message Processing and Dispatching for the Simple Network
  Management Protocol (SNMP)" Case, Harrington, Presuhn, Wijnen, RFC
  2572, April 1999

  These 3 have been obsoleted. New RFCs are: 3410, 3411 and 3412.
  But... there are no citations to these references, so they probably
  should be removed.

- At most places where they talk about "MIB" or even worse "MIBs" they
  mean "MIB modules" and "MIB modules" respectively. Would be good to fix
  that.

- I am worried about them using MIB module names that (as far as I know)
  will NOT get published under that name. The reason why that will not happen
  is that they tend to rename their mib modules when they get approved.
  Several of the MIB modules they mention are not even in AD evaluation.
  Maybe it is better to just name the title of the MIB module they intend
  to speak about. They say that "...can be maneged with XXX" so the "can"
  I think makes it OK to be informative reference. But that will let these
  module names (that most probably will change) go into a PS document.
  In fact the "title" of the MIB module for [L3VPN-MIB] has already changed,
  so using the title seems risky too.

- They talk about (page 17):
          Presumably the PE routers will not accept unauthorized TCP
          connections or SNMP commands, so such traffic will be thrown
          away; the danger is that the PE may need to use a significant
  I can live with it. But SNMP has a noAuthnoPriv mode which means that
  SNMP commands (under configuration control) can be OK to come in as
  unauthenticated. There is still the normal authorization, but if not
  authenticated, then that does not help of course.

[Ballot comment]
Reviewed by Lucy Lynch, Gen-ART

The rfc2547bis document is not a model of clarity, but as2547 explains a lot. Perhaps it would be appropriate to add to the abstract of rfc2547bis a note saying "READ AS2547 FIRST"?

Because there are already DISCUSSes on the document, I'm not casting a DISCUSS based on the large number of language comments in the review. But they should be looked at.

IANA Last Call Comments - Follow-up
The IANA Considerations section should be
revised to reflect what actions need to be
taken.

Comments from Eric Rosen:
The draft specifies  the use of an AFI (Address  Family Identifier) value of 1,  to indicate  "IPv4  address", together  with  an SAFI  value  of 128 to
indicate "MPLS labeled VPN address". 

The use of AFI value 1 for IP is as currently specified in the IANA registry "Address Family Identifier", so no action need be taken with respect to it.

However, the SAFI value 128 is currently specified as "Private Use" in the IANA "Subsequent  Address  Family  Identifier" registry. This  should be
changed from "private use" to "MPLS-labeled VPN address".

The value 128 was chosen about five years ago when the initial deployments of this technology were made, as  at that time there was no standards activity in this  area.  At the present time, there are hundreds of deployments, some extremely large, and it is not  feasible to change the assignment.

[Ballot comment]
I am choosing to abstain on this document because I can see no hope of a correction
at this stage; there is enough thrust behind this mammal that it is known to fly,
and pointing out that picking a bird rather than a pig would have been better
just isn't going to be heard.

This, I felt, was the most unintentially funny (or heartbreaking) piece in the pair:

  The basic principle is to model each VPN as a self-contained
  "internet", where each site makes one or more access connections to a
  SP, sends the SP its routing information, and then relies on the SP
  to distribute routing information to and from the other sites in that
  same VPN.  The service differs from Internet service, however, in
  that the SP strictly controls the distribution of this routing
  information so that routes from within a VPN are not sent outside the
  VPN, unless that is explicitly authorized by the customer.  In fact,
  even within the VPN, the distribution of routes may be controlled by
  the SP so as to meet some policy of the customer.

Well should they put internet in lower case and quotes.

[Ballot comment]
draft-ietf-l3vpn-as2547:

I liked it a lot.  I hope there's no static because there's no section labeled "Security Considerations"; the "Security" section is quite good.

[Ballot discuss]
draft-ietf-l3vpn-rfc2547bis:

The abstract is very long -- too long?  There are *far* too many authors.

There are many unexpanded acronyms; among these are DLCI, VC, VLAN, and NLRI.

4.2: I'm disturbed by the format of the RD.  It gives an edge to today's ISPs, which have 2-byte ASNs; possible newer ISPs would be limited to a 2-byte field for (effectively) customer number.  Maybe that's enough -- but I really don't understand why the type field is 2 bytes; I'd be astonished if there were every more than about 4 bits worth of variants.  (But I see that there is nothing in this document that supports IPv6.  Should there be?)

13.2: Give the proper citation for TCP-MD5.

[Ballot comment]
draft-ietf-l3vpn-rfc2547bis-01:

The abstract is pretty long -- most of what's there would be better used as "Introduction" text.

The document is missing a "Security Considerations" section, though it does talk about security in several places -- most notbaly section 13.  Perhaps section 13 should be titled "Security Considerations".

draft-ietf-l3vpn-as2547-05.txt:

Same comment on "Security Considerations", though section 6 is titled "Security".

[Ballot comment]
The abstract is pretty long -- most of what's there would be better used as "Introduction" text.

The document is missing a "Security Considerations" section, though it does talk about security in several places -- most notbaly section 13.  Perhaps section 13 should be titled "Security Considerations".

[Ballot comment]
The abstract is pretty long -- most of what's there would be better used as "Introduction" text.

The document is missing a "Security Considerations" section, though it does talk about security in several places.  Perhaps one of those sections should be titled "Security Considerations".

IANA Last Call Comments:
In response to the first paragraph in the IANA section,

We understand the above to create a new registry for "Route Distinguisher Type Field Values". 
0, 1, and 2 are defined by this document (Type 0,
Type 1, and Type 2).  Please note there is a typo in the above paragrah (hihg-order should be high-order).

In response to the second paragraph, 
Are these values to be newly assigned or do they exist in a current registry?  This section should be more clear as to what the IANA needs to do.

2003-12-25:

From: Ross Callon
To: narten@us.ibm.com, Margaret.Wasserman@nokia.com, zinin@psg.com
Cc: Ronald Bonica , Rick Wilder ,
  rcallon@juniper.net, yakov Rekhter , skh@nexthop.com,
  rcallon@juniper.net
Date: Thu, 25 Dec 2003 11:52:33 -0500
Subject: draft-ietf-l3vpn-rfc2547bis-01.txt

The document draft-ietf-l3vpn-rfc2547bis-01.txt has now passed last call
in both L3VPN and IDR working groups, and is ready for IESG review. The
associated applicability statement passed last call a while ago in the
L3VPN working group, and is also ready for IESG review.

These depend upon the BGP extended communities attribute.

thanks, Ross


>To: Ross Callon , Rick Wilder ,
>    Ron Bonica , skh@nexthop.com
>cc: yakov@juniper.net
>Subject: last call ended
>Date: Tue, 23 Dec 2003 06:03:50 -0800
>From: Yakov Rekhter
>
>Folks,
>
>The IDR WG Last Call on draft-ietf-l3vpn-rfc2547bis-01.txt
>ended up with no comments.
>
>Yakov.