Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework
draft-ietf-l2vpn-oam-req-frmk-11

[Ballot comment]
I would suggest replacing the first paragraph of the security considerations with something along the following lines:

  This specification assumes that L2VPN components within the OAM domain are mutually trusted.  Based on that
  assumption, confidentiality issues are fully addressed by filtering to prevent OAM frames from leaking outside their
  OAM domain. Similarly, authentication issues are addressed by preventing OAM frames generated outside from
  entering the OAM domain.  Requirements to prevent OAM messages from leaking outside an OAM domain and for
  OAM domains to be transparent to OAM frames from higher OAM domains are specified in Section 6.10 and 7.10. 

I think this is a bit clearer than "This document takes into account the security considerations and ..."

[Ballot comment]
I would suggest replacing the first paragraph of the security considerations with something along the following lines:

This specification assumes that L2VPN components within the OAM domain are trusted.  Based on that assumption,
confidentiality issues are fully addressed by filtering to prevent OAM frames from leaking outside their OAM domain.
Similarly, authentication issues are addressed by preventing OAM frames generated outside from entering the OAM
domain.  Requirements to prevent are specified in Sec

[Ballot comment]
I would suggest prepending the following (or something like it) to the second paragraph of the security considerations:

This specification assumes that L2VPN components within the OAM domain are trusted.  Based on that assumption,
confidentiality issues are addressed by filtering to prevent OAM frames from leaking outside their OAM domain.
Similarly, authentication issues are addressed by preventing OAM frames generated outside from entering the OAM
domain.

[Ballot comment]
Because of the interdependencies of this work with work and documents published in the IEEE 802.1 WG, ITU-T and MEF I believe it would have been better if these SDOs have been notified and asked to review this work.

[Ballot comment]
1. The titles and dates of the IEEE 802.1 standards mentioned in the references need to be updated.

2. Because of the interdependencies of this work with work and documents published in the IEEE 802.1 WG, ITU-T and MEF I believe it would have been better if these SDOs have been notified and asked to review this work.

[Ballot discuss]
1. This document is part of a rather complex set of OAM documents issued by different standards organizations. I am familiar to some extend to the relevant work done in other places, and yet I find it difficult to synchronize information and terminology and to make sense about who makes what and how a real life deployment looks like. In this document you need to get to sections 4 and 9 to discover some of the information burried there. I think that a 'Relationship with other OAM work' sub-section in the introduction would be extremely useful in clarifying what each SDO defines, where the authoritative definition of terms resides, and how a user of the l2vpn OAM will use it in combination with OAM defined in other documents.

2. I asked this question in the WGLC but I never received an answer. The document refers in sections 6,7, and 8 to a set of performance metrics like frame loss, frame delay (one-way, two-way) and frame delay variation that are defined per service, and indeed the OAM requirements mention the need of measuring them per service. There is no mention and I am wondering whether the terms are consitent with the terminology defined in IPPM, and if IPPM work (RFC 2679, 2680, 3393) can be used, or because we are dealing with a sub-IP layer these metrics will need to be defined separately, maybe even with a specific OAM methodology per type of service.

3. [fixed in draft-10]

4. Section 1 mentions a notification service that reflects a 'client/server relationship between two layered networks'. I understand that this is different from the Connectivity Fault Notification requirements defined in 8.3 and I cannot find the appropriate definition of requirements for this service further in the rest of the document.

