Subject: [RE] Layer One VPNs - sorry for the previous email

From: [email-masked]
Date: Mon, 15 Mar 2004 17:40:24 +0900

Hi, 
I think the framework document has good guidelins for realizing the L1VPN
in the GMPLS networks. 
I'm not sure that the L1VPN service itself could be included in the CCAMP
charter or not, but 
I think functional enhancements for supporting the L1VPN in GMPLS should be
covered in the CCAMP. 
Thanks,
Young

> Hi,
> Although Layer One VPNs do not currently have a home in any IETF working
group, we were 
> the recipients of a liaison from ITU-T SG13 informing us about the work
they are doing on 
> this topic and pointing us at 
> http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt
> If anyone has comments on this work they can send them to this mailing
list (until another 
> home is found in the IETF) or to the authors direct.
> Thanks, 
> Adrian

---

From: Tomonori TAKEDA <[email-masked]>
Date: Tue, 16 Mar 2004 01:00:40 +0900

Hi, Young,

Thank you for your comments.

Yes, I think the functional enhancement for UNI (overlay) and NNI (peer) to 
support the Layer 1 VPN is a crucial point for the provider that wants to 
provide connectivity services within limited group of customer devices 
(enhancement from public services). I see that you are in line with this 
important benefit of the L1 VPN. Comments are really appreciated.

At 17:40 04/03/15 +0900, [email-masked] wrote:

>I think functional enhancements for supporting the L1VPN in GMPLS should 
>be covered in the CCAMP.
>Thanks,
>Young
>
>
> > Hi,
> > Although Layer One VPNs do not currently have a home in any IETF 
> working group, we were
> > the recipients of a liaison from ITU-T SG13 informing us about the 
> work they are doing on
> <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
>
> > If anyone has comments on this work they can send them to this 
> mailing list (until another

-----
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434

---

From: [email-masked]
Date: Mon, 15 Mar 2004 18:39:35 +0100

hi tomonori, young, all,

the proposed framework document (part of this discussion)
deliversa good starting point in terms of functionality

some more specific comment on this document:

- it mentions an issue concerning the "shared control link" it
may be advisable to detail more accurately the expectation in
terms of functionality and then assess whether a shared control
link can be used in this context, the addition to which you're
referring seems to imply a mux/de-mux mechanism - it would be
of great interest to see how this compares with Section 4 of
the GVPN id

- section 4.1, performance is included as service do you mean
this as a classification of the quality of the delivered service
or do you mean that it is a service to allow customer to monitor
performance of the delivered service ?

- there is the issue of the "PE-PE virtual links" and in case of
"Per VPN Peer model" more details should be provided in order to
assess whether existing GMPLS mechanisms are sufficient (from
that perspective details about the following sentence might be
of interest because it seems you took this as initial working
assumption "there is currently no leakage of routing information
across the PE to CE boundary.")

- i would suggest to conclude the document with the expected
delta requirement from gmpls perspective (this would help in
assessing what's expected in terms of protocol for the next
step(s))

- an edit concerning the section on terminology it would be
of great help for this community to point the differences (if
any) from the existing [TERM] document

thanks,
- dimitri.

Tomonori TAKEDA wrote:

> Yes, I think the functional enhancement for UNI (overlay) and NNI (peer) 
> to support the Layer 1 VPN is a crucial point for the provider that 
> wants to provide connectivity services within limited group of customer 
> devices (enhancement from public services). I see that you are in line 
> with this important benefit of the L1 VPN. Comments are really appreciated.
> 
>> I think the framework document has good guidelins for realizing the 
>> L1VPN in the GMPLS networks.
>> I'm not sure that the L1VPN service itself could be included in the 
>> CCAMP charter or not, but
>> I think functional enhancements for supporting the L1VPN in GMPLS 
>> should be covered in the CCAMP.
>> Thanks,
>> Young
>>
>>
>> > Hi,

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "zafar ali" <[email-masked]>
Date: Mon, 15 Mar 2004 17:09:59 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, March 15, 2004 3:40 AM
To: [email-masked]
Subject: [RE] Layer One VPNs - sorry for the previous email

Hi, 

Yes, I agree the framework document is a good start. 

There were also talks about creating a new WG for it. Considering
current work load at CCAMP, this may be a sensible option. I hope we are
able to clarify on home for this work soon. 

Thanks
 
Regards... Zafar

Thanks, 
Young 

working group, we were 
work they are doing on 
list (until another

---

From: Tomonori TAKEDA <[email-masked]>
Date: Thu, 18 Mar 2004 00:10:31 +0900

Hi, Dimitri

Thank you for your comments. Please see my comments in line.

>of great interest to see how this compares with Section 4 of

Okay, let me try to answer your comments.

For control link between the CE and the PE, I would say there are three 
categories.

1) Physically disjoint control link
2) IP-level disjoint control link (e.g., GRE tunnel)
3) IP-level shared control link

