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

[Dimitri.Papadimitriou@alcatel.be]

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

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

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

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

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

Tomonori TAKEDA wrote:

> Hi, Young,
>
> Thank you for your comments.
>
> Yes, I think the functional enhancement for UNI (overlay) and NNI (peer) 
> to support the Layer 1 VPN is a crucial point for the provider that 
> wants to provide connectivity services within limited group of customer 
> devices (enhancement from public services). I see that you are in line 
> with this important benefit of the L1 VPN. Comments are really appreciated.
>
> At 17:40 04/03/15 +0900, yhwkim@etri.re.kr wrote:
>
> > Hi,
> > I think the framework document has good guidelins for realizing the 
> > L1VPN in the GMPLS networks.
> > I'm not sure that the L1VPN service itself could be included in the 
> > CCAMP charter or not, but
> > I think functional enhancements for supporting the L1VPN in GMPLS 
> > should be covered in the CCAMP.
> > Thanks,
> > Young
> >
> >
> > > Hi,
> > > Although Layer One VPNs do not currently have a home in any IETF 
> > working group, we were
> > > the recipients of a liaison from ITU-T SG13 informing us about the 
> > work they are doing on
> > > this topic and pointing us at
> > > 
> > <http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt>http://www.ietf.org/internet-drafts/draft-takeda-l1vpn-framework-00.txt 
> >
> > > If anyone has comments on this work they can send them to this 
> > mailing list (until another
> > > home is found in the IETF) or to the authors direct.
> > > Thanks,
> > > Adrian
>
>
> -----
> 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