5. [moved to COMMENT after the clarification received from editors - now item #2 at COMMENT]

[Ballot discuss]
1. This document is part of a rather complex set of OAM documents issued by different standards organizations. I am familiar to some extend to the relevant work done in other places, and yet I find it difficult to synchronize information and terminology and to make sense about who makes what and how a real life deployment looks like. In this document you need to get to sections 4 and 9 to discover some of the information burried there. I think that a 'Relationship with other OAM work' sub-section in the introduction would be extremely useful in clarifying what each SDO defines, where the authoritative definition of terms resides, and how a user of the l2vpn OAM will use it in combination with OAM defined in other documents.

2. I asked this question in the WGLC but I never received an answer. The document refers in sections 6,7, and 8 to a set of performance metrics like frame loss, frame delay (one-way, two-way) and frame delay variation that are defined per service, and indeed the OAM requirements mention the need of measuring them per service. There is no mention and I am wondering whether the terms are consitent with the terminology defined in IPPM, and if IPPM work (RFC 2679, 2680, 3393) can be used, or because we are dealing with a sub-IP layer these metrics will need to be defined separately, maybe even with a specific OAM methodology per type of service.

3. [fixed in draft-10]

4. Section 1 mentions a notification service that reflects a 'client/server relationship between two layered networks'. I understand that this is different from the Connectivity Fault Notification requirements defined in 8.3 and I cannot find the appropriate definition of requirements for this service further in the rest of the document.

5. Because of the interdependencies of this work with work and documents published in the IEEE 802.1 WG, ITU-T and MEF I am wondering if these SDOs have been notified and asked to review this work.

-------- Original Message --------
Subject: Moving draft-ietf-l2vpn-oam-req-frmk-10.txt (Informational RFC) forward
Date: Fri, 25 Jul 2008 10:18:56 +0200
From: Mark Townsley
To: draft-ietf-l2vpn-oam-req-frmk@tools.ietf.org, "l2vpn-chairs@tools.ietf.org" , Ron Bonica , Russ Housley , Tim Polk , Dan Romascanu , David Ward , "Joel M. Halpern"


This is part of a general review of documents on my plate in the IESG in
advance of the Dublin meeting.  I am giving advice here on how to move
forward based on the current read of the tracker. See DISCUSS and
COMMENT actions cc'd from the tracker below.

I do notice that there has been a new version submitted recently, but it
does not seem to address all the issues from the IESG below.

Please Answer Ron's question here. I personally don't think that, as an
Informational Framework document, this can be prescribing whether
the measurement is done on box or not - this is out of scope of
the document.

To Russ' comment from Joel. I believe that the VPWS boundary does
not have to coincide with the SP boundary (e.g., a single SP may
have its own VPWS boundaries within its network). So, the any
alignment assumptions in the text should be incidental. Please work
with Joel to find out where those areas were, and ensure that the
text makes it clear that this is not prescriptive.

Tim points out two items. For #2, please let Time and I know if the
latest version of the document addresses the resolutions from the secdir
review. For #1, do you need to have the ability to authenticate and
integrity protect the OAM alarms? If not, you need to specify why.

Dan has a lot of points. First, if there are aspects of this document
coming from other SDOs, please point that out - and if that means
sections could be removed by replacing them with reference
to the other SDO's work, so much the better. Dan, as a framework document
perhaps your second point is out of scope - much like the answer
to Ron's comment would be. e.g., in general if the document would back
off on prescriptive text, it would better fit an informational framework
document, while at the same time avoiding some of the issues I see
from you (and David Ward). #3 #4 seem to be indicators that this document
has not been iterated and reviewed enough. Please ensure consistency
in the document. Finally, #5 is a relevant point about SDO interaction -
certainly, SDOs have to work with one another, but we must make sure
that we don't step on any toes here. We should probably at least
have our IEEE liaison and/or someone from the ITU-T review this (if not
gear up the formal liaison process, but i'd rather keep this lightweight
if possible).

I'm moving the document to Revised ID needed as I believe that it will
need a new version in order to be approved. Lead editors, please work
individually with discuss holders to better understand their positions,
so that the next version can be approved.

Thanks,

- Mark


Discusses and Comments
Ron Bonica:
Discuss:
[2007-12-19] Many of the requirements are ambiguous. For example, you say:

(R16) VPWS OAM MUST support measurement of per-service frame/packet
delay variation between two VPWS service aware devices that support
the same VPWS service instance within a given OAM domain.

Does that mean that the box offering the service should be able to
measure jitter. Or that you should be able to attach a box external to
the service to measure jitter? If the latter, is it really a requirement
of the service?

Russ Housley:
Discuss:
[2007-12-20]
The Gen-ART Review by Joel Halpern has not received a response.
It can be found at:

  http://www.alvestrand.no/ietf/gen/reviews/
  draft-ietf-l2vpn-oam-req-frmk-09-halpern.txt

I am especially interested in a response to this part of the review:
>
> 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.

Tim Polk:
Discuss:
[2007-12-20] #1 Fault management is clearly a security relevant
operation.  Reporting nonexistent faults,
whether accidental, through misconfiguration, or by a malicous node,
seems likely to cause
major operational problems.  Alarms and subsequent fault management
messages are transmitted and forwarded between nodes. However, there is
no mention of integrity or authentication
requirements for fault alarms, verification, or localization.

#2 Several issues with respect to security considerations were also
raised in Tobias Gondrom's
secdir review.  From the email thread, these issues appear resolved (or
nearly so), but the
document has not been updated.

Dan Romascanu:
Discuss:
[2007-12-20] 1. This document is part of a rather complex set of OAM
documents issued by different standards organizations. I am familiar to
some extend to the relevant work done in other places, and yet I find it
difficult to synchronize information and terminology and to make sense
about who makes what and how a real life deployment looks like. In this
document you need to get to sections 4 and 9 to discover some of the
information burried there. I think that a 'Relationship with other OAM
work' sub-section in the introduction would be extremely useful in
clarifying what each SDO defines, where the authoritative definition of
terms resides, and how a user of the l2vpn OAM will use it in
combination with OAM defined in other documents.

2. I asked this question in the WGLC but I never received an answer. The
document refers in sections 6,7, and 8 to a set of performance metrics
like frame loss, frame delay (one-way, two-way) and frame delay
variation that are defined per service, and indeed the OAM requirements
mention the need of measuring them per service. There is no mention and
I am wondering whether the terms are consitent with the terminology
defined in IPPM, and if IPPM work (RFC 2679, 2680, 3393) can be used, or
because we are dealing with a sub-IP layer these metrics will need to be
defined separately, maybe even with a specific OAM methodology per type
of service.

3. Section 9 refers to a 'management option introduced in Section
5.2.3.2' but there is no such seb-section and from the reading of 5.2.3
I cannot figure out what this refers to.

4. Section 1 mentions a notification service that reflects a
'client/server relationship between two layered networks'. I understand
that this is different from the Connectivity Fault Notification
requirements defined in 8.3 and I cannot find the appropriate definition
of requirements for this service further in the rest of the document.

5. Because of the interdependencies of this work with work and documents
published in the IEEE 802.1 WG, ITU-T and MEF I am wondering if these
SDOs have been notified and asked to review this work.

Comment:
[2007-12-20] The titles and dates of the IEEE 802.1 standards mentioned
in the references need to be updated.

David Ward:
Comment:
[2007-12-19] It is interesting that this document has no normative
language whatsoever but, definitely alludes to preferred choices. I
found the meat of the doc to be in Section 9 where [IEEE 802.1ag] and
[ITU-T Y.1731] were attempted to be elevated to the protocols of choice
(though using  the word choice "can"). It was mentioned that VCCV and
BFD "can" be used in the interim until [IEEE 802.1ag] and [ITU-T Y.1731]
are available.

Should a document that goes into such detail and intending to recommend
protocol choice be so vague as not use normative language?

[Ballot discuss]
#1 Fault management is clearly a security relevant operation.  Reporting nonexistent faults,
whether accidental, through misconfiguration, or by a malicous node, seems likely to cause
major operational problems.  Alarms and subsequent fault management messages are transmitted and forwarded between nodes. However, there is no mention of integrity or authentication
requirements for fault alarms, verification, or localization. 

#2 Several issues with respect to security considerations were also raised in Tobias Gondrom's
secdir review.  From the email thread, these issues appear resolved (or nearly so), but the
document has not been updated.

[Ballot discuss]
Several issues with respect to security considerations were raised in Tobias Gondrom's
secdir review.  From the email thread, these issues appear resolved (or nearly so), but the
document has not been updated.

[Ballot discuss]
The Gen-ART Review by Joel Halpern has not received a response.
  It can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-l2vpn-oam-req-frmk-09-halpern.txt

  I am especially interested in a response to this part of the review:
  >
  > 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.

[Ballot discuss]
1. This document is part of a rather complex set of OAM documents issued by different standards organizations. I am familiar to some extend to the relevant work done in other places, and yet I find it difficult to synchronize information and terminology and to make sense about who makes what and how a real life deployment looks like. In this document you need to get to sections 4 and 9 to discover some of the information burried there. I think that a 'Relationship with other OAM work' sub-section in the introduction would be extremely useful in clarifying what each SDO defines, where the authoritative definition of terms resides, and how a user of the l2vpn OAM will use it in combination with OAM defined in other documents.

2. I asked this question in the WGLC but I never received an answer. The document refers in sections 6,7, and 8 to a set of performance metrics like frame loss, frame delay (one-way, two-way) and frame delay variation that are defined per service, and indeed the OAM requirements mention the need of measuring them per service. There is no mention and I am wondering whether the terms are consitent with the terminology defined in IPPM, and if IPPM work (RFC 2679, 2680, 3393) can be used, or because we are dealing with a sub-IP layer these metrics will need to be defined separately, maybe even with a specific OAM methodology per type of service.

3. Section 9 refers to a 'management option introduced in Section 5.2.3.2' but there is no such seb-section and from the reading of 5.2.3 I cannot figure out what this refers to.

4. Section 1 mentions a notification service that reflects a 'client/server relationship between two layered networks'. I understand that this is different from the Connectivity Fault Notification requirements defined in 8.3 and I cannot find the appropriate definition of requirements for this service further in the rest of the document.

5. Because of the interdependencies of this work with work and documents published in the IEEE 802.1 WG, ITU-T and MEF I am wondering if these SDOs have been notified and asked to review this work.

[Ballot comment]
It is interesting that this document has no normative language whatsoever but, definitely alludes to preferred choices. I found the meat of the doc to be in Section 9 where [IEEE 802.1ag] and [ITU-T Y.1731] were attempted to be elevated to the protocols of choice (though using  the word choice "can"). It was mentioned that VCCV and BFD "can" be used in the interim until [IEEE 802.1ag] and [ITU-T Y.1731] are available.

Should a document that goes into such detail and intending to recommend protocol choice be so vague as not use normative language?

[Ballot discuss]
Many of the requirements are ambiguous. For example, you say:

(R16) VPWS OAM MUST support measurement of per-service frame/packet
delay variation between two VPWS service aware devices that support
the same VPWS service instance within a given OAM domain.

Does that mean that the box offering the service should be able to measure jitter. Or that you should be able to attach a box external to the service to measure jitter? If the latter, is it really a requirement of the service?

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Shane Amante (shane@castlepoint.net) is the Document Shepherd. I have reviewed the document and it is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by the WG, during the WG Last Call, and through IETF L2VPN WG meetings. There were no concerns raised during WG Last Call.

I have no concerns about the state of readiness of this document.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

Several Vendors and a few Service Providers have contributed to and reviewed the requirements contained in this document. I have no concerns about this document, and believe it does not require further reviews from a broader perspective.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no specific concerns about this document, nor are there any concerns that should be conveyed to the IESG or the Responsible AD.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document is understood. No one objected to publishing it during the WG Last Call. It is expected that this document will guide development of OAM solutions for VPLS and VPWS.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No one has indicated to the WG Chairs or to the WG Mailing List any intention to appeal the publication of this document.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Yes. There are 4 warnings and 2 comments. The 'Intended Status' needs to be updated to Informational, Form Feeds inserted and, finally, the Normative References need to be updated to correspond to (recently) published RFC's. The authors will correct these references during the Author Review period, given by the RFC-Editor.


(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document?

Yes. There is no IANA Considerations for this document, which is reasonable given its intended purpose.


If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN)
tunnels. The requirements are intended to identify OAM requirement
for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if
L2VPN services OAM requirements impose specific requirements on PW
OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements
are also identified.


Working Group Summary
This document has been reviewed by carriers and experts in the L2VPN WG and there are no outstanding issues.


Document Quality
This memo is straightforward and well written. No issues are anticipated.


Personnel
Who is the Document Shepherd for this document?
Shane Amante (shane@castlepoint.net)

Who is the Responsible Area Director?
Mark Townsley (townsley@cisco.com)