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

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 10 May 2006 15:39:16 -0400

Shane,

Thank you for your careful review. While we have addressed the comments
in details (see below), we still feel that you could have provided some
of these comments along with other comments you have been providing
during the review process for last couple of years now. 

As you would notice, we propose to incorporate some of them in the next
update. These have also been reviewed by some of the other contributors.

The responses are marked as [DM-AS]/[DM-AS]

Regards,
Dinesh & Ali
-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Monday, April 10, 2006 12:38 AM
To: [email-masked]
Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05
[Requirements Review]

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?

[DM-AS] 
The requirements for VPLS and VPWS are not entirely identical,
especially not a search and replace on VPLS with VPWS. There are some
distinct requirements called out and distinct description applicable to
VPLS and/or VPWS. However, the question, IMO, should not be whether
these requirements are identical or not, but whether they are complete
or not for VPLS and VPWS.

Please note, that we decided to keep the requirements separate since the
two services are distinct and the OAM requirements can diverge, as an
example see in Section 6.2.1 and 7.2.1. /[DM-AS]

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.

[DM-AS]
You are correct. We will add a statement in Section 6: "These
requirements are applicable to VPLS as a Bridged LAN service, as
described in Section 4.1.1." /[DM-AS]

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?

[DM-AS]
Yeah, we could rearrange Section 8 as you suggest and we will do it. In
future, if we do end up identifying network requirements for VPWS, we
can always create a new section. /[DM-AS]

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.

[DM-AS]
First of all, Section 9 is marked as "OAM Operational Scenarios" and not
requirements. If there would have been references to solutions (.1ag,
Y.1731, VCCV, BFD) in Sections 6 or 7, which are marked specifically as
"Requirements", it would not have been appropriate.

As a framework document, there had been a desire expressed in our
discussions to provide some guidance around abstract architectural
elements. As a result, Section 9 was created which does not mandate any
specific solution and indicates how different solutions including BFD,
VCCV, .1ag etc can be applied as an example operational scenario.
/[DM-AS]

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

[DM-AS]
Fair point. We will remove this section and a new section can be added
in future. /[DM-AS]

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.

[DM-AS]
Good comment. We will update the security section in the next version.
/[DM-AS]

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.

[DM-AS]
Also see disposition to your comment regarding Section 9. Please note
that Appendix A was specifically added based on our discussions and
agreements to reflect some interim framework guidance, as you had
requested. If you are interested, we could drop Appendix A? /[DM-AS]

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

[DM-AS]
We will change the statement to: "Therefore, VPLS OAM must allow alarm
notification to allow suppression of service connectivity faults
notifications." /[DM-AS]

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.

[DM-AS]
The previous comment should address this since rate limiting is not
specific to fault notifications. /[DM-AS]

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

[DM-AS]
As also pointed out by Dan Romascanu's comment, we plan to add a note to
the document pointing to some existing definitions (e.g. MEF, IPPM,
etc.) for the performance metrics which seems to be what you are also
seeking. /[DM-AS]

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

[DM-AS]
Accept.
/[DM-AS]

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

[DM-AS]
In the presence of ECMP the load balancing is done on a PW basis, and
each PW belongs to a given VPLS instance, the OAM frames will travel the
same path (i.e. links and nodes) as the data frames. 

Given this requirement is specifically for VPLS which is bridged LAN
service, the requriment still remains. We can clarify the requirement
as:
"(R6) VPLS OAM frames MUST be forwarded along the same path (i.e. links
and nodes) as the VPLS service/data frames." 
/[DM-AS]

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

[DM-AS]
We intended to associate the number of service OAM instances supported
to the number of service instances supported as per the L2VPN
Requirements. We will update the reference from L2VPN-FRMK to L2VPN-REQ,
and also update the text a little bit more to convey the intent.
/[DM-AS]

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?

[DM-AS]
These are not the same however going thorugh the text in Section 6.8 and
6.12, we can see the potential for confusion. We will merge the two
sections and clarify the text. /[DM-AS]

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

