[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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