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

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 5 May 2005 16:15:16 -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: Loa Andersson <[email-masked]>
Date: Fri, 06 May 2005 10:26:32 +0200

Comments in line.

/Loa

> Alex,
< snip >

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

hmmm, maybe we should discuss which wg are in thge wrong area :)

< snip>

> problem set (the set of interfaces where GMPLS applies).

Guess that Hamids comment boils down to that GMPLS can
do more than L1. Strictly speaking ASON (which really is a
degenrate version of GMPLS) could also (in some restricted
way) be used for L1VPNs.

> necessarily L1-based. Something along the line of 

I don't think that this wg is the place to solve all genral
VPN problems, would rather urge to focus this really narrow
e.g. the two service models below

>>     plane (e.g. network-layer reachability information as in 

Question: would be correct to say that the intention is to
describe an "overlay model" in the in the basic mode and an
"peer model" in the enhanced. If so it should be made clear
that when we talk about "user's routing information" it is the
routing information for the "layer" native to the GMPLS VPN.

given that description it is probably time to ask if this a
Layer 1 VPN working group or an GMPLS VPN working group.
The P for Private in VPN is a bit dubious at least in the early
uses of this technology, might be better to name it
GMPLS VPN wg.

< snip >

>>     model, fundamental assumptions, and terminology.

< snip>

>>  3. Specification of the L1VPN node-to-node interface (NNI) 

don't understand this node-to-node, the user inerface seems
enough or do we intend to do interdomain hops on L1?

>>  7. MIB modules and/or extensions required for UNI and NNI 

I would like to see the security issue mentioned explicitly.

>>where necessary. Where necessary,  the WG will also cooperate 

I guess that the thought here is that ccamp acts on behalf of
the mpls wg, but would be happier if the mpls wg were mentioned
ecxplicitly, also since we mention the BGP/MPLS VPNs some
coordintion with L3VPN might turn out necessary.
I also think that the paragraph is to weak, it should say.

"Protocol extensions required for L1VPN need to be done with
by the working roup that owns the base protocol, e.g. CCAMP,
MPLS, OSPF, IS-IS, IDR, and other WGs where necessary. Where
necessary, the WG will also cooperate with ITU-T."

>>IESG for publication as Proposed Standard

There are some comments, e.g. on the NNI that could affect the
milestones once they are resoloved.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]