Re: [L1vpn] Proposed charter for L1VPN WG

["Adrian Farrel" <adrian at olddog.co.uk>]

Hi Dimitri,

> "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."
>
> which OAM mechanisms are you referring to in the L1 context ? if you are
> referring to the control plane mechanisms they should be part of the
corr.
> control document

Definitely CP mechanisms.
But I while I would want requirements up front, and protocol extensions to
consider OAM requirements, I would not necessarily want protocol
extensions to become heavily bound up with OAM solutions. For example, we
would not insist that the MIB modules formed part of the protocol
extensions.

> this said, why not combining item 8 and 9 in a single item and leave the
> multiple-provider case for the next step

I think I can agree to leaving multi-provider to the next step (although
note that we have already received a question about how to provide this
function).

In which case, we are not combining items 8 and 9. We are deleting item 9.
This is fine.

> "8. Guidelines for applying the basic and extended modes for
> single-provider networks."

Also OK.

> note: you were also questioning about the reason of
>
> " Dec 06 Submit L1VPN framework to IESG for publication as Informational
> RFC"
>
> for a document defining the reference network model, L1VPN service
> model, fundamental assumptions, and terminology; indeed the framework
leads
> as its first version is going to be submitted by Sep05 should lead and
> should be 90%+ cooked. but it also covers terminology and other certain
> aspects that can be retro-actively impacted by the protocol work -
> experience has shown that such document becomes fully stable when the
> protocol work is near completion

OK, whatever works.
We certainly saw an element of this during (e.g.) P2MP MPLS TE, but we
will still complete the document containing the terminology ahead of the
protocol spec.

Adrian