Document: L2VPN OAM Requirements and Framework
Reviewer: Joel M. Halpern
Review Date: 2007-11-05
IETF LC End Date: 2007-11-09
IESG Telechat date: (if known) not known

Summary: This document is almost ready for publication as an Informational RFC.
	There are several small items that need to be addressed.

Comments:

Right after referencing three different types of Layer 2 VPNS (VPWS, VPLS, and IPLS) the text says that "The requirements are intended to identify OAM requirements for L2VPN services (e.g. VPLS and VPWS)."  is the omission of IPLS intentional?  If intentional, it should be explained. (I suspect that the intended answer is that IPLS are VPLS, but the text currently reads inconsistently.)

Given that section 3.1 says that the only underlying mechanism of interest is MPLS/IP, it would probably be a good idea to say that same thing in the very well written introduction.  (I am sure it is implicit in the terminology, but it seems a good idea to state it anyway.)  Or section 3.1 could be reworded not to say that the underlying transport must be MPLS/IP.

In describing diagram 5(D), it might be helpful if there were a little text explaining that the boundary between network operators must be MIPs for the Service Provider, and visible to the service provider, precisely because they are the MEPs for the individual network operator.  (I got stalled for a few minutes because I tried to compare with IP, where the customer does not see the ISP border routers differently from the ISP internal routers.  But this case is different.)  I realize the need is inherent in the required architecture.  Just a few words might have prevented a reader getting confused.

In the VPLS case, the Service Provider OAM domain spans multiple Network Operator OAM domains.  That makes sense.  But then the VPWS section
(5.2) explicitly makes the operator domain boundaries align with the Service Provider domain boundaries.  Is this deliberate?  If so, the difference needs to be explained.  If it is accidental, it is quite confusing.

The VPWS Data Path requirement states that VPWS must be forwarded using the "transfer plane."  Given that this is different from the VPLS requirement, it would seem that there ought to me some text explaining why the requirement is stricter for VPWS than for VPLS.  As a smaller point, the introduction of the phrase "transfer plane" is probably a mistake.  Just say explicitly that the forwarding must use the same forwarding mechanism as regular data.


Minor Comments:

Should the introduction include expansions of the terms VPWS, VPLS, and IPLS when they are first used just before section 1.1?  Or does the working group consider those effectively to be names rather than acronyms for the different services?

It seems odd to me, but is probably appropriate (which is why this is in the "minor" block) to require delay variation monitoring capability.
This seems odd for two reasons.  Firstly, one way delay measurement is only optional, not mandatory.  And the other is that many LAN services don't make delay variation commitments, so it seems surprising for this to be mandatory.  After all, one may want availability monitoring without jitter concerns.

The text in section 8.1 on Partial mesh issues for VPLS says that either the whole mesh should be shut down, or enough should be shut down to restore the full mesh connectivity.  The requirements actually say tha the OAM MUST support both capabilities.  This seems stricter than necessary.

The VPLS Connectivity Faul Notification text says that the OAM "should"
provide alarm suppression.  Then the requirement text (R15) actually says "MUST support."  This may be consistent, but it is confusing.