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

["Dinesh Mohan" <[e-mail]>]

Joel,

First of all, thank you for your comments. Also, apologies for
inadvertent delayed response. Please see inline responses: 

Regards,
----
Dinesh 

-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Monday, November 05, 2007 9:45 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; Mohan, Dinesh (CAR:NP02);
[e-mail]; [e-mail];
[e-mail]
Subject: 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.alves
trand.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.)

DM>> Section 2 does contains a statement "IPLS is a special VPLS which
is used to
carry only IP service packets." which is based on RFC4664 (L2VPN
Framework) referenced in the same para. Further, during the L2VPN
activities, the IPLS specific requirements were solicited multiple times
and no specific requirements were put forward. Therefore, following this
due diligence, the current coverage of IPLS in current draft via VPLS
requirements seems sufficient to the authors. Please let us know if this
satisfies your comment.

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.

DM>> This document is based on RFC4664 (L2VPN Framework) and section 3.1
specifically mentions that "Similarly in context of L2VPNs, network
layers consist of MPLS/IP networks. The MPLS/IP networks can consist of
networks links realized by different technologies e.g. SONET, Ethernet,
ATM etc." Therefore, the authors feel that it is explicitly stated in
the text. Please let us know if this satisfies your comment.

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.

DM>> Section 3.3 which introduces MEPs and MIPs contains the text "In
Hierarchical OAM Domains, a MEP of lower-level OAM domain can correspond
to a MIP or a MEP of a higher-level OAM domain." and also "Further, the
MEs (or MEGs) are hierarchically organized in hierarchical OAM
domains.". Section 4.2.3 containing Figure 5(D) uses the same concepts
introduced in Section 3.3. Section 5.2.3 also uses the same concepts
introduced in Section 3 for VPWS. Therefore, the authors feel that this
is already covered in the document. Please let us know if this satisfies
your comment.

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.

DM>> The specific coverage of VPLS and VPWS domains is inline with L2VPN
architectures. For VPLS, which involves Ethernet service offer, we have
specifically addressed distributed case (H-VPLS) in L2VPN, involving
U-PE and N-PE both of which have Ethernet service visibility and
therefore access, core and access networks shown specifically. For VPWS,
the AC are typically not represented as separate network operator
domains in the architecture and if the PSN involves multiple network
operators and therefore MS-PWs, these are not yet closed completely and
reflected in L2VPN architecture. Furthermore, the S-PEs for MS-PW are
not typically native service aware and therefore make no difference in
terms of OAM architecture shown in Sec 5.2. Therefore the authors feel
that since we are inline with RFC4664, no updates are needed to this
document for VPLS and VPWS cases. Please let us know if this satisfies
your comment.

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.

DM>> R6 for VPLS Data Path is similar to R17a for VPWS Data Path.
Further, for the case of VPWS, R17b is spelled out since current LSP and
PW OAM solutions use either data plane and control plane for exchanging
status information and acknowledgements. Therefore, R17b explicitly
indicates that for VPWS service, that involves ACs and PW, data plane
must be used for forwarding VPLS OAM rather than control plane. On the
smaller point, we agree that we could do without introducing "transfer
plane" however this was used in a draft submitted by different service
providers in PWE3 for VPWS OAM which was later decided to be integrated
into this L2VPN document. Given we do indicate that transfer plane is
the same as data plane in the requirement R17b text, please let us know
if this is still an issue. Also, let us know if this satisfies your
overall comment.


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?

DM>> You are correct, we could expand the terms VPWS, VPLS and IPLS in
Section 1. This will be a minor editorial update, however, since we also
consistently mention that we use terms defined in RFC4664, these
acronyms are well recognized in our L2VPN work. Please let us know if
you think given the familiarity of terms in L2VPN, we could avoid
updating the document simply for this purpose (of course, if other
changes are deemed necessary, we will introduce this minor editorial
update).

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.

DM>> The requirements have been written and agreed with L2VPN WG members
based on pragmatic considerations. This is the reason why one-way delay
is optional since it requires clock synchronization among the nodes.
Also, service provides are also looking to offer both LAN and P2P
services across VPLS (e.g. two UNI on VPLS service instance). Within LAN
service, the SLA offerings have been improving as additional
capabilities and service differentiation is being added. Therefore,
these capabilities must be present and in some deployments, these may
not be turned on. As a result, the authors feel that no change is needed
in the document. Please let us know if the above explanation satisfies
your comment.

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.

DM>> R13b and R13c address different service deployment models that may
be used for LAN service, one being absolute service where all end-points
need to be connected all the time, other where some partial service is
acceptable in failure scenarios. Therefore OAM requires support for both
mechanisms since it will then be up to the SPs to use either model.
Hopefully this satisfies your comment.

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.

DM>> You are correct. The text must also mention "must" for consistency
with the requirement. The requirements specifically use the normative
text. As mentioned earlier, the authors will make the minor editorial
update if other updates to the document are warranted. However, Please
let us know if you think we could avoid updating the document purely for
this reason (in case other comments do not warrant an update).

Yours,
Joel M. Halpern




_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art