Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review]

From: Shane Amante <[email-masked]>
Date: Sun, 09 Apr 2006 22:38:22 -0600

Ali, Dinesh, et. al,

I have reviewed the OAM reqmt's and framework doc and have a substantial 
number of comments.  In order make them more digestible, I am going to 
split up the comments into two pieces: first, the comments relating to 
the OAM requirements and, second, the comments relating to the OAM 
framework.  (Yes, that's reverse order, but I view the reqmt's as more 
significant).  Inside each half I have split the comments up to those 
that are substantial/significant in nature and those that are editorial.

Below is the review of the requirements section(s).  Based on: a) "TBD" 
section(s) (Section 9.2); b) incomplete security requirements (Section 
11); and, c) solutions inside of a reqmt's doc (Section 9), I don't 
believe it's ready for Last Call, yet.

===================================================================
SUBSTANTIATIVE:
===================================================================

Sections 6 (VPLS OAM Reqmt's) and Section 7 (VPWS OAM Reqmt's) appear to 
be identical, except for a search & replace on VPLS with VPWS.  Are 
there, in fact, differences?  If not, why are there two separate sections?

In Section 6, are these requirements relative to VPLS as a Bridged LAN 
service (4.1.1), VPLS as a Network (4.1.2) or VPLS as VLAN Emulation 
(4.1.3)?  Although the title says "VPLS Service OAM requirements", it 
might help to add a sentence/pointer back up to the top of the I-D to 
clarify that you probably mean 4.1.1.

Why is there a Section 8, "L2VPN Network OAM Requirements", and then a 
Section 8.1, "VPLS (V)LAN Emulation OAM Requirements"?  Why not just 
have a Section 8 that is "VPLS (V)LAN Emulation OAM Requirements" and 
getting rid of the "L2VPN Network OAM Requirements" ... if there's not 
going to be any VPWS Network OAM Requirements?

Section 9 prescribe solutions, with specific pointers to IEEE 802.1ag 
and Y.1731, as it relates to VPLS OAM.  That might be OK for a 
"solutions document", but solutions don't belong in requirements 
documents.  Recommend striking this whole section.

Section 9.2:
Why are VPWS OAM Operational Scenarios TBD?  This doc is in WG Last 
Call, why TBD?

Section 11, says: "Security issues resulting from this draft will be 
discussed in greater depth at a later point."  Is WG Last Call of the 
document a 'later point'?  ;-)  I'd recommend this section dumps what's 
currently in there and covers _at least_ the following: a) OAM messages 
not leaking outside OAM domains; and, b) any authentication or 
encryption reqmt's for OAM messages that may exist inside a single OAM 
domain or that cross multiple OAM domains, etc.

Appendix A1: If anything, this whole section should be moved up to 
replace of Section 9, since it discusses what appears to be OAM 
scenarios without dragging any OAM solutions into the document.  If you 
do not believe that is acceptable, either craft a new section 9 similar 
in language to Section 9 (e.g.: requirements, not solutions) or drop 
Appendix A altogether.

===================================================================
SIGNIFICANT:
===================================================================

Section 6.2.4:
---snip---
Therefore, VPLS OAM must allow alarm notification to allow suppression of
service connectivity fault notifications.
---snip---
    Change the above sentence to say like the following:
---snip---
Therefore, VPLS OAM must allow rate-limiting or suppression of service 
connectivity fault notifications.
---snip---

Section 6.2.4:
I would recommend you state that rate-limiting/suppression is a "MUST" 
and make it (R2e).  It seems to be a fundamental requirement.

Section 6.5:
Frame Delay variation opens up a can of worms with respect to one's 
interpretation of between what two points are you measuring variation? 
Specifically, is it between each packet received packet?  If so, what do 
you do for lost packets?  Or, is it for a series of packets which is 
then averaged, etc.?
---snip---
(R5) VPLS OAM MUST support measurement of per-service frame/packet
delay variation between two VPLS service aware devices that support
the same VPLS service instance within a given OAM domain.
---snip---

Section 6.6:
s/Data Path Execution/Data Path Forwarding/

Section 6.6:
Isn't the below requirement practically impossible?  I'm referring 
specifically to proprietary MPLS load-balancing hashes used on a per-hop 
basis in today's networks.  I recommend changing this to SHOULD, and 
making OAM implementations specifically MUST call-out where they will 
not be forwarded on the same path as VPLS service/data frames.
---snip---
(R6) VPLS OAM frames MUST be forwarded along the same path as the
VPLS service/data frames.
---snip---