[DM-AS]
We will move the Availability requirement up. Wrt your comment on the
need for putting a specific requirement against Availability, if the
definition is built out from connectivity, FL, FD and FDV, then the OAM
protocol does not need any specific mechanism for Availability. We could
clarify this and also provide reference to some existing definitions of
Availability. /[DM-AS]

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

[DM-AS]
Shutting down does not mean that the labels etc are withdrawn. Maybe we
could make a specific statement around this point. Further, we are
indicating that it must ALLOW for shutdown because there is other
requirement R13c that indicates a partial mesh can be allowed if the
remaining subset can be considered as full mesh. /[DM-AS]

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

[DM-AS]
OK, will change this. /[DM-AS]

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

[DM-AS]
We think that the requirement says what you are indicating above as your
understanding. If not, please suggest the modified text that you would
like to see. /[DM-AS]

===================================================================
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/

[DM-AS]
OK, will change this. /[DM-AS]

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

[DM-AS]
OK, will change this. /[DM-AS]

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/

[DM-AS]
OK, will change this. /[DM-AS]

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

[DM-AS]
OK, will change this with "degrade" changed to "degraded" in your
proposed text /[DM-AS]

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

[DM-AS]
OK, will change this. /[DM-AS]

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

[DM-AS]
OK, will change this. /[DM-AS]

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/

[DM-AS]
OK, will change this. /[DM-AS]

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/

[DM-AS]
s/or a subset of PW with full PW mesh should be realized/or a subset of
PWs should be shutdown such that the remaining PWs have full
connectivity among them/ /[DM-AS]

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.

[DM-AS]
OK, will change this. /[DM-AS]

-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, 28 May 2006 22:38:26 -0600

Dinesh, Ali,

Comments in-line below.

> believe it's ready for Last Call, yet.

OK, so the two sections are nearly 98% identical in terms of content?

When using diff, the significant majority of differences are due to  
formatting (extra spaces, carriage returns, etc.).  The only content  
differences I had noticed were as follows:
- As you previously noted, Section 7.2.1 (Connectivity Fault  
Detection), adds one reqm't (R14b).
- Addition of one reqm't (R14f) to Section 7.2.4 (Connectivity Fault  
Alarm)
- Addition of one reqm't (R18b) to Section 7.6 (Data Path Execution)
- Addition of Section 7.13 (Prioritization) to the VPWS section.

The goal of pointing this out is it would be much easier for readers  
of the I-D if there was one common section covering both VPLS & VPWS  
reqmt's and only the above differences were called out in a separate  
section as needed.  However, since no one else seems to have  
significant concerns over this, I'm fine leaving it "as is".

> described in Section 4.1.1." /[DM-AS]

OK.

> can always create a new section. /[DM-AS]

OK, sounds good.

> VCCV, .1ag etc can be applied as an example operational scenario.

The substantial part of the first half of this document (up to  
Section 6) is all about "OAM Framework".  What's disconcerting is to  
read through this I-D and read the following: framework (Sections 1 -  
5), reqmt's (Sections 6 - 8) and then, finally, switch briefly back  
into framework again (Section 9).  At a minimum, it would be ideal to  
consolidate the framework bits all into the first part of the  
document, (at a minimum move Section 9 up before Section 6).  At  
least this way Section 9 is adjacent with the rest of the framework.

