Subject: RE: [Fwd: I-D ACTION:draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt]

From: "Yuji KAMITE" <[email-masked]>
Date: Mon, 03 Mar 2008 22:13:28 +0900

Hi,

I think there would be wide interests among SPs in providing 
end-customers with new enhanced service in terms of
QoS admission control.

This is functional requirement for BGP/MPLS IP-VPN improvement,
So I believe this item is worth considering in this working group.

-Yuji

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Kenji Kumaki
> Sent: Thursday, February 21, 2008 10:31 AM
> To: [email-masked]
> Subject: [Fwd: I-D ACTION:draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt]
> 
> Hi all,
> 
> We submitted the following I-D.
> Actually, we focus on requirements of "RSVP over L3VPN" and 
> "RSVP-TE over L3VPN".
> 
> We appreciate WG comments and feedback.
> 
> Thanks,
> Kenji
> 
>

---

From: "Yuichi Ikejiri" <[email-masked]>
Date: Wed, 05 Mar 2008 18:42:50 +0900

Hi,

I support this draft that discribes requirements of both RSVP and
RSVP-TE over L3VPN as a service provider.

Then, this is just editorial comments, but some words seem 
to be missing in the last sentence of the first paragraph of 
section 3. Problem Statement. (ex. Please note that there..)

Thanks,
Yuichi

On Thu, 21 Feb 2008 10:31:18 +0900
"Kenji Kumaki" <[email-masked]> wrote:

> Actually, we focus on requirements of "RSVP over L3VPN" and "RSVP-TE
> over L3VPN".
>

---

From: S.Matsushima <[email-masked]>
Date: Wed, 5 Mar 2008 22:07:27 +0900

Hi,

I've received a lot of demands for supporting TE-LSP
through BGP/MPLS-VPN network from our customers who
are using Carriers' carrier service.
I support this draft.

--satoru

2008/2/21, Kenji Kumaki <[email-masked]>:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>        Title           : Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS IP-VPN
>        Author(s)       : K. Kumaki
>        Filename        : draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt
>        Pages           : 21
>        Date            : 2008-2-20
>
> Some service providers want to build a service which guarantees QoS
>   or bandwidth from a local CE to a remote CE through the network.
>   Today, customers expect to run triple play services through BGP/MPLS
>   IP-VPNs. As a result, their requirements for end-to-end QoS of
>   applications are increasing. Depending on the application (e.g.,
>   voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end
>
>   native RSVP path and/or an end-to-end MPLS TE LSP are required, and
>   they need to meet some constraints.
>   This document describes service provider requirements for supporting
>   customer RSVP and RSVP-TE over a BGP/MPLS VPN
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/i-d-announce
>
>

---

From: Totti Murakami <[email-masked]>
Date: Wed, 05 Mar 2008 23:56:55 +0900

Hi,

I support this draft because it would be benefical in terms of giving
the customers the new choice.

Regards,
Totti
> ------------------------------------------------------------------------
>
> Subject:
> I-D ACTION:draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt
> From:
> [email-masked]
> Date:
> Wed, 20 Feb 2008 13:15:01 -0800 (PST)
> To:
> [email-masked]
>
> To:
> [email-masked]
> CC:
>
>
> ------------------------------------------------------------------------
>

---

From: Joel Stafford <[email-masked]>
Date: Wed, 05 Mar 2008 10:09:40 -0500

I agree. I think there's promise with this service.

******************
Joel Stafford
vBNS+ Engineering
Advanced Internet Technology
v-806.3786
******************

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Totti Murakami
Sent: Wednesday, March 05, 2008 9:57 AM
To: Kenji Kumaki
Cc: [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt]

Hi,

Regards,
Totti
> We appreciate WG comments and feedback.
http://www.ietf.org/internet-drafts/draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.
txt

---

From: Tomoki Murai <[email-masked]>
Date: Fri, 07 Mar 2008 22:31:25 +0900 (JST)

Hi,

I support this draft.
I think this solution can provide a very flexible network to customers.

In Section 6.2, is it correct in understanding that graceful OSPF or BGP
restart is necessary for P-TE LSPs? 

Regards,
Tomoki

From: Kenji Kumaki <[email-masked]>
Subject: [Fwd: I-D ACTION:draft-kumaki-l3vpn-e2e-rsvp-te-reqts-06.txt]
Date: Thu, 21 Feb 2008 10:31:18 +0900

---

From: Kenji Kumaki <[email-masked]>
Date: Sat, 08 Mar 2008 11:16:52 +0900

Hi Tomoki,

Thank you for your support and comments.

 > restart is necessary for P-TE LSPs?

Yes. In this case, graceful restart about OSPF and BGP is required for 
P-TE LSPs. In that sense, graceful restart about RSVP is required for 
C-TE LSPs.
So, I'll reflect your comments in the next revision.

Thanks,
Kenji

---

From: Kenji Kumaki <[email-masked]>
Date: Sat, 08 Mar 2008 11:16:34 +0900

Hi Yuichi,

 > section 3. Problem Statement. (ex. Please note that there..)

That's right.
I'll reflect your comments in the next revision.

Thanks,
Kenji

---

From: Ken Nagami <[email-masked]>
Date: Sat, 08 Mar 2008 15:08:24 +0900

> We appreciate WG comments and feedback.

I think this requirements are important to provide end-to-end
MPLS TE.

Regards,

Ken Nagami