Section 6.7:
Can you elaborate on what is the intent of this sentence?  I don't follow.
---snip---
Note: The specific numbers or range of services should align with
the [L2VPN-FRWK]
---snip---

Section 6.12, "Backward Compatibility", & Section 6.8, "Extensibility". 
  Aren't these really one and the same?  If so, shouldn't these be 
merged into one requirement?

Section 6.13:
Two things here.  First, I recommend moving Section 6.13 up to around 
the same point as Frame Loss, Frame Delay, etc., since Availability is 
one of the fundamental metrics for observing whether service is up or not.
Second, it seems very odd that the I-D has no requirement with respect 
to "availability", yet it has very precise requirements with respect to 
Frame Loss, Frame Delay, Connectivity Fault Detection, Connectivity 
Fault Verification, etc.  Why if you have all those other requirements 
to detect whether or not the service is up, or down, is there no 
requirement for availability?
---snip---
Since availability measurement may be associated with connectivity,
frame/packet loss, frame/packet delay and frame/packet delay
variation measurements, no additional requirements are specified
currently.
---snip---

Section 8.1.1:
I think a "MUST" is dangerous here, for a couple of reasons, but most 
importantly, the signaling state associated with the [rapid] shutdown 
and re-initialization of a large, full-mesh VPLS will almost certainly 
lead to a catastrophic meltdown of the network.  Recommend changing MUST 
to MAY and putting in a statement along the lines of what I just said, 
i.e.: the network operator should be aware that this could have 
detrimental effects on network performance.
---snip---
(R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the
entire mesh of PWs to be shutdown upon detection of a partial-mesh
failure condition.
---snip---

Section 8.1.1:
I recommend upgrading this MAY to MUST, since this is likely to be a 
preferred mode of operation for network operators.
---snip---
(R13c) PW OAM for PWs related to a (V)LAN emulation MAY allow the
subset of PWs to be shutdown upon detection of a partial-mesh
failure condition in a manner such that full mesh is present across
the remaining subset.
---snip---

Section 8.1.3:
Two comments.  First, you likely want to add "rate-limiting or alarm 
suppression".  Second, I believe what you're attempting to say here is 
that interworking must be supported between PWs and the native, 
service-layer OAM.  Is that correct?  If so, then perhaps cleaning up 
this sentence a bit would make that more clear.
---snip---
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support
interworking with VPLS service OAM to allow alarm suppression in the
VPLS service upon fault detection in (V)LAN emulation.
---snip---

===================================================================
EDITORIAL:
===================================================================
Section 6.2.3:
(R2c) VPLS OAM MUST allow connectivity fault localization between
two VPLS service aware devices that support the VPLS same service
instance within a given OAM domain.
    s/the VPLS same service/the same VPLS service/

Section 6.2.4:
EMS/NMS (Element Management System/Network Management System).
    Change the above to just say "NMS (Network Management System)".

Section 6.2.4:
However, a single transport/network fault may cause multiple
services to fail causing
    s/to fail causing/to fail simultaneously causing/

Section 6.3:
---snip---
A VPLS service may be considered degraded if it is sensitive to
service frames/packets loss during transit between the VPLS service
aware devices.
---snip---
    I'd recommend changing the above to be:
---snip---
A VPLS service may be considered degrade if service-layer frames/packets 
are lost during transit between VPLS service-aware devices.
---snip---

Section 6.7:
---snip---
though the OAM may only be used for
limited VPLS services e.g. premium services and may not be used for
best effort services.
---snip---
   I'd recommend changing the above to be:
---snip---
though the OAM may only be used for limited VPLS service instances, for 
example premium VPLS service instances, and may not be used for 
best-effort VPLS services.
---snip---

Section 6.8:
---snip---
Extensibility is intended to allow introduction of additional
functionality in future such that backward compatibility can be
maintained i.e. when working with older version devices, VPLS OAM
with reduced functionality is still possible.
---snip---
   I'd recommend changing the above to be:
---snip---
Extensibility is intended to allow introduction of additional OAM 
functionality in the future such that backward compatibility can be 
maintained when interoperating with older devices.  In such a case, VPLS 
OAM with reduced functionality should still be possible.
---snip---

Section 6.10:
---snip---
(R10b) VPLS OAM MAY allow adaptation/interworking with specific
transport/network OAM functions. For example, this would be useful
to allow Fault Notifications from transport/network layer(s) to be
sent to VPLS service layer.
---snip---
    s/sent to VPLS service layer/sent to the VPLS service layer/

Section 8.1.1:
---snip---
Therefore, when partial-mesh failure occurs in (V)LAN
emulation, either the entire PW mesh should be shutdown when only an
entire VPLS service is acceptable or a subset of PW with full PW
mesh should be realized when partial VPLS service is acceptable.
---snip---
   s/or a subset of PW with full PW mesh should be realized/or a subset 
of PWs should be shutdown when a partial-mesh VPLS service is acceptable/

Section 8.1.3:
---snip---
When connectivity fault is detected in (V)LAN emulation, PE devices
may notify the EMS/NMS (Element Management System/Network Management
System).
---snip---
    s/EMS\/NMS (Element Management System\/Network Management 
System)/NMS (Network Management System)/
    Make sure to do the same in the next sentence.

-shane

Shane Amante wrote:
> The authors of draft-ietf-l2vpn-oam-req-frmk-05, have requested a L2VPN 
> WG Last Call for this I-D, "L2VPN OAM Requirements and Framework".  It 
> can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-05.txt
> 
> Please thoroughly review the document and send any comments to the list. 
>  Also, please indicate whether you believe this document is ready to go 
> to the IESG "as is", or whether there should be a cleaner separation 
> between the requirements and framework.  In the latter case, the I-D 
> would not pass LC, would need to get re-drafted for WG comments and the 
> separate components sent out for WG Last Call again.
> 
> The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7).
> 
> -shane
>