Shared control link generally refers to category 3).

 From here, I am describing more than what is described in the ID.

Category 3) is typically the case that the same CE device belongs to 
multiple VPNs (or the CE device contains multiple VPN instances), as 
described in section 6.1 of the ID. In this case, to distinguish messages 
exchanged over the control channel, some mechanisms are needed, and 
addition of VPN ID seems one way to do.

In GVPN ID, my understanding is that logical CE-PE links (or association) 
belong to each VPN. L1VPN framework ID is in line with this (as described 
in section 6.1), but this ID goes beyond and tackles the case for shared 
control channel.

>performance of the delivered service ?

I mean the former.

To make sure, I mean that performance is one of the items that specify the 
service. (or the service defines the level of performance.)

>across the PE to CE boundary.")

Agree. Providing more details about service requirements may be helpful ? 
Functional requirements are also important, but before going that in 
details, more clear service level requirements may be useful.

Concerning the initial working assumption you mentioned, we started from 
the most acknowledged model for the service interface, that is the UNI. 
That is why we put above text.

>assessing what's expected in terms of protocol for the next

Okay, if CCAMP is going to work on the L1 VPN, I agree delta requirement 
would be an important step.

Do you have anything in your mind ?

>any) from the existing [TERM] document

Thanks. I would take that into the next version.

Best regards,

-----
Tomonori TAKEDA

---

From: Tomonori TAKEDA <[email-masked]>
Date: Thu, 18 Mar 2004 00:40:57 +0900

Hi, Zafar,

Technically, GMPLS protocols seem to have many common pieces for the L1VPN 
as suggested by some of the voices during the CCAMP meeting.

Any suggestion ?

Best regards,

At 17:09 04/03/15 -0500, zafar ali wrote:
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of [email-masked]
>There were also talks about creating a new WG for it. Considering current 
>work load at CCAMP, this may be a sensible option. I hope we are able to 
>clarify on home for this work soon.
>Thanks
>
>Regards... Zafar
>
>
>Thanks,
>Young
>
> > Hi,

-----
Tomonori TAKEDA

---

From: "zafar ali" <[email-masked]>
Date: Wed, 17 Mar 2004 11:24:38 -0500

Hi Tomonori, 

We still need to find a way to allow more time for face-to-face
discussions in CCAMP WG meeting. My point was coming from the fact that
we have been really pressed for time during CCAMP meetings, to the
extent that we had to skip through various important discussions. Which
IMO is not the best use of a face-to-face opportunity. 

Thanks

Regards... Zafar

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Tomonori TAKEDA
>Sent: Wednesday, March 17, 2004 10:41 AM
>To: zafar ali; [email-masked]; [email-masked]
>Subject: RE: [RE] Layer One VPNs - sorry for the previous email
>
>
>Hi, Zafar,
>
>>CCAMP
><http://www.ietf.org/internet-drafts/draft->takeda-l1vpn-framework-00.t
>> 
>xt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00
>> .txt
>>
>> > home is found in the IETF) or to the authors direct. Thanks,
>> > Adrian
>
>-----
>Tomonori TAKEDA

---

From: [email-masked]
Date: Wed, 17 Mar 2004 21:10:56 +0100

hi tomonori,

Tomonori TAKEDA wrote:

> described in section 6.1 of the ID. In this case, to distinguish 
> messages exchanged over the control channel, some mechanisms are needed, 
> and addition of VPN ID seems one way to do.
> 
> In GVPN ID, my understanding is that logical CE-PE links (or 
> association) belong to each VPN. L1VPN framework ID is in line with this 
> (as described in section 6.1), but this ID goes beyond and tackles the 
> case for shared control channel.

this was over time also my understanding of your intention and we may 
point this as something to be further discussed from a solution 
perspective in case of acceptance of this work item w/i ietf scope

> To make sure, I mean that performance is one of the items that specify 
> the service. (or the service defines the level of performance.)

ok, this clarifies

> Agree. Providing more details about service requirements may be helpful 
> ? Functional requirements are also important, but before going that in 

do you plan to deliver those as part of the user community or do you 
expect this input to come from SG13 - or both - ? just to know about the 
timeframe we may expect here since there are very interesting issues 
you're introducing with the above approaches

> That is why we put above text.

so you started with a signaling interface, and then try to build on top 
of it the necessary pieces

> Do you have anything in your mind ?

try to collect all the sentences that are part of the present document 
that either implicitly or explicitly determine a feature to be covered
list them in terms of signaling and routing, i think we would gain a lot 
of precious time in having such conclusion in case decision to work on 
solution is accepted

thanks,
- dimitri.