Re: Should L3VPN adopt draft-kumaki-murai-ccamp-rsvp-te-l3vpn ?

<benjamin.niven-jenkins@bt.com> Mon, 24 May 2010 21:19 UTC

From: benjamin.niven-jenkins@bt.com
To: tme@americafree.tv, l3vpn@ietf.org
Date: Mon, 24 May 2010 22:19:13 +0100
Subject: Re: Should L3VPN adopt draft-kumaki-murai-ccamp-rsvp-te-l3vpn ?
Thread-Topic: Should L3VPN adopt draft-kumaki-murai-ccamp-rsvp-te-l3vpn ?
Thread-Index: AcrzLLkk8Ru1J6V/R9aUucNC8Cr71AIWgi2l
Message-ID: <C820ABE1.17724%benjamin.niven-jenkins@bt.com>
In-Reply-To: <BE86C887-F3DF-4E22-A62C-CB78AC463A72@americafree.tv>
Accept-Language: en-US, en-GB
Content-Language: en-US
user-agent: Microsoft-Entourage/13.3.0.091002
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: list

<As an individual>

The document aims to provide a mechanism to implement at least some of the
requirements in RFC5824.

One significant observation that I have is that the document allows a CE-PE
protocol (RSVP) to effectively create session state within the core (PE-PE)
network supporting the VPN.

What is impact on this to P routers? Do they need to understand the new
session object (my knowledge of RSVP-TE is too rusty)?

I think the document needs to discuss the applicability of the proposed
mechanisms in the context that they directly impact VPN core session state?
Should protection mechanisms be included to prevent excess session state
being created in the core by a single VPN customer?

Is there any way to better balance the creation of core session state than
the 1:1 CE-PE request:core state in the current draft, e.g. Multicast VPNs
create session state in the VPN core but the WG was careful to discuss and
specify mechanisms (the various flavours of xI-PMSI) to allow an operate to
realise a trade off between bandwidth/efficiency and core session state.

Ben

On 14/05/2010 07:14, "Marshall Eubanks" <tme@americafree.tv> wrote:

> Hello;
> 
> This document
> 
> https://datatracker.ietf.org/doc/draft-kumaki-murai-ccamp-rsvp-te-l3vpn/
> 
> was presented and discussed in Anaheim - see
> 
> http://www.ietf.org/proceedings/10mar/slides/l3vpn-2.ppt
> 
> The authors requested that the draft be adopted, but there was little
> support to do that at the meeting and there were suggestions that it
> should be in another WG.
> 
> After a discussion between the L3VPN, CCAMP and MPLS WG Chairs, a
> consensus developed among us that L3VPN was the most appropriate home
> for this document if it is to be adopted by any WG at all, so I think
> it falls to us to decide whether it is going to progress or not.
> 
> The requirements for supporting BGP/MPLS RSVP-TE based IP-VPNs are
> documented in
> draft-ietf-l3vpn-e2e-rsvp-te-reqts-05.txt
> 
> If the WG feels that draft-kumaki-murai-ccamp-rsvp-te-l3vpn is an
> adequate solution to the requirements
> in draft-ietf-l3vpn-e2e-rsvp-te-reqt, I think that it would be
> entirely appropriate to
> adopt this document in L3VPN. If the WG feels that this is not an
> acceptable
> solution to  draft-ietf-l3vpn-e2e-rsvp-te-reqts, I think that it
> would be useful to have the reasons why brought to the surface.
> 
> So, I would like to request that WG members read this draft and
> provide comments to the list as to whether or not this document should
> be adopted by L3VPN, and also what they see as good points or problems
> with the solution described in this draft.
> 
> A failure by the WG to express interest in the document will lead to
> the draft not being adopted.
> 
> Regards
> Marshall Eubanks
>

Should L3VPN adopt draft-kumaki-murai-ccamp-rsvp-… Marshall Eubanks
Re: Should L3VPN adopt draft-kumaki-murai-ccamp-r… Shishio Tsuchiya
Re: Should L3VPN adopt draft-kumaki-murai-ccamp-r… benjamin.niven-jenkins