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

From: Tomonori TAKEDA <[email-masked]>
Date: Fri, 06 May 2005 21:00:38 +0900

Hamid,

<snipped>

 >> >>  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).
 >>
 >> Is there a disagreement in the community on what L1VPNs should do?
 >> If so, can it be resolved on the mailing list?
 >>
 >
 >I think service requirements can guide the work to
 >identify items such as which parameters to consider in signaling,
 >etc, but you maybe right. I am interested to hear providers opinion
 >on that. My suggestion would be to reuse what has been already
 >done in ITU (just we need to make it visible to ietf folks...).

I think framework document can describe service requirements.

Curret framework document (draft-takeda-l1vpn-framework-03) already 
contains service requirements. There may be some detailed points to be 
discussed, especially for the enhanced mode (sig+rtg model), as we see some 
discussion. (Framework document is describing a broad range of things, but 
not at the level of protocol requirements.) So, it may be necessary to 
narrow down the scope for the enhanced mode, which can be done through the 
mailing list, or if needed, through writing a separate draft. (I don't 
think we have an immediate need to write a separate draft.)

Best regards,

Tomonori

 >
 >Another item that needs to be added is "security" (after all
 >this is a VPN problem), and particularly that we allow
 >some critical information exchange between CE and PE.
 >My experience working on this topic is provider will want
 >maximum security between CE and PEs (and between providers)
 >clarifying how security is provided between PE and CEs
 >(and between provider border nodes) will help what appropriate
 >mechanisms to use for address separation, authentication, etc.
 >
 >Hamid.
 >
 >_______________________________________________
 >L1vpn mailing list
 >[email-masked]
 >https://www1.ietf.org/mailman/listinfo/l1vpn 

_______________________________________________
L1vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l1vpn

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 May 2005 15:04:09 +0200

Dimitri,

I might be a bit dogmatic about this, but I think that IETF
should be "protocol centric", it is fine to ue our prtocols
for whatever application they are useful for, but I would be
reluctant if we wer about to start specifying whatever protocol
that could be useful for an application

/Loa

[email-masked] wrote:

> loa,
> 
> ok - your point of view is to have a GMPLS VPN WG focusing on L1VPN for 
> now (and future will tell us if further LxVPN work should be included in 
> this working group - hope x will stay limited ;-)
> 
> in this case, it means we build a protocol-centric WG working on a 
> single application now and potential further extends its application 
> scope rather than having an application-centric WG working on 
> (extending) a protocol suite - difference is subtle but worth mentioning -
> 
> 
> *Loa Andersson <[email-masked]>*
> Sent by: [email-masked]
> 05/06/2005 12:33 ZE2
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> cc: Hamid Ould-Brahim <[email-masked]>, [email-masked], [email-masked]
> bcc:
> Subject: Re: [L1vpn] Proposed charter for L1VPN WG
> 
> 
> 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)
>  >
>  > 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 <[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 >
>  >
>  >  >
>  > < 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:  [email-masked]
>  >
>  >                                                                       
>                     [email-masked]
>  >
> --
> 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]

-- 
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: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 6 May 2005 09:39:11 -0400

Tomonori,

> think we have an immediate need to write a separate draft.)

I do agree the framework draft covers the requirements and is inline 
with ITU L1VPN work. An option that can be considered is to separate 
the requirements from the framework in separate internet draft and 
let the two drafts progress independently (from work point of view).
I assume at certain point solutions (and not the framework) would have 
to be compared to the set of requirements listed.

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 6 May 2005 10:32:39 -0400

Loa,

(I understand this email wasn't intended specifically
to me) but you raised an interesting point I would
like to comment on it. 
> do more than L1.

Back like four years ago, some of us (ietf folks) proposed
the topic of "Optical VPNs" (GMPLS VPNs). So we had at that 
time requirement draft and some solution drafts here and there. 
The feedback from presentations and discussions at IETF 
meetings came that Optical is not really covering TDM. 

