Subject: the dubious P in L1VPN Was: (Re: [L1vpn] Proposed charter for L1VPN WG)

From: Loa Andersson <[email-masked]>
Date: Fri, 06 May 2005 12:24:47 +0200

Dimitri,

the reason I called it "dubious" is that the service seems be
more appropriate for Public operators (Virtual Public Networks),
than for "private" use.

Note: Hold comments along the line "There might be private entrprises
tht want to..." I realize that, what I'm talking about is where we
have an immediate need, and I mostly see bw-broker type of operators
on the L1VPN market.

But you are right the "dubious p" applies to GMPLS VPN also.

/Loa

[email-masked] wrote:
< snip >
> 
> note: you mention the "P" for private is bit dubious and so preferrable 
> to make use GMPLS VPN but is this name not also including the dubious "P" ?
> 

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

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 May 2005 12:33:30 +0200

Dimitri,

we've already had the comment that GMPLS can do more than L1, but
it is hardly so that L1VPN's can do more than L1.

So I guess that the second alternative would be more appropriate,
charter a limited (L1) GMPLS VPN work now and extend if we find
necessary. We are after all focused on the control plane protocols,
and the applicability of those seems to follows control plane
capabilities rather than limitations of networking layers.

/Loa

[email-masked] wrote:

> loa -
> 
> it seems we have three options
> 
> o) either large focus with GMPLS VPN (but then as sub-title for any 
> interface based VPN, i.e. GMPLS does cover a larger set than L1 interfaces)
> 
> o) or narrow focused with a title GMPLS VPN and then as sub-title for L1 
> interfaces only (but this restriction will simply appear arbitrarily 
> restrictive for the reason explained above)
> 
> o) or narrow focused with as title L1VPN (and sub-title GMPLS-based)
> 
> => it seems to me that the third option is more appropriate (even if it 
> comes out that some of the protocol outcomes are similar to the 
> below-mentionned "Generalized VPN" techniques)
> 
> *Loa Andersson <[email-masked]>*
> Sent by: [email-masked]
> 05/06/2005 10:26 ZE2
> 
> To: Hamid Ould-Brahim <[email-masked]>
> cc: [email-masked], [email-masked]
> bcc:
> Subject: Re: [L1vpn] Proposed charter for L1VPN WG
> 
> 
> Comments in line.
> 
> /Loa
> 
> Hamid Ould-Brahim wrote:
> 
>  > Alex,
>  >
> < snip >
> 
>  >
>  > 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).
> 
> hmmm, maybe we should discuss which wg are in thge wrong area :)
> 
> < snip>
> 
> 
>  >>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).
> 
> 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.
> 
>  > 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.
> 
> 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
> 
>  >
>  >
>  >> 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).
> 
> 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 >
> 
>  >
>  >> The WG will work on the following items:
>  >>
>  >>  1. Framework document defining the reference network model,
>  >>L1VPN service
>  >>     model, fundamental assumptions, and terminology.
>  >>
> 
> < snip>
> 
>  >
>  >>  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.
> 
> don't understand this node-to-node, the user inerface seems
> enough or do we intend to do interdomain hops on L1?
> 
>  >>
>  >>  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.
> 
> I would like to see the security issue mentioned explicitly.
> 
>  >>
>  >> 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.
> 
> 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."
> 
>  >>
>  >>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
>  >>
> 
> There are some comments, e.g. on the NNI that could affect the
> milestones once they are resoloved.
> 
> /Loa
> 
> --
> Loa Andersson
> 
> _______________________________________________
> L1vpn mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l1vpn
> 

-- 
Loa Andersson