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)
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 <loa at pi.se>*
Sent by: l1vpn-bounces at lists.ietf.org
05/06/2005 10:26 ZE2
To: Hamid Ould-Brahim <hbrahim at nortel.com>
cc: rtg-dir at ietf.org, l1vpn at ietf.org
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
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
_______________________________________________
L1vpn mailing list
L1vpn at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn