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

From: [email-masked]
Date: Fri, 6 May 2005 11:43:49 +0200

adrian

you mention

"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

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

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 May 2005 16:57:43 +0100

Hi Dimitri,

> referring to the control plane mechanisms they should be part of the
corr.

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.

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

> single-provider networks."

Also OK.

> 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