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

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 26 Mar 2004 10:03:13 -0600

Hi Tomonori, Adrian,

I noted the SG13 liaison has a response date of September 2004 (the l1vpn questionnaire responses are due June).  Will we wait until the August IETF meeting to respond? (hopefully there will have been a decision on the l1vpn work allocation)

I support Dimitri's comments below, it would be useful for the next version of the draft to compare ITU terminology and [TERM], and also provide an initial proposal of comparison/delta requirements to aid in ccamp's understanding of the work and for responding to SG13 e.g. comparison to ccamp's gmpls-overlay draft which includes GMPLS VPN support (L1 included) and the GVPN services draft which includes VPN service models and GMPLS toolkit to support.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of [email-masked]
Sent: Wednesday, March 17, 2004 3:11 PM
To: Tomonori TAKEDA
Cc: [email-masked]; [email-masked]
Subject: Re: [RE] Layer One VPNs - sorry for the previous email

hi tomonori,

Tomonori TAKEDA wrote:

> Hi, Dimitri
> 
> Thank you for your comments. Please see my comments in line.
> 
> At 18:39 04/03/15 +0100, [email-masked] wrote:
> 
>> 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
> 
> 
> 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.

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

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

ok, this clarifies

>> - 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

> 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

>> - 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. I would take that into the next version.

thanks,
- dimitri.

> Best regards,
> 
>> thanks,
>> - dimitri.
> 
> 
> -----
> Tomonori TAKEDA
> NTT Network Service Systems Lab.
> Phone: +81-422-59-7434
> 

-- 
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