Subject: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-l3vpn-00.txt

From: [email-masked]
Date: Thu, 3 Jul 2008 10:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Support for RSVP in Layer 3 VPNs
	Author(s)       : B. Davie, et al.
	Filename        : draft-ietf-tsvwg-rsvp-l3vpn-00.txt
	Pages           : 32
	Date            : 2008-07-03

RFC 4364 and RFC 4659 define an approach to building provider-
provisioned Layer 3 VPNs for IPv4 and IPv6.  It may be desirable to
use RSVP to perform admission control on the links between CE and PE
routers.  This document specifies procedures by which RSVP messages
travelling from CE to CE across an L3VPN may be appropriately handled
by PE routers so that admission control can be performed on PE-CE
links.  Optionally, admission control across the provider's backbone
may also be supported.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Change history

[_Note to RFC Editor: This section to be removed before publication_]

Changes in this version (draft-ietf-tsvwg-rsvp-l3vpn-00) relative to
the last (draft-davie-tsvwg-rsvp-l3vpn-02):

o  Outlined signalling security issues and added discussion of

methods to control redistribution of routes among providers and

from providers to customers

o  Clarification regarding support for RSVP-TE across L3VPN

o  Minor corrections

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-l3vpn-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 18 Jul 2008 10:29:28 -0700

Bruce,

> This draft has been presented to L3VPN a couple of times, but is now  
> getting progressed in TSVWG as discussed at the last IETF. If you  
> want to comment on it, please copy the tsvwg list.

>From Section 5.2.2 of the draft:

   In the case where the address
   is specially created for control protocols, the BGP advertisement for
   this address SHOULD be marked such that it is not redistributed
   outside the MPLS VPN.  Two possible methods to achieve this goal are:

   o  Tag the advertisement of such routes with a route target that is
      not imported into any customer VRFs.  This requires the creation
      of a special "control protocols" VPN which is used only for these
      addresses.

   o  Tag the advertisement with a specially defined extended-community
      attribute, the meaning of which is that this route is not to be
      redistributed to customers.  Definition of this attribute is
      beyond the scope of this document.

Do we really need two methods ? Why one is not enough ?

Yakov.

---

From: Bruce Davie <[email-masked]>
Date: Tue, 22 Jul 2008 08:34:20 -0400

Yakov,

> Do we really need two methods ? Why one is not enough ?

The two methods each have their pluses and minuses.  Furthermore,  
this topic of controlling route distribution outside the VPN is of  
broader impact than just RSVP - it is really a general L3VPN issue.  
So I believe that if there is a strong need at some point to restrict  
the options to only one, the right place to narrow down the choices  
would be in L3VPN.

Because the first option listed does not require any new protocol  
machinery, it also provides a solution that can be deployed today,  
but it would not present an interoperability problem if the L3VPN  
group later decided to favor the community attribute approach.

Bruce

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 22 Jul 2008 09:18:22 -0700

Bruce,

> broader impact than just RSVP - it is really a general L3VPN issue.  

Agreed.

> the options to only one, the right place to narrow down the choices  

Unless someone could present compelling arguments why both of the
choices are needed, we should settle on one (or at least make one
mandatory and another optional). I agree with you that the right
place to narrow down the choices would be in L3VPN. I also think
that we should narrow down the choices sooner, rather than later.
With this in mind, I'd like to ask folks on L3VPN to comment on
these choices.

Yakov.

---

From: Bruce Davie <[email-masked]>
Date: Thu, 24 Jul 2008 13:07:10 -0400

Yakov,

> Bruce,
[...]
> With this in mind, I'd like to ask folks on L3VPN to comment on

First off, let's remember that all of the text we are talking about  
describes optional capabilities. To quote the draft just above the  
text you quoted earlier:

    This VPN-IPv4 address MAY be created specially for this
    task, or MAY be any previously-advertised address representing any
    VRF (e.g. local PE-CE link address).   In the case where the address
    is specially created for control protocols, the BGP advertisement  
for
    this address SHOULD be marked such that it is not redistributed
    outside the MPLS VPN.

The options we are discussing only apply if the address is  
specifically created for control protocols. So whatever we decide,  
interoperability could always be obtained by just using previously  
advertised addresses (such as local PE-CE addresses) for this purpose.

Now assuming that we want to have at least one solution that does not  
require the use of previously advertised addresses,
the first method (use a special "control protocols" VPN) can be  
achieved without any additional standardization. So in order to  
provide a workable solution in the near term, this approach is the  
only option I am aware of. I'd be hesitant to remove it at this point.

The second method (define a new community attribute) can, I think, be  
considered a viable longer term solution. I don't want to define the  
new community in this draft - it's a more broadly applicable  
attribute, as I think we agree, and should be done on its own. I also  
don't want to hold up this RSVP over L3VPN draft waiting for that one  
to be written, but maybe we can get that moving along fairly quickly.  
If so, I'd be amenable to removing the "control protocol VPN" option  
(barring any strong direction to do otherwise from the WGs).

Bruce