[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RE] Layer One VPNs - sorry for the previous email
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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Wednesday, March 17, 2004 3:11 PM
To: Tomonori TAKEDA
Cc: yhwkim@etri.re.kr; ccamp@ops.ietf.org
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, Dimitri.Papadimitriou@alcatel.be 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 : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone : +32 3 240-8491