Subject: [L1vpn] Proposed charter for L1VPN WG

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 10:03:17 -0700

Folks-

 Please find below the proposed text of the charter for L1VPN WG. I've ran
 it past the usual suspects, but would appreciate comments from everyone
 (even you're a suspect and your only comment is "OK").

--
Alex

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

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

 The WG will work on the following items:

  1. Framework document defining the reference network model, L1VPN service
     model, fundamental assumptions, and terminology.

  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.

  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: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 May 2005 20:15:54 +0100

Thanks Alex (and the back-room boys) for putting this together.
It is really great to see some forwards movement, and this is a very good
start at a charter draft.

Comments in line.

Cheers,
Adrian

>  Alex Zinin <[email-masked]>

I think a TA would be really sensible. The WG is going to be touching the
edges of a few signaling and routing protocols, as well as working with
transport concepts - quite a broad spectrum.

>  L1VPN Working Group's task is to specify mechanisms necessary for

s/L1VPN/The L1VPN/

>  providing a VPN service over a GMPLS transport network.

Question: Is the definition of such a service and the statement of the
requirements not part of the WG's task?
While we can absorb some of the requirements as expressed by the ITU and
also show them in the framework, some areas (like the enhanced mode
[sig+rtg]) may need a little more work to capture the requirements before
working on the specifications.

>      plane (e.g. network-layer reachability information as in the
MPLS/BGP model).

These statements are fine, but they do not cover two other functional
units. It may be that you intended to exclude these, but if so it would
help to be explicit.
a. Distribution of information about the provider's resources/topology
over the CE-PE interface.
b. Distribution of membership information from CE to PE (maybe you see
this as "some information from the user's control plane", in which case,
how about deleting the "(e.g. network-layer......)"?)

>      model, fundamental assumptions, and terminology.

I am not sure that the use of the established terms "UNI" and "NNI" are
helpful in this context (below). It seems that they raise more questions
than they answer.

But most importantly, I don't think we should use terms in the charter
without defining them in the charter. (This works well for basic and
extended mode, above).

>      including both CE and PE functionality.

"Specification" is too loose a term. Does this mean specification of the
architecture, function, requirements or protocol?

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

Do you mean "node-to-node" or "network-to-network"?

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

What about other OAM concerns?
What about applicability guidance for choice between the four modes?

Also, what about the existing "applicability" draft that discusses the
applicability of various existing protocol models to satisfying the
different L1VPN modes? Do you imagine this being broken up into the
"specifications" above, or does it have value as an independent I-D?

>  the WG will also cooperate with ITU-T.

I think "where necessary" is too unspecific (and, BTW, sounds hugely
derogatory - which I am sure is not what you meant!). I suggest replacing
with...
   The WG will also cooperate with the ITU-T in the development of L1VPN
   requirements and the statement of operational models.

>   Dec 06 Submit L1VPN framework to IESG for publication as Informational
RFC

Why is this so late in the list? If you were talking about an
architecture, I would understand why it is pretty much the final
milestone, but I thought a framework should lead. That is, we shouldn't
even start on the specifications until the framework is 90%+ cooked.

>   Aug 07 Submit MIB modules for UNI and NNI enhanced mode to IESG for
publication as Proposed Standard

Initial dates seem quite realistic. Later dates are, perhaps, a long way
ahead.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 15:33:37 -0700

Adrian,

inline below, pls

> transport concepts - quite a broad spectrum.

Re routing, I hope the fact that the WG is positioned with RTG and that the
responsible AD is from the same area, should help WG coordination.
Which transport concepts did you have in mind that you though we should
have a TA for?

> s/L1VPN/The L1VPN/

ok

> working on the specifications.

If there's a clear understanding/consensus within the community on what
needs to be done, writing a requirements document would only delay
progress. If, however, there's a consensus here that the WG should do this
before jumping on the enhanced mode spec, I would not object, as long as we
keep it very laconic.

> how about deleting the "(e.g. network-layer......)"?)

Do we really have to spell out distribution of VPN membership info?

Re point a above, how about this:

  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.

> without defining them in the charter. (This works well for basic and

Please suggest changes.

> architecture, function, requirements or protocol?

One or more documents going to STD and used to described the above piece
of functionality.

> Do you mean "node-to-node" or "network-to-network"?

I didn't like network-to-network, because supposedly this may well be nodes
within a single network. Open for suggestions.

> What about other OAM concerns?

Please suggest changes

> What about applicability guidance for choice between the four modes?

ditto

> "specifications" above, or does it have value as an independent I-D?

I think it will depend on how the specs end up being written, and whether
we'll need separate applicability statements for them. I don't want to
overload the charter.

>    requirements and the statement of operational models.

I don't think "where necessary" is more derogatory when applied to ITU than
when applied to other IETF WGs, I don't see a problem there.

Reading your suggested wording:

 - how much work on requirements do you believe is required ?
 - what do you mean by operational models?

> even start on the specifications until the framework is 90%+ cooked.

That depends on the perceived role of the fw document. If it has the role
of the initial architecture, then you are probably right. If its role is an
informational document pulling pieces together (which is how I look at it),
then I would be against making it a prerequisite for further work.

--
Alex

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2005 02:10:55 +0100

Hi,

> Which transport concepts did you have in mind that you though we should

Data plane transport concepts, not X.200 transport layer protocols.

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

No, but then I would not put in the example you cited either.

>      or parameters of the part of the provider's network dedicated to

Yeah.

> > without defining them in the charter. (This works well for basic and

Certainly. You'll notice that I have rolled all of your "please suggest
changes" into this list. Also added point 9 while I was thinking of it,
but I would understand if you wanted to punt this to a re-charter.

2. Specification of the L1VPN signaling functionality between the user
network and the provider network to support the basic mode.

3. Specification of the L1VPN signaling and routing functionality within
the provider network to support the basic mode.

4. OAM features and MIB modules and/or extensions required for the basic
mode.

5. Specification of the L1VPN signaling and routing functionality between
the user network and the provider network to support the extended mode.

6. Specification of the L1VPN signaling and routing functionality within
the provider network to support the extended mode.

7. OAM features and MIB modules and/or extensions required for the
extended mode.

8. Applicability guidelines to compare the basic and extended modes.

9. Specification of the L1VPN extensions for applying the basic and
extended modes to multi-provider L1VPNs.

> >>  CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary. Where
> >>  necessary, the WG will also cooperate with ITU-T.
>

I said you dodn't mean it to sound the way it sounds. I can only report
how it sounds.

>  - how much work on requirements do you believe is required ?

Minimal. Just a cross-check.

>  - what do you mean by operational models?

I mean "Service Models" as in section 7 of
draft-takeda-l1vpn-framework-03.txt.
Again, mainly cross-check work.

What I am trying to do is point up the areas where we can take sensible
input from the ITU-T. These are the areas where they have done most work
and where their SP-oriented make-up can help us most.

> >>   Dec 06 Submit L1VPN framework to IESG for publication as
Informational
> then I would be against making it a prerequisite for further work.

Ah well, whatever. The document is already cooked and ready for
publication as an RFC, so it doesn't make too much difference.

Adrian