Subject: Re: [L1vpn] Proposed charter for L1VPN WG

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 5 May 2005 17:18:46 -0400

Alex,

Quick comments on the charter...may have other
comments later on.

> 
> Layer 1 Virtual Private Networks (l1vpn)
> 
> Last Modified: 2005-05-05
> Chair(s):
>  TBD
>  TBD
> 
> Routing Area Director(s):
>  Bill Fenner <[email-masked]>
>  Alex Zinin <[email-masked]>
> 

Just out of curiosity shouldn't this WG be as well within 
the internet area like l2 and l3vpns?  Some functions 
are really similar to the ones developed in l2 and l3 vpns. 

Routing area is still fine (since ccamp is within this area anyway).

> Routing Area Advisor:
>  Alex Zinin <[email-masked]>
> 
> Technical Advisor(s):
> 
> Mailing Lists:
>  General Discussion: [email-masked]
>  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 above should be more specific that is about L1VPN using GMPLS
and across a GMPLS enabled network. A "VPN service over GMPLS" includes
all VPN cases that GMPLS interfaces support while here
we are looking specifically at l1vpn using gmpls. 

I believe that if we solve the GMPLS VPN for L1VPN
then in fact we are actually solving a much bigger VPN
problem set (the set of interfaces where GMPLS applies).
And maybe it's much better to solve the GMPLS VPNs That
include GMPLS L1 based interfaces then starting with
L1VPN as a service since most of the mechanisms are not
necessarily L1-based. Something along the line of 
Generalized VPNs.

>  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 some information from the 
> user's control
>      plane (e.g. network-layer reachability information as in 
> the MPLS/BGP model).
> 

Is this referring to auto-discovery of L1VPN endpoints/nodes
or to routing peering between CE and PE and have PE distribute 
CE relate routing? It looks like the text is about the latter
not the former.

>  The WG will work on the following items:
> 
>   1. Framework document defining the reference network model, 
> L1VPN service
>      model, fundamental assumptions, and terminology.
> 

Should we as well add requirement document? I think we should
(since this is a service after all).

>   2. Specification of the L1VPN user-to-network interface 
> (UNI) basic mode,
>      including both CE and PE functionality.
> 
>   3. Specification of the L1VPN node-to-node interface (NNI) 
> basic mode.
> 

Not sure what we mean here by L1VPN node-to-node interface.

Hamid.

>   4. MIB modules and/or extensions required for UNI and NNI 
> basic mode.
> 
>   5. Specification of L1VPN UNI enhanced mode.
> 
>   6. Specification of L1VPN NNI enhanced mode.
> 
>   7. 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. Where necessary,  the WG will also cooperate 
> with ITU-T.
> 
> Milestones:
> 
>   Sep 05 Submit first Internet Draft of L1VPN framework
> 
>   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
> 
>   Apr 06 Submit UNI and NNI basic mode specifications to IESG 
> for publication as Proposed Standard
> 
>   Jun 06 Submit first Internet Drafts 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
> 
>   Dec 06 Submit L1VPN framework to IESG for publication as 
> Informational RFC
> 
>   Aug 07 Submit MIB modules for UNI and NNI enhanced mode to 
> IESG for publication as Proposed Standard
> 
> 
> 
> 
> 
> _______________________________________________
> L1vpn mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/l1vpn
> 
>

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 15:39:44 -0700

Hamid,

> Routing area is still fine (since ccamp is within this area anyway).

In retrospect, my personal opinion is that putting L2VPN and L3VPN in INT
was a mistake. Most of the complexity in the work they are doing is
RTG-related, and most of the people who go there are also RTG-involved.
I've learned it the hard way...

L1VPN builds on CCAMP work, so it makes sense to put it in RTG.

> necessarily L1-based. Something along the line of 

How do you think the text should be changed?

> CE relate routing? It looks like the text is about the latter

More the latter. I didn't think we should spell the former out.

> (since this is a service after all).

Is there a disagreement in the community on what L1VPNs should do?
If so, can it be resolved on the mailing list?

In other words, do we really need a requirements document? (see my reply to
Adrian for more on this.)

> Not sure what we mean here by L1VPN node-to-node interface.

see my reply to Adrian.

thanks.

Alex