We went back and made it clear that it is about 
"Optical/TDM" VPNs (no change on technical content just title 
change). After other IETF meetings, the feedback came as well 
that Optical VPN is not really within the scope of IETF and 
a proposal was made to call it Generalized VPNs which are VPNs 
built using IETF GMPLS protocols and they apply where GMPLS 
apply. 

We went to the work we have done and made another minor 
change (pretty much find and replace function). Changes things like 
"Connection" to "LSPs", Optical/TDM to GVPN, etc. We didn't really 
change the functionality of the 
mechanisms which stayed pretty much the same.

That is to say that it is not a major work to consider
services other than L1 as long as functions are
well defined using GMPLS and VPN constructs.

But I am okay if we focus initially on L1VPN as a service,
my suggestion would be that from protocol point of view the work 
should aim when possible to use GMPLS (and VPN constructs) 
regardless whether they apply to L1 or other interfaces 
supported by GMPLS such that if later on we decide to extend the 
mandate of that group we already have most of key protocol
work done.

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

I am fine with that. In fact I believe that the second
service model can be further subdivided in two
separate service models. One when the GMPLS provider network will 
appear to the client nodes as *one* private GMPLS-enabled node, 
and the other where the provider network appear as a subset of 
provider network resources (or nodes) to the client nodes as a  
private Gmpls network (fully interacting with client network).

Hamid.

---

From: [email-masked]
Date: Fri, 6 May 2005 17:06:09 +0200

hamid -

the framework document has been used to determine the protocol work this group is going to address, if two documents (requirements + framework) are to be progressed in parallel it means that either

- you suggest we keep continuing work on functional requirements but then one could question whether we agree on what to do in this working group ? (note: protocol details will be worked out as part of the protocol work anyway)

- or you do suggest that we close the requirements asap (but then what is the purpose of it as we would be all in agreement ? here also details will be worked out as part ofthe protocol work anyway) and the framework becomes the document where terms, working assumptions and other models get documented as suggested in the initial charter proposal

would you clarify your thought because i have some difficulties to understand the logic behind the below reasoning ?

"Hamid Ould-Brahim" <[email-masked]>
Sent by: [email-masked]
05/06/2005 09:39 AST

To: Tomonori TAKEDA <[email-masked]>, Alex Zinin <[email-masked]>
cc: [email-masked], [email-masked]
bcc:
Subject: RE: [L1vpn] Proposed charter for L1VPN WG

Tomonori,

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 6 May 2005 11:41:16 -0400

Dimitri,
 
My suggestion was more on the logistic side. More
likely requirement, framework, solutions/mechanism
will evolve (in terms of work) in parallel, 
if later on and as we progress an update is required
on the list of requirements that will impact only the 
mechanisms (like specific parameters) one needs 
not to go and update the framework document.
 
One can track the service requirements separately from
tracking the framework. I was actually talking about
service requirements (not specifically functional
requirements). And since we already have a set of
requirements why not start with that. Framework
and service requirements can progress first...
 
As I indicated before if providers think having
a separate service requirement draft is not required 
and it is okay to continue the req work within the framework
draft then I am fine with that. 
 
An example we can use is what has been done in 
l2vpn wg.
 
Hamid.
 
 the framework document has been used to determine the protocol work this
group is going to address, if two documents (requirements + framework) are
to be progressed in parallel it means that either

- you suggest we keep continuing work on functional requirements but then
one could question whether we agree on what to do in this working group ?
(note: protocol details will be worked out as part of the protocol work
anyway)

- or you do suggest that we close the requirements asap (but then what is
the purpose of it as we would be all in agreement ? here also details will
be worked out as part ofthe protocol work anyway) and the framework becomes
the document where terms, working assumptions and other models get
documented as suggested in the initial charter proposal

would you clarify your thought because i have some difficulties to
understand the logic behind the below reasoning ?

To: Tomonori TAKEDA <[email-masked]>, Alex Zinin
<[email-masked]>
cc: [email-masked], [email-masked]
bcc: 
Subject: RE: [L1vpn] Proposed charter for L1VPN WG

Tomonori,

Hamid.