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

["Alanqar, Wesam I [NTK]" <wesam.alanqar@mail.sprint.com>]

Will SG15 be included in this effort mainly addressing ASON
architectural enhancements for L1 VPN? I believe that there should be
collaboration on the (protocols, generic control plane architectures,
service architectures) to support L1 VPN.

Thanks,
-Wesam

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Tomonori TAKEDA
Sent: Tuesday, April 06, 2004 11:34 AM
To: Dimitri.Papadimitriou@alcatel.be
Cc: yhwkim@etri.re.kr; ccamp@ops.ietf.org
Subject: Re: [RE] Layer One VPNs - sorry for the previous email

Hi, Dimitri

Thank you for your comments. And I am sorry for late response.

[snipped]

>>>- 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.")
>>
>>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.
>
>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

Understood. I think this requires further discussion. I would personally

think joint collaboration between IETF and SG13 would be a good
approach. 
Anyway, a simple step further at this point could be to enhance the 
current service level requirements according to all material produced in

SG13. We (authors of the L1VPN framework draft) are happy to provide
such 
text for the next version of the draft. Inputs and comments would be
also 
appreciated.


>>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.
>
>so you started with a signaling interface, and then try to build on top

>of it the necessary pieces
>
>>>- 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))
>>
>>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 ?
>
>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. Yes, as already said, delta requirements will be certainly
useful. 
Having a good understanding of the service and architecture needs is 
beneficial to drive later the discussion on protocols in a comprehensive

way (how protocols and mechanisms fit the service and the architecture).

[snipped]

Any comments are appreciated.

Best regards,


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