From l2vpn-bounces@ietf.org Mon Apr 10 00:38:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoAa-0001Wp-5i; Mon, 10 Apr 2006 00:38:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoAY-0001Wk-Vw for l2vpn@ietf.org; Mon, 10 Apr 2006 00:38:30 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSoAY-0006H2-Bf for l2vpn@ietf.org; Mon, 10 Apr 2006 00:38:30 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 7A5496444B for ; Sun, 9 Apr 2006 22:38:21 -0600 (MDT) Message-ID: <4439E13E.6070801@castlepoint.net> Date: Sun, 09 Apr 2006 22:38:22 -0600 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org References: <441DE92E.6050507@castlepoint.net> In-Reply-To: <441DE92E.6050507@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Requirements Review] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org 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 l2vpn-bounces@ietf.org Mon Apr 10 00:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoDJ-00020A-R7; Mon, 10 Apr 2006 00:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSoDH-000205-Vf for l2vpn@ietf.org; Mon, 10 Apr 2006 00:41:19 -0400 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSoDH-0006KZ-A0 for l2vpn@ietf.org; Mon, 10 Apr 2006 00:41:19 -0400 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 490226444B for ; Sun, 9 Apr 2006 22:41:10 -0600 (MDT) Message-ID: <4439E1E8.4010901@castlepoint.net> Date: Sun, 09 Apr 2006 22:41:12 -0600 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org References: <441DE92E.6050507@castlepoint.net> In-Reply-To: <441DE92E.6050507@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Subject: Re: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 [Framework Review] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Ali, Dinesh, et. al, As stated in an earlier e-mail, below are the comments relating to the Framework section(s). =================================================================== SUBSTANTIATIVE: =================================================================== 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 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 l2vpn-bounces@ietf.org Mon Apr 10 07:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuC7-00047U-LL; Mon, 10 Apr 2006 07:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSuC6-00047P-1R for l2vpn@ietf.org; Mon, 10 Apr 2006 07:04:30 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSuC4-0003lF-MR for l2vpn@ietf.org; Mon, 10 Apr 2006 07:04:30 -0400 Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3AB29Qm008276 for ; Mon, 10 Apr 2006 07:02:10 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.8/Switch-3.1.0) with ESMTP id k3AB1GBb029021 for ; Mon, 10 Apr 2006 07:01:17 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Apr 2006 14:04:26 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 Thread-Index: AcZLrPc7K6RlV9NoRqexrQ6vxPhxLwQ4KSUg From: "Romascanu, Dan \(Dan\)" To: "Shane Amante" , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: RE: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org I have a basic question to which I did not find an answer in the document.=20 The document refers 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 there is any intention to use the work in IPPM (RFC 2679, 2680, 3393) or will these metrics be defined separately per service, plus maybe specific OAM methodology per type of service?=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Monday, March 20, 2006 1:29 AM > To: l2vpn@ietf.org > Subject: WG Last Call: draft-ietf-l2vpn-oam-req-frmk-05 >=20 > The authors of draft-ietf-l2vpn-oam-req-frmk-05, have=20 > requested a L2VPN WG Last Call for this I-D, "L2VPN OAM=20 > Requirements and Framework". It can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-f > rmk-05.txt >=20 > Please thoroughly review the document and send any comments=20 > to the list.=20 > Also, please indicate whether you believe this document is=20 > ready to go to the IESG "as is", or whether there should be a=20 > cleaner separation between the requirements and framework. =20 > In the latter case, the I-D would not pass LC, would need to=20 > get re-drafted for WG comments and the separate components=20 > sent out for WG Last Call again. >=20 > The WG Last Call will end on 10 Apr 2006 at 1700 MST (UTC/GMT -7). >=20 > -shane >=20 >=20