However, I see you mixed in a small handful of references to Section  
6 (VPLS Service OAM reqmt's) into the current Section 9.  Thus, I'm  
assuming you might be concerned over forward references if Section 9  
moved up ahead of Section 6?  Personally, I think the forward  
references would be a small concern relative to consolidating the  
framework together in one portion of the document to provide a more  
comprehensive & consolidated picture of the OAM framework.

Ultimately, while I still have significant concerns relative to the  
content of Section 9, in the absence of any public opinion that it  
does not belong in this I-D that must mean everyone thinks the  
content is OK "as is".  That said, I still want you to consider  
consolidating it with the rest of the framework.

> Fair point. We will remove this section and a new section can be added

OK.

> Good comment. We will update the security section in the next version.

OK.

> requested. If you are interested, we could drop Appendix A? /[DM-AS]

IMO, there is much, much more value in Appendix A1 which defines "OAM  
Operational Scenarios" (framework) in a much more general sense than  
Section 9 and without any reference to other standards.  Appendix A1  
even succeeds at outlining the (strengths and) weaknesses related to  
each of the Alternate Models, (as compared to a full-blown  
hierarchical OAM layering model).  IMO, this general style ought to  
have been the same principle used in Section 9.  However, since I've  
not been able to convince you of this and no one else has expressed  
similar concerns, it's OK to leave Appendix A1 in "as-is" since there  
is value in these Alternate Models, because they are likely the first  
to be deployed.

Your suggested change appears confusing.  Why are you opposed to the  
original suggested change?  I thought that by using the term "rate- 
limiting" it could be interpreted as anything from 0 to X over some  
time period.  Thus, if someone wanted complete "suppression" they  
could set a rate-limiter to 0, which is equivalent to full suppression.

> specific to fault notifications. /[DM-AS]

Please see my previous comment.  I still think this is necessary,  
since operators may not want to completely suppress all alarms, but  
in some cases have them rate-limited.  Again, a rate-limiter can be  
set to 0 for those who desire complete suppression.

> etc.) for the performance metrics which seems to be what you are also

OK.

> and nodes) as the VPLS service/data frames."

I wasn't referring to ECMP, but rather load-balancing of a given PW  
"flow" across multiple links in a single link-bundle between two  
adjacent devices.  Typically, implementations take some number of  
MPLS labels for a given MPLS datagram, then calculate a hash which  
determines the individual link a PW "flow" will be forwarded on.   
Since these hash algorithms are proprietary to every vendor, there is  
no standard.  The bottom-line is you can't guarantee the behavior of  
the network wrt forwarding of datagrams in the presence of this type  
of load-balancing, (because it depends on what is consumed as input  
to the load-balancing hash).  While I agree that this type of load- 
balancing could cause problems relative to associating a given OAM  
fault with a particular PW used by a VPLS service, it is a fact of  
life in today's networks and will likely be around for the  
foreseeable future.

One way to address this concern is to make R6 a "SHOULD" (and not a  
"MUST").  Then, add a second paragraph to Section 6.6, before the  
requirement, that says something like the following:
---snip---
Load-balancing of PW's between two adjacent devices in a link-bundle  
may result in VPLS OAM frames not fate-sharing with the VPLS data- 
plane traffic.  Operators concerned with this incongruity between OAM  
and data-plane traffic may design their network to avoid these  
scenarios.
---snip---

> and also update the text a little bit more to convey the intent.

OK.

> sections and clarify the text. /[DM-AS]

OK.

> clarify this and also provide reference to some existing  

OK, please move Availability up.

Related to the second point, what reference to an existing definition  
of Availability are you considering pointing at?

> Shutting down does not mean that the labels etc are withdrawn.

Why would the labels not be withdrawn?

> Maybe we
> could make a specific statement around this point.

This might help, but I still need to see what your thinking wrt the  
previous question.

> Further, we are

Perhaps the way I should consider this is to reverse the order of  
these two reqmt's?  IOW, an implementation is likely to consider R13c  
first and, if that reqm't can't be met, only then do R13b.  Is that  
your thinking?

Aside from that, I'm still concerned with the potential for a  
catastrophic meltdown due to the tear-down of several PW's triggered  
by an OAM fault condition.  One way to address this concern wrt R13b  
is to suggest a pacing of PW teardown, label withdraw messages, PW re- 
initialization, etc. to avoid killing the network.  I won't push this  
point to wait to see how you're going to address the first question  
as to why labels won't be withdrawn and how that is supposed to help  
alleviate the potential for pathological churn on the network.

> OK, will change this. /[DM-AS]

Before changing this, let's agree to the course of action on R13b above.

> understanding. If not, please suggest the modified text that you would

OK, try this text:
---snip---
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support
interworking with native service-layer OAM to allow alarm suppression
in the VPLS service-layer upon fault detection in the native service
layer, or vice-versa.
---snip---

[--snipped to end--]

All of the rest of the editorial changes look good.

-shane