---

From: Shane Amante <[email-masked]>
Date: Sun, 09 Apr 2006 22:41:12 -0600

Ali, Dinesh, et. al,

As stated in an earlier e-mail, below are the comments relating to the 
Framework section(s).

Section 1:
I understand the intent to have a comprehensive set of OAM reqmt's, but 
I'm not sure why the L2VPN WG specifically needs to take on the breadth 
of what this statement suggests, specifically "a reference model for OAM 
layering and furthermore emphasizes the importance of proper independent 
layering in design and development of OAM functionality across ..." 
Wouldn't proper OAM layering be a topic more suitable for the Ops Area?
---snip---
This document provides a description and a reference model for OAM
layering and furthermore emphasizes the importance of proper
independent layering in design and development of OAM functionality
across L2VPN services, Pseudo Wires (PWs) and Public Switched
Network (PSN) tunnels.
---snip---

Section 3.3 (MEPs and MIPs)
It would be *extremely* useful to address this comment, as it relates to 
"Scalability" of VPLS OAM, in Sections 6 (& 7).  Specifically, in a mp2p 
environment like VPLS, it would be useful to assert some guidelines as 
it relates to the number of ME's per service instance per PE, 
(particularly for the "sink PE" that is a receiver of n(n-1)/2 ME messages).
---snip---
A ME is a point-to-point association between a pair of MEPs and 
represents a monitored entity. For example, in a VPLS service which 
involves n CEs, all the MEs associated with the VPLS service in the 
customer OAM domain (i.e. from CE to CE) can be considered to be part
of a VPLS MEG, where the n-point MEG consists of a maximum of n(n-1)/2
MEs.
---snip---

Section 4.1.1 (VPLS as Bridged LAN Service) thru 4.1.3 (VPLS as (V)LAN 
Emulation):
I'm not sure I'm comfortable with these sections.  Specifically, I think 
what you're describing in Section 4.1.1 is VPLS operates as a peer-layer 
to the native (Ethernet) service-layer.  In Section 4.1.2, I think you 
are attempting to describe VPLS as a peer-layer as well as a 
client-layer to an underlying MPLS or IP substrate.  Finally, I think in 
Section 4.1.3, you're finally up to VPLS as a service-layer in its own 
right.  Is that correct?
    If so, then I think we need to be careful in Sections 4.1.1 and 
4.1.2 when referring the native Ethernet service-layer (particularly in 
the context of the access-layer networks), that this is out-of-scope for 
this work product (and the IETF).
    In addition, in Section 4.1.2, there's a vague statement with 
respect to OAM mechanisms at the "network level".  The way the current 
sentence is phrased, I believe you are saying that network-layer OAM 
mechanisms are required; however, it's not in our charter to solve 
MPLS-layer OAM. (Note, to be fair, you do say in Section 4.2.1 that OAM 
at the transport-layer is out-of-scope of this doc, but perhaps 
copying/moving that statement up to here would be useful)?
---snip---
To check the network
integrity regardless of the network topology, network level OAM
mechanisms are needed for the VPLS networks.
---snip---
    Related to the last comment, the words "network level" is IMO vague. 
  Perhaps it would be better to state that it refers to network-layer 
protocols such as MPLS, GRE/IP or L2TPv3?

