Loa,
good to see there is a clear intention to structure our relationship and
message towards ITU-T wrt to our GMPLS work and views
if i correctly interpreet you statement "Use the established IETF channels
to coordinate with ITU-T as necessary." it means there will be a single
channel (contrary to the multiple per WG channel that exists today) and you
suggest making use of it to communicate with ITU-T SG13 on L1VPN
as long as this allows interacting with them where necessary i do not think
this would problematic - do you know when such person is going to be
appointed ?
thanks,
- dimitri.
---
Igor and Dimitri,
I'm not that happy about this - did see it go into the version
that was sent to l1vpn-list, and think it should not be there.
At least not until we have a clear understanding of what the
scope of this working groups coordination with ITY-T needs to
be.
The issues we see to today is that we have several contacts points
with ITU-T and the messages we send over these contact points are
sometimes conflicting and they are using it to say that we don't
have control of what we are doing.
I think that with regards to the ITU-T relationship it would be
much better to appoint one person (a liaison) or a working group
or a set of working groups responsible for coordinating the
(g)mpls part of the ITU-T relationship from the IETF. And then
write something like:
"Use the established IETF channels to coordinate with ITU-T as
necessary."
Actually this could go into the charter of all working groups that
needs to part of this coordination.
/Loa
Igor Bryskin wrote:
Good idea.
Igor
*/Dimitri.Papadimitriou at alcatel.be/* wrote:
igor, all - now that i am thinking of it there is probably a need to
add a sentence like "The WG will also liaise with related ITU-T SGs"
after "... and other WGs where necessary."
*Igor Bryskin <i_bryskin at yahoo.com>*
Sent by: rtg-dir-bounces at ietf.org
05/04/2005 07:18 MST
To: Alex Zinin <zinin at psg.com>, Adrian Farrel <adrian at olddog.co.uk>,
Dimitri PAPADIMITRIOU/BE/ALCATEL at ALCATEL, rtg-dir at ietf.org, Kireeti
Kompella <kireeti at juniper.net>, takeda.tomonori at lab.ntt.co.jp
cc:
bcc:
Subject: Re: Draft L1VPN Charter
Alex, All
2. Enhanced mode: the CE-PE interface provides the signaling
capabilities
as in the Basic mode, plus permits utilization of the provider's
control
plane for distribution of user's routing information (e.g. similar
to the
MPLS/BGP model).
I'd like to replace this with:
2. Enhanced mode: the CE-PE interface provides the signaling
capabilities
as in the Basic mode, plus permits utilization of the provider's
control
plane for distribution of user's arbitrary control plane information
between the VPN sites including but not limited to routing
information.
Provider network IHMO should make no assumptions on what protocols
are running within VPNs. Generally speaking, a L1VPN user is not
necessarily GMPLS controlled network. Furthermore, even in case it
does use GMPLS it needs L1VPN CE-CE connections to provide (TE)
links within VPNs. Specifically, the User should be capable to run
LMP for such links, it also should be possible to establish
signaling (RSVP) adjacencies between their ends, etc. The bottom
line is that distribution of routing information between CEs IHMO is
not sufficient. I believe this is consistent with the requirements
stated in ITU-T SG13 L1VPN documents
Igor
*/Alex Zinin <zinin at psg.com>/* wrote:
Folks-
Before we bring it to the l1vpn mailing list, I'd like to run this
draft
by you guys for comments.
--
Alex
Layer 1 Virtual Private Networks (l1vpn)
Last Modified: 2005-01-25
Chair(s):
TBD
TBD
Routing Area Director(s):
Bill Fenner
Alex Zinin
Routing Area Advisor:
Alex Zinin
Technical Advisor(s):
Mailing Lists:
General Discussion: l1vpn at ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html
Description of Working Group:
L1VPN Working Group's task is to specify mechanisms necessary for
providing a VPN service over a GMPLS transport network.
The following two service models will be addressed:
1. Basic mode: the CE-PE interface's functional repertoire is limited
to
path setup signalling only. The GMPLS network is not involved in
distribution of user's routing information.
2. Enhanced mode: the CE-PE interface provides the signaling
capabilities
as in the Basic mode, plus permits utilization of the provider's
control
plane for distribution of user's routing information (e.g. similar
to the
MPLS/BGP model).
The WG will work on the following items:
1. Specification of the L1VPN user-to-network interface (UNI) basic
mode,
including both CE and PE functionality.
2. Specification of the L1VPN node-to-node interface (NNI) basic
mode.
!
3. MIB modules and/or extensions required for UNI and NNI basic mode.
4. Specification of L1VPN UNI enhanced mode.
5. Specification of L1VPN NNI enhanced mode.
6. MIB modules and/or extensions required for UNI and NNI enhanced
mode.
Protocol extensions required for L1VPN will be done in cooperation
with
CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary.
Milestones:
Sep 05 Submit first Internet Drafts of UNI and NNI basic mode
specifications
Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI
basic
mode
Jun 06 Submit UNI and NNI basic mode specifications to IESG for
publication as Proposed Standard
Jun 06 Submit first Internet Draf! ts of UNI and NNI enhanced mode
specifications
Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for
publication as Proposed Standard
Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for
publication as Proposed Standard
Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for
publication as Proposed Standard
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com <http://mail.yahoo.com/>
------------------------------------------------------------------------
Discover Yahoo!
Find restaurants, movies, travel & more fun for the weekend. Check it
out!
<http://us.rd.yahoo.com/evt=32658/*http://discover.yahoo.com/weekend.html>
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson at acreo.se
loa at pi.se