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

From: Marshall Eubanks <[email-masked]>
Date: Fri, 14 May 2010 02:14:13 -0400

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

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 14 May 2010 15:42:07 +0900

This internet draft's purpose is RFC5824 supports.
RFC5824 is L3vpn wg documents.
So I think this draft should be adopted in l3VPN wg.
 
Regards,
-Shishio

(2010/05/14 15:14), Marshall Eubanks wrote:
> 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.
> 
> in draft-ietf-l3vpn-e2e-rsvp-te-reqt, I think that it would be entirely 
> appropriate to
> 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
> 
>

---

From: <[email-masked]>
Date: Mon, 24 May 2010 22:19:13 +0100

<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