Re: [Gen-art] LC review: draft-ietf-l2vpn-oam-req-frmk-09.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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.

Yours,
Joel M. Halpern

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art