Network based IP VPN Architecture Using Virtual Routers
draft-ietf-l3vpn-vpn-vr-03

[Ballot discuss]
draft-ietf-l3vpn-vpn-vr

12. Quality of Service
   
  This architecture can utilize a variety of Quality of Service
  mechanisms. QoS mechanisms developed for physical routers can be
  used with VRs, on a per-VR basis, including classification,
  policing, drop policies, traffic shaping and scheduling/bandwidth
  reservation. The architecture allows separate quality of service
  engineering of the VPNs and the backbone.

The topic of QoS in a VR architecture appears to me to be substantially more complex than the above text indicate. A VR solution will have the normal issues with handling resource and marking across the boundaries from inside to outside a tunnel. In addition there will be issues with translating different QoS models or adapt to different types of engineering between the different levels of VPNs and the real network.

The chapter should be rewritten to indicate that although there are possibilities they will not be a general as one might think. And in addition there should be some references to the issues that exist.

This also impact section 14 in draft-ietf-l3vpn-as-vr.

[Ballot discuss]
draft-ietf-l3vpn-vpn-vr

12. Quality of Service
   
  This architecture can utilize a variety of Quality of Service
  mechanisms. QoS mechanisms developed for physical routers can be
  used with VRs, on a per-VR basis, including classification,
  policing, drop policies, traffic shaping and scheduling/bandwidth
  reservation. The architecture allows separate quality of service
  engineering of the VPNs and the backbone.

The topic of QoS in a VR architecture appears to me to be substantially more complex than the above text indicate. A VR solution will have the normal issues with handling resource and marking across the boundaries from inside to outside a tunnel. In addition there will be issues with translating different QoS models or adapt to different types of engineering between the different levels of VPNs and the real network.

The chapter should be rewritten to indicate that although there are possibilities they will not be a general as one might think. And in addition there should be some references to the issues that exist.

[Ballot discuss]
12. Quality of Service
   
  This architecture can utilize a variety of Quality of Service
  mechanisms. QoS mechanisms developed for physical routers can be
  used with VRs, on a per-VR basis, including classification,
  policing, drop policies, traffic shaping and scheduling/bandwidth
  reservation. The architecture allows separate quality of service
  engineering of the VPNs and the backbone.

The topic of QoS in a VR architecture appears to me to be substantially more complex than the above text indicate. A VR solution will have the normal issues with handling resource and marking across the boundaries from inside to outside a tunnel. In addition there will be issues with translating different QoS models or adapt to different types of engineering between the different levels of VPNs and the real network.

The chapter should be rewritten to indicate that although there are possibilities they will not be a general as one might think. And in addition there should be some references to the issues that exist.

[Ballot comment]
> An important consideration to remember is that one may have any
> number of INDEPENDENT BGP systems carrying VPN-related information.
> This is unlike the case of the Internet, where the Internet BGP
> system must carry all the Internet routes. Thus one significant
> (but perhaps subtle) distinction between the use of BGP for the
> Internet routing and the use of BGP for distributing VPN-related
> information, as described in this document is that the former is not
> amenable to partition, while the latter is.

Yes. But given what we learned in the routing and addressing workshop,
perhaps there should still be a warning that VPN-related BGP
information can still form a large fraction of the entire
routing table in a provider site.

[Ballot comment]
This abstain comment applies to draft-ietf-l3vpn-bgpvn-auto.
I believe that the security considerations section is problematic. 
It says, in particular:

  It is of critical importance that a particular PE should not be
  "discovered" to be attached to a particular VPN unless that PE
  really is attached to that VPN, and indeed is properly authorized to
  be attached to that VPN.  If any arbitrary node on the Internet
  could start sending these BGP advertisements, and if those
  advertisements were able to reach the PE routers, and if the PE
  routers accepted those advertisements, then anyone could add any
  site to any VPN.  Thus the auto-discovery procedures described here
  presuppose that a particular PE trusts its BGP peers to be who they
  appear to be, and further that it can trusts those peers to be
  properly securing their local attachments.

  If a particular remote PE is not a BGP peer of the local PE, then
  the information it is advertising is being distributed to the local
  PE through a chain of BGP speakers.  The local PE must trust that
  its peers only accept information from peers that they trust in
  turn, and this trust relation must be transitive.  BGP does not
  provide a way to determine that any particular piece of received
  information originated from a BGP speaker that was authorized to
  advertise that particular piece of information.  Hence the
  procedures of this document should be used only in environments
  where adequate trust relationships exist among the BGP speakers.

The problem, certainly not unique to this document, is that the set of
bgp speakers can change as the path changes and any particular
bgp speaker cannot directly evaluate the trust relationships between
peers distant in the path.    That creates the transitive trust requirement
that the document notes.  In many cases, the potential set of bgp
peers to which transitive trust might have to be extended is not
bounded. 

Put another way, the document describes a risk, and it should
stop there--there is a risk that someone injecting false information into
BGP would allow unauthorized hosts to attach to a VPN. 
Assuming that there will be environments where the transitive trust relationships
are sufficient to avoid this problems seems to me to presume a stability in
the set of actors which may not be appropriate over time even in environments
where adequate trust relationship exist initially.  It also might be taken as
encouraging the common, but not very useful, idea that there are security
perimeter aspects to the vpn network topology.

This is not a discuss because these are informational documents and because they
are no longer the subject of active work.

[Ballot discuss]
Eric Rescorla provided IETF Last Call comments (his SecDir Review)
  on draft-ietf-l3vpn-as-vr-02.  No response was posted.  His comments
  were significant in my view, and I think that a response is needed in
  order for me to determine if the working group considered the issues
  that Eric raised.