Section 4.2.2:
It doesn't look like the lines in the diagram in Figure 4, for A, B & C 
are properly aligned.  You should fix them.

Section 4.2.3:
Again, it doesn't look like the diagram in Figure 5 is properly aligned 
with the scenarios depicted in A, B & C.

Section 4.2.3:
In general, this section says that it is 'expected' that MEPs and MIPs 
will be implemented into various components of the VPLS architecture, 
(VPLS forwarder/briding modules).  Are you discussing the OAM framework 
here, or do these 'expected' details surrounding an eventual 
implementation which would mean these would translate into MUSTs or 
SHOULDs in the reqmt's sections?  (I'm trying to seek clarity of what 
you're intent is with these statements, because I don't see anything 
related to MEPs and MIPs in the reqmt's section).

Section 4.2.3:
(D) depicts both MEPs and MIPs, however this sentence only discusses 
expectations around MEPs ... what about the MIPs in Scenario (D)?
---snip---
(D) represents the MEPs and MIPs
visible within the service provider domain. These MEPs are expected
to be implemented in the bridge module/VPLS forwarder of a PE
device, as per the [L2VPN-FRWK].
---snip---

Section 4.2.3:
In which components of the VPLS architecture do you expect the MEPs and 
MIPs in (E) to be implemented?

Section 4.2.4:
What about VPLS-BGP?  What identifiers are used for it, since it doesn't 
use PW-id's?

Section 4.2.4:
---snip---
Both PW-ids and VLAN tags for a given VPLS
instance are associated with a Service Identifier (e.g., VPN
identifier).
---snip---
Which identifier do you have in mind, i.e.: VPLS-ID in l2vpn-signaling?

Section 5:
Diagrams aren't aligned Figure 6, VPWS Reference Model.

Section 5.2:
What are you trying to say here?
---snip---
In common scenarios, it could or simply a point-to-point interface of
certain type.  The core network connecting PEs can be IP, MPLS, etc.
---snip---

Section 5.2:
To which network types are you referring?  Can you somehow reference 
back to the heterogenous & homogeneous terminology introduced in the 
aforementioned section?
---snip---
Therefore, it is important that the OAM mechanisms can be applied to
all these network types.
---snip---

Section 5.2.1:
Diagrams in Figure 7 are not aligned properly, and I believe you're 
missing a > describing the right-most end-point in the diagram.

Section 5.2.2:
Diagrams in Figure 8a & 8b are not aligned properly, and I believe 
you're missing a > describing the right-most end-point in the diagram.

Section 5.2.2:
---snip---
"The service provider is responsible to monitor the PW ME"
"... the monitoring requirements across the AC ME are minimal."
---snip---
What is the "PW ME" and "AC ME"?  The term "ME" hasn't been defined as 
it related specifically to PW's or AC's.  Furthermore, does ME refer to 
the NSP, or some other function/layer of VPWS?

Section 5.2.2:
---snip---
The
distinction between Figure 8b (C) and (D) is that (C) MEs have MEPs
at CE and PEs and have no MIPs while (D) MEs have MEPs at CEs and
PEs and likely MIPs in between, thereby having a visibility to
Operator network.
---snip---
    Can you clarify this part of the sentence: "(C) MEs have MEPs
at CE and PEs and have no MIPs" ... specifically, it's not clear at all 
(e.g.: to which devices or components of VPWS) where MEPs and MIPs are 
applicable.
    Can you also clarify the second half of that sentence "(D) MEs have 
MEPs at CEs and PEs and likely MIPs in between, thereby having a 
visibility to Operator network." ... again, it's not clear where (e.g.: 
to which devices or components of VPWS) MEPs are MIPs are applicable.  I 
think it's just the way you're phrasing it, so perhaps re-phrasing in a 
better way would be good.

Section 5.2.3:
Which option are you referring to?
---snip---
The advantage of this option is that end-to-end and segment OAM can
be carried out in an independent manner.
---snip---

Section 5.2.3:
Suggest putting this paragraph before the diagram and changing the intro 
to s/Though, different possible OAM layers have been shown/Although many 
different OAM layers are possible, as shown in Figure 9,/.
---snip---
Though, different possible OAM layers have been shown in the Figure
9, not all may be realized. For example, Figure (B2) and (D) may be
adequate in some cases.
---snip---

===================================================================
EDITORIAL:
===================================================================
1.1) Formatting needs to be fixed/aligned
2) Formatting needs to be fixed/aligned
2) "CEs that are member of the same service instance communicate with 
each other as if they are connected via a bridged LAN."
    s/member/members/
