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

[Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>]

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.


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

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

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.

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

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

Best regards,

> thanks,
> - dimitri.

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