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

["Joel M. Halpern" <[e-mail]>]

In most of these cases, what I am asking for is clarifying text because
as a reader it was hard to follow what was intended.  Your comments
almost all take the form of "but it already means the right thing."
I am not the one who makes the final call, but I really think that some
clarifying words in many of these would help.
I have gone through and tried to explain again in line below.

Joel

Dinesh Mohan wrote:
> 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.

Yes, the structure requires that the underlying network be MPLS / IP.
But I reader may not be as intimately familiar with the framework, and
may not realize that requirement.  So a sentence in the introduction
will help ensure that the reader has the right frame of reference for
understanding the document.
> 
> 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.

Yes, the earlier texts says that low layer MEPs can correspond to higher
layer MIP / MEPs.  The question isn't whether the architecture is
consistent.  The issue is that it took significant time and interfered
with understanding to realize what was actually happening at the
boundaries.  An extra sentence would have helped.
> 
> 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 issue for me as a reader is that the two cases (VPLS and VPWS are
drawn differently with regard to the layer relationship.  As far as I
can tell, there is no requirement that the VPWS operator domain boundary
align with the service provider boundary.  Therefore, I find it
confusing that the diagram shows them aligned.  (Any reader can
understand that the boundaries sometimes align.  When the diagram shows
them aligned, the reader is led to think they must be aligned.)  If in
fact they must be aligned, that that needs to be explicitly stated in
this document.

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

I think the use of the term "transfer plane" just because it was used in
another draft is a mistake.  In general, introducing two terms for the
same thing leads to confusion, not clarity.
It is not clear from your explanation whether the reuirements for VPLS
and VPWS are intended to be different (if so, why) or if it is just that
no one seems to be trying to violate the requirement in the VPLS space.
 If the later, it should still be a VPLS requirement even if no one is
doing it wrong.

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

The terms should be expanded.

> 
> 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.
I presumed it was WG agreement.  And I said it was minor.  But requiring
Jitter measurement seems over the top to me.

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

While I am concerned that you may be over-burdening the OAM, it's your
call.

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

Given taht I think you need to fix some of the other items, and given
that it is confusing, I think you SHOULD make this fix :-)

> 
> Yours,
> Joel M. Halpern
> 
> 
> 


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