4.1.1) "... and it provides a virtual LAN service to the attach CEs 
belonging to that service instance."
    s/attach CEs/attached CEs/
4.1.1) "The reason it is called bridged LAN service is because the
VPLS-capable PE provide this end-to-end virtual LAN service
performing bridging functions (either full or a subset) as described
in the [L2VPN-FRWK]."
    s/provide/providing/
    s/performing/is performing/
4.1.3. "Since the emulated LAN segment is presented as a Virtual
LAN (VLAN) to the bridge module of a VPLS-capable PE, emulated
segment is also referred to as an emulated VLAN."
    s/VPLS-capable PE, emulated/VPLS-capable PE, the emulated/
4.2.4:
---snip---
As described in [VPLS-LDP], VPLS instance can be identified in an 
Ethernet domain (e.g., 8021.d domain) using VLAN tag
---snip---
    s/VPLS instance/a VPLS instance/
    s/8021.d/802.1d/
4.2.4:
"For Ethernet services e.g. VPLS,"
    s/e.g. VPLS,/, e.g. VPLS,/
Section 4.2.4:
---snip---
MEPs and MIPs Identifiers, i.e. MEP Ids and MIP Ids
must be unique within their corresponding Service Identifiers within
the OAM domains.
---snip---
    s/, i.e. MEP Ids and MIP Ids must/, i.e. MEP Ids and MIP Ids,
must/
Section 5.1:
---snip---
. VPWS with homogeneous ACs (where both ACs are same type)
. VPWS with heterogeneous ACs (where the ACs are of different
   types)
---snip---
    s/type/Layer-2 encapsulation/
5.2:
---snip---
As an example, the access network between CE and PE on
one side can be Ethernet bridged network, ATM network, etc.
---snip---
    s/be Ethernet bridged network/be an Ethernet bridged/
Section 5.2.1:
---snip---
Service provider network can be considered to be
segmented into core network and two types of access network.
---snip---
    s/Service provider network/A service provider network/
    s/into core network/into a core network/
Section 5.2.1:
---snip---
In most general case, a PE can be client service aware when it
processes client service PDUs and is responsible for encapsulating
---snip---
    s/In most general case/In the most general case/
Section 5.2.1:
---snip----
... is responsible for encapsulating
and de-encapsulating client service PDUs onto PW and ACs.
---snip---
    s/onto PW and ACs/onto a PW and ACs/
Section 5.2.2
---snip---
PEs of a given operator and could
also be present in access if the access is
---snip---
    s/present in access/present in the access network/
    s/if the access/if the ACs are/
Section 5.2.2:
"by the customer and customer"
    s/and customer/and the customer/
Section 5.2.2:
"The service provider is responsible to monitor the PW ME"
    s/responsible to monitor/responsible for monitoring/
Section 5.2.2:
"responsibility shared between the customer and service provider"
    Change this whole quote to be:
"the shared responsibility of the customer and the service provider"
Section 5.2.2:
---snip---
Figure 8b highlights another management model, where the CEs are
managed by the Service Provider and where CEs and PEs are connected
via access network.
---snip---
    s/via access network/via an access network/
Section 5.2.3:
---snip---
to specific responsibilities within the network.
---snip---
    s/specific responsibilities/specific areas/
Section 5.2.3:
---snip---
The CE interfaces support MEPs at end-to-end Service Provider OAM
level for VPWS end-to-end service as shown in Figure 9 (B1) and
(B2).
---snip---
    s/MEPs at end-to-end Service Provider/MEPs at the end-to-end Service 
Provider/
    s/VPWS end-to-end service/VPWS as an end-to-end service/
Section 5.2.3:
---snip---
Service Provider OAM level when PEs are client service aware, shown
in Figure 9 (B2).  As an example, if one considers an enc-to-end
Ethernet line service offered to subscriber between between CE1 and CE2
which is realized via ATM type AC1 and AC2 and PW which encapsulates
ATM over MPSL, the PEs can be considered as Ethernet service
unaware,
---snip---
    s/, shown in Figure 9 (B2)/, as shown in Figure 9 (B2)/
    s/enc-to-end/end-to-end/
    s/offered to subscriber between/offered to a subscriber/
    s/MPSL/MPLS/
Section 5.2.4:
---snip---
In VPWS, the MEPs and MIPs should be identified with their native
addressing schemes. MEPs and MIPs Identifiers, i.e. MEP Ids and MIP
Ids must be unique within their corresponding OAM domains and must
also be unique to the VPWS service instance.
---snip---
    s/i.e. MEP Ids and MIP Ids must/i.e. MEP IDs and MIP IDs, must/

-shane