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

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 5 May 2005 20:07:06 -0400

Alex,

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

It's not too late to bring them back to RTG (better late 
than never) ;-).

> L1VPN builds on CCAMP work, so it makes sense to put it in RTG.
> 
> >> 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.
> 
> How do you think the text should be changed?
> 

How about we say:

"L1VPN Working Group's task is to specify mechanisms 
necessary (and combination thereof) for implementing 
provider-based L1VPN services using GMPLS protocols 
as defined in IETF". 

I think there are in fact multiple L1VPN service models,
each L1VPN service model will need to be implemented through 
a consistent vertical solution, and one or more L1VPN mechanisms 
can be defined and combined to implement one or more 
vertical solutions. Note I removed the GMPLS transport network
(I found a bit specific...).

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

I suggest we replace the terms "GMPLS network" with
"provider GMPLS enabled network...". 

In the basic mode since the path signaling is done for the 
purpose of L1VPN then I think it is important to indicate that 
signaling is accomplished within a given CE-CE connectivity topology.

Here is my text suggestion for 1.

"1. Basic mode: the CE-PE interface's functional repertoire 
    is limited to path setup signalling only between CEs 
    members of the same L1VPN across the provider network.  
    The provider GMPLS enabled network is not involved in 
    distribution of user's routing information."

> 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.
> 
> More the latter. I didn't think we should spell the former out.
> 

I prefer we spell discovery out clearly to avoid some confusion later on.

Using your proposal in your reply to Adrian below:

"  2. Enhanced mode: the CE-PE interface provides the signaling capabilities
     as in the Basic mode, plus permits limited exchange of information
     between the control planes of the provider and the user to help such
     functions as discovery of reachability information in remote sites,
     or parameters of the part of the provider's network dedicated to
     the user."

I think the routing is a bit tricky here. The enhanced mode
(which in fact can map to one or two L1VPN service models") may imply 
only that the exchange of routing is done only between
the user control plane and "a control plane" running on the PE. That
control plane running on the PE may have no relation to the provider
actual control plane.  

How about rewriting the above paragraph to be:

"  2. Enhanced mode: the CE-PE interface provides the signaling capabilities
     as in the Basic mode, plus permits exchange of L1VPN user routing
     information between the CE control plane and a control plane(s) running

     on provider edge nodes. In this context functions such as discovery of 
     reachability information in remote sites, or parameters of the part of
the 
     provider's network dedicated to the user need to be specified."

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

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

---

From: Alex Zinin <[email-masked]>
Date: Wed, 11 May 2005 14:26:54 -0700

Comments to Hamid, and Loa:

> "provider GMPLS enabled network...". 

Did some changes

> signaling is accomplished within a given CE-CE connectivity topology.

This would clearly simplify the mechanisms, security especially. Let's
leave this sort of details to the WG though.

> How about rewriting the above paragraph to be:

Again, we're not doing the design here, so let's not split the hair.
If the above text is "good enough", we should stop editing it. There will
never be a wording perfectly satisfying everybody.

Loa:
> 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.

My understanding is that at this point, the enhanced mode includes
two possibilities: overlay with user route distribution assist,
and peer-to-peer.

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

Of course, this list shouldn't limit the actual WGs that this one
would work with, but I have no problem with expanding it.

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

"In cooperation with" was an abbreviation of the process that we (you, I,
et al) are using now and that's a bit more complicated then just doing
the extensions in the protocol WGs:

 - L1VPN reviews the proposed extension from the L1VPN perspective
   If positive, refer it to the protocol WG.

 - The protocol WG reviews the extension.
   If positive, it adopts the extension as a WG item, or says "nah, it's
   OK, guys, it's simple, you can do it, make sure you check with us when
   ready", and L1VPN takes it then.

// do we need a bcp on this?
   
--
Alex