- 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
----- Tomonori TAKEDA NTT Network Service Systems Lab. Phone: +81-422-59-7434