Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [FrameworkReview]

From: "Dinesh Mohan" <[email-masked]>
Date: Thu, 1 Mar 2007 11:03:30 -0500

Shane,

Please see inline marked DM>> (rest of email snipped for clarity)

---
Dinesh

<snipped>

Perhaps I wasn't clear in my originally proposed text or follow-up
comments.  Let me try again, this time using a different approach.

DM>> This is indeed a different approach (see below) :-)

Can we agree that there is a portion of the VPLS architecture that
relates to native Ethernet, for example, when the communication path
between an MTU-s and an upstream PE-rs is using Q-in-Q encapsulation?
If yes, then I have not seen any *requirement* in the requirements
section to acknowledge that the goal of any proposed solution is to, at
most, inter-work with -- but, MUST NOT break! -- existing IEEE/ITU OAM
standards, related to the native Ethernet service-layer of VPLS, in
order to provide an "end-to-end" solution for VPLS OAM.

There are some requirements in Section 6.11, (Transport Independence),
related to OAM transport independence & interworking/ adaptation.
However, what I am recommending is that you be more specific in Section
6 and clearly articulate that VPLS OAM solutions MUST NOT: a) break
existing IEEE/ITU OAM protocols; or, b) define extensions or wholly new,
competing OAM messages for IEEE/ITU OAM protocols.  Clearly, this would
indicate to solutions designers that if a solution requires (b), they
had better work those changes through the IEEE/ITU and, only after said
changes, extensions, etc.  
are approved in the appropriate SDO, may a VPLS OAM solution consider
interworking with that protocol.

DM>> Even though there seems to be a NEW kinds of requirement being
proposed here which suggest to mention what is not to be done (bit odd,
since there are certainly many other things that should also not be
done, e.g. working independently in this group on extending LSP ping for
example, or VCCV etc.), fortunately, there is no disagreement on this
point and I will be more than willing to add a statement to this effect
in the document.

However, at the same time, in the interest of progressing this document
and not causing an endless loop to create new requirements at the last
minute, I would like to ask if similar requirements were captured in
L2VPN Requirements RFC? Hasn't this been the understanding of the IETF
in general that any time solutions are proposed which require extension
of protocols owned by other SDOs or groups, the work has to be carried
out in appropriate bodies?

<snipped>

---

From: Shane Amante <[email-masked]>
Date: Thu, 01 Mar 2007 13:36:32 -0700

Dinesh,

> point and I will be more than willing to add a statement to this effect

First, it certainly doesn't hurt, and more than likely helps, explain 
what should NOT be done as much as what SHOULD be done with respect to 
requirements that solutions will ultimately be derived from.  In fact, 
in looking at the reqmt's in this particular draft, it is heavily biased 
toward what should/must be done, rather than what should not or must not 
be done.  However, it's too late to change that now.

Second, I recognize your point that we can't possibly call out every 
requirement and non-requirement.  OTOH, at least having this discussion, 
particularly with a wider audience, leads to a more explicit 
understanding of the eventual goal and an expectation around how we 
might achieve that goal, rather than what is implied or inferred based 
on [assumed] previous precedent.

> out in appropriate bodies?

With respect to precedent, I would refer you specifically to Section 
5.1, "Scope of Emulation", in RFC 4665:
    L2VPN protocols SHOULD NOT interfere with existing Layer 2 protocols
    and standards of the Layer 2 network the customer is managing.  If
    they impact customer Layer 2 protocols that are sent over the VPLS,
    then these impacts MUST be documented.

Since I don't see it called out specifically in the OAM draft, do we 
assume that draft-ietf-l2vpn-oam-req-frmk agrees with the above 
statement relative to Ethernet OAM protocols?  I don't see why the OAM 
draft has any reason to disagree with RFC 4665, however if you look at 
R10b of Section 6.11, "Transport Indedepence":
---snip---
(R10b) VPLS OAM MAY allow adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful
to allow Fault Notifications from transport/network layer(s) to be
sent to the VPLS service layer.
---snip---

The "_adaptation/interworking_ with specific transport/_network_ OAM 
functions" implies that a VPLS OAM solution may, in fact, interfere with 
"existing Layer 2 protocols and standards of the Layer 2 network".  I'm 
not going to argue about the words 'adaptation' and 'interworking', 
rather the larger points here are:
a) Does Section 6.11 in the OAM draft conflict with RFC 4665?  (Based on 
your response, it sounds like you agree it doesn't).
b) Since it doesn't conflict with RFC 4665, why can't you just 
explicitly say that any solutions must follow the same precedent?

-shane