[Ballot comment]
draft-ietf-l3vpn-bgpvpn-auto-08.txt

Lists 2119 but does not cite it. Contains one inappropriate MUST.

"Two interwoking scenarios are considered..."

Interesting thought :-)

draft-ietf-l3vpn-as-vr-02 (from Spencer Dawkins)

This document dates from the PPVPN days (before L2VPN and L3VPN split into two working groups). If there is any energy left for editorial changes, it might be nice to make it more clearly an L3VPN document - less confusing for the reader, anyway.

Should this and draft-ietf-l3vpn-vpn-vr-03.txt contain a
statement that they are being published for the record?

[Ballot comment]
draft-ietf-l3vpn-bgpvpn-auto-08.txt

Lists 2119 but does not cite it. Contains one inappropriate MUST.

"Two interwoking scenarios are considered..."

Interesting thought :-)

draft-ietf-l3vpn-as-vr-02 (from Spencer Dawkins)

This document dates from the PPVPN days (before L2VPN and L3VPN split into two working groups). If there is any energy left for editorial changes, it might be nice to make it more clearly an L3VPN document - less confusing for the reader, anyway.

PROTO

-------- Original Message --------
Subject: RE: VR documents
Date: Tue, 20 Jun 2006 12:31:24 -0400
From: Rick Wilder
To: 'Mark Townsley'
CC: 'Ron Bonica' ,


I didn't get hold of Ross, but here is the summary info.

Rick


--------------------------------------------------------------------


1.a) Have the chairs personally reviewed this version of the Internet Draft
(ID), and in particular, do they believe this ID is ready to forward to the
IESG for publication?

Yes, Ross and Rick have reviewed the specification.

1.b) Has the document had adequate review from both key WG members and key
non-WG members?

Yes.

Do you have any concerns about the
depth or breadth of the reviews that have been performed?

No. The document is mature and all interested parties have had all concerns
addressed.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No, implementation issues have been adequately addressed

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of?  For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it.  In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No. The approach is pretty straightforward and well documented.

1.e) 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?

This is a straightforward document which I believe is well understood.
Though the approach described in the document has not become the dominant
solution, it is valuable to capture how the solution works.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes. There were no problems found.

1.h) Is the document split into normative and informative references?

Yes, both normative and informational references are listed.

Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

No.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

. Technical Summary

This document describes a network-based Virtual Private Network (VPN)
architecture using the virtual router (VR) concept. Multiple VRs can exist
in a single physical device. A VR emulates all the functionality of a
physical router, and therefore inherits all existing mechanisms and tools
for configuration, operation, accounting, and maintenance. Any routing
protocol can be used to distribute VPN reachability information among VRs,
and no VPN-related modifications or extensions are needed to the routing
protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be
configured through layer-2 links or through IP- or MPLS-based tunnels.
Traffic from VRs belonging to different VPNs may be aggregated over a
"backbone VR" network, which greatly simplifies VPN provisioning. This
architecture accommodates various backbone deployment scenarios, both where
the VPN service provider owns the backbone, and where the VPN service
provider obtains backbone service from one or more other service providers.


    *    Working Group Summary

There are no WG conflicts regarding this draft.

    *    Protocol Quality

The draft is well done and existing implementations have been successfully
deployed.

[Note]: 'Subject: Re: Fwd: Re: L3VPN IPsec and VR documents
Date: Wed, 23 Mar 2005 14:57:46 -0500
From: Ross Callon
To: W. Mark Townsley , paul.knight@nortelnetworks.com
CC: narten@us.ibm.com, margaret@thingmagic.com, rick@rhwilder.net,        rbonica@juniper.net, rcallon@juniper.net

Paul Knight is currently updating the VR document, so I have
copied him on this email. Comments in-line (although mostly
my comments are simple agreements)....' added by Mark Townsley

[Note]: '2004-08-25: draft-ietf-l3vpn-as-vr-01.txt &
draft-ietf-l3vpn-vpn-vr-02.txt go together. Need to better understand
what wording/changes are needed to make clear that these documents are
not a protocol spec from which one can achieve interoperability.
' added by Thomas Narten

From: Ross Callon
To: l3vpn@ietf.org
Date: Wed, 12 May 2004 14:38:00 -0400
Subject: Progression of VR and IPsec Architectures

In reviewing the VR and IPsec architectures and associated applicability
statements, the IESG has pointed out that the documents do not actually
read as standards, in the sense that they don't specify what needs to be
implemented for interoperability.

This gives us two choices:

One option would be to publish the documents in approximately their
current form as informational RFCs.

The second option would be to update the documents to specify which
features need to be implemented to allow interoperability between different
implementations.

Note that the VR architecture already contains a few MUST and
SHOULD statements, particularly in section 2. However, it is not clear
whether the sum of the MUST's which are present are sufficient to
ensure interoperability. For example, there is no single discovery
scheme which MUST be implemented (would the MUST apply to
implementation of discovery via manual configuration??).

The CE-based VPN architecture based on IPsec contains a significant
number of MUST statements. However, these are primarily of the form
"for such a feature to work, the implementation MUST operate as follows",
rather than of the form "to be compliant, the implementation MUST
implement the following protocol or feature".

As a working group, we need to decide whether to publish the current
documents as informational, or to begin a process of determining which
features are MUST versus which are SHOULD or MAY, in order to ensure
interoperability, and thereby allow us to progress the documents on the
standards track.

Comments?

thanks, Ross