Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches
draft-ietf-l3vpn-as-vr-02

Summary: Needs a YES.

Lars Eggert Abstain

Alvaro Retana No Record

Andrew Alston No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Martin Duke No Record

Murray Kucherawy No Record

Paul Wouters No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Magnus Westerlund; former steering group member) 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.

(Russ Housley; former steering group member) 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.

(Mark Townsley; former steering group member) Yes

(Brian Carpenter; former steering group member) No Objection

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?

(Dan Romascanu; former steering group member) No Objection

(David Kessens; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

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

(Ted Hardie; former steering group member) Abstain

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

(Ross Callon; former steering group member) Recuse

(Cullen Jennings; former steering group member) (was No Objection) No Record