From internet-drafts@ietf.org Wed Jan 2 04:17:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45021F90BF; Wed, 2 Jan 2013 04:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbYx2q9N+imG; Wed, 2 Jan 2013 04:17:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C4921F9099; Wed, 2 Jan 2013 04:17:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130102121712.13238.12648.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 04:17:12 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 12:17:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Interface Stack Capability MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-00.txt Pages : 15 Date : 2012-12-25 Abstract: This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines a set of objects, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. This document obsoletes RFC 5066. It amends that specification by moving the entire EFM-CU- MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bclaise@cisco.com Wed Jan 2 05:37:36 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126621F8CB2 for ; Wed, 2 Jan 2013 05:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.404 X-Spam-Level: X-Spam-Status: No, score=-10.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTSzET3ro8QT for ; Wed, 2 Jan 2013 05:37:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF621F8CB6 for ; Wed, 2 Jan 2013 05:37:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02DbS6c018172; Wed, 2 Jan 2013 14:37:29 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02DbSc8013147; Wed, 2 Jan 2013 14:37:28 +0100 (CET) Message-ID: <50E43817.1010407@cisco.com> Date: Wed, 02 Jan 2013 14:37:27 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20130102121712.13238.12648.idtracker@ietfa.amsl.com> In-Reply-To: <20130102121712.13238.12648.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130102121712.13238.12648.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000101050809090408070809" Cc: Edward Beili , Howard Frazier Subject: [OPSAWG] Fwd: I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 13:37:36 -0000 This is a multi-part message in MIME format. --------------000101050809090408070809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is some background information on this document, mainly taken from the IETF-IEEE coordination call meeting minutes (http://www.ietf.org/iesg/ieee/20121029/coordination.txt). 7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3 7.1. Description In the transition process between the IETF and the IEEE the following documents were taken over by IEEE 802.3: RFC 2108 - Ethernet Repeater Devices RFC 3621 - Power Ethernet MIB RFC 3635 - Ethernet-like Interface Types RFC 3637 - Ethernet WAN Interface Sublayer RFC 4836 - Ethernet Medium Attachment Units (MAUs) RFC 4837 - Ethernet Passive Optical Networks (EPON) RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to continue to be maintained by the IETF in a separate new document The IEEE 802.3 proposed to create an RFC that documents the issues related to the transition of the Ethernet MIB work to IEEE 802.3 similar to RFC 4663 which documents the transition of the Bridge MIB work to IEEE 802.1 - The OPSAWG was rechartered in October 2012 to include the two relevant documents 7.2. Relevant Documents - IEEE 802.3.1 Draft - http://datatracker.ietf.org/wg/opsawg/charter/ - TBD OPSAWG I-Ds 7.3. Owners - Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3) 7.4. Action Items - Dan Romascanu will enter the Sponsor Ballot pool and enter a comment suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB from their document and refer the IF-CAP-STACK-MIB instead. - Ed Beili will write an I-D targeting standards track that obsoletes RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording emphasizing the generic nature of this module - Ed Beili will write an I-D targeting informational RFC, similar to RFC 4663, with: a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 b) A table mapping the old IETF MIB names with the corresponding new IEEE ones c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, reviews d) Clarifications on the intellectual property considerations The first version will be posted by Ed. Then Dan Romascanu and Howard Frazier will add IETF-IEEE interactions chapter. - Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB document, to explain the situation Regards, Benoit -------- Original Message -------- Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt Date: Wed, 02 Jan 2013 04:17:12 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: opsawg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Interface Stack Capability MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-00.txt Pages : 15 Date : 2012-12-25 Abstract: This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines a set of objects, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. This document obsoletes RFC 5066. It amends that specification by moving the entire EFM-CU- MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --------------000101050809090408070809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is some background information on this document, mainly taken from the IETF-IEEE coordination call meeting minutes (http://www.ietf.org/iesg/ieee/20121029/coordination.txt).

7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3
7.1. Description
In the transition process between the IETF and the IEEE the following 
documents were taken over by IEEE 802.3: 
RFC 2108 - Ethernet Repeater Devices
RFC 3621 - Power Ethernet MIB
RFC 3635 - Ethernet-like Interface Types
RFC 3637 - Ethernet WAN Interface Sublayer
RFC 4836 - Ethernet Medium Attachment Units (MAUs)
RFC 4837 - Ethernet Passive Optical Networks (EPON)
RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions 
on Ethernet-Like Interfaces
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to 
continue to be maintained by the IETF in a separate new document
The IEEE 802.3 proposed to create an RFC that documents the issues 
related to the transition of the Ethernet MIB work to IEEE 802.3 similar 
to RFC 4663 which documents the transition of the Bridge MIB work to 
IEEE 802.1 
- The OPSAWG was rechartered in October 2012 to include the two relevant 
documents 

7.2. Relevant Documents
- IEEE 802.3.1 Draft
- http://datatracker.ietf.org/wg/opsawg/charter/ 
- TBD OPSAWG I-Ds

7.3. Owners 
- Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3)

7.4. Action Items
- Dan Romascanu will enter the Sponsor Ballot pool and enter a comment 
suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB 
from their document and refer the IF-CAP-STACK-MIB instead. 
- Ed Beili will write an I-D targeting standards track that obsoletes 
RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording 
emphasizing the generic nature of this module
- Ed Beili will write an I-D targeting informational RFC, similar to RFC 
4663, with:
a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011
b) A table mapping the old IETF MIB names with the corresponding new 
IEEE ones
c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, 
reviews
d) Clarifications on the intellectual property considerations
The first version will be posted by Ed. Then Dan Romascanu and Howard 
Frazier will add IETF-IEEE interactions chapter.
- Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB 
document, to explain the situation

Regards, Benoit
-------- Original Message --------
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt
Date: Wed, 02 Jan 2013 04:17:12 -0800
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: opsawg@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.

	Title           : Interface Stack Capability MIB
	Author(s)       : Edward Beili
	Filename        : draft-ietf-opsawg-rfc5066bis-00.txt
	Pages           : 15
	Date            : 2012-12-25

Abstract:
   This document defines Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.
   This document defines a set of objects, describing cross-connect
   capability of a managed device with multi-layer (stacked) interfaces,
   extending the stack management objects in the Interfaces Group MIB
   and the Inverted Stack Table MIB modules.  This document obsoletes
   RFC 5066.  It amends that specification by moving the entire EFM-CU-
   MIB module along with the relevant descriptive text, to a separate
   document, maintained by the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3.1 working group.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


--------------000101050809090408070809-- From bclaise@cisco.com Wed Jan 2 06:14:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7E321F8455 for ; Wed, 2 Jan 2013 06:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.408 X-Spam-Level: X-Spam-Status: No, score=-10.408 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AabfyIr0s0cm for ; Wed, 2 Jan 2013 06:14:21 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA1721F8450 for ; Wed, 2 Jan 2013 06:14:21 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02EEJ7P022037; Wed, 2 Jan 2013 15:14:19 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02EEI42011183; Wed, 2 Jan 2013 15:14:18 +0100 (CET) Message-ID: <50E440BA.1010208@cisco.com> Date: Wed, 02 Jan 2013 15:14:18 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Edward Beili Content-Type: multipart/alternative; boundary="------------050100060105000308010009" Cc: "opsawg@ietf.org" Subject: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:14:22 -0000 This is a multi-part message in MIME format. --------------050100060105000308010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 166 } NEW_ _ -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 XXXX } _ _Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." _ Editorial_ 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor) --------------050100060105000308010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ed,

Here is my draft-ietf-opsawg-rfc5066bis-00.txt review


1.
OLD
  -- EdNote: Replace XXXX with the actual RFC number &
   -- remove this note

       ::= { mib-2 166 }
NEW

  -- EdNote: Replace XXXX with the actual RFC number &
   -- remove this note

       ::= { mib-2 XXXX }

Consequently, the IANA considerations section need to be changed/
7.  IANA Considerations

   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been
   allocated by IANA in the MIB-2 sub-tree.
2.
I don't believe that you need the following REVISION
       REVISION    "200711070000Z"  -- November 07, 2007
       DESCRIPTION "Initial version, published as RFC 5066."

Editorial
1.
OLD
Abstract

   This document defines Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.
NEW
Abstract

   This document defines a Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.
2.
OLD
   In addition the Security Considerations section was updated to
  

NEW
   In addition, the Security Considerations section was updated to



Regards, Benoit (as a contributor)
--------------050100060105000308010009-- From bclaise@cisco.com Wed Jan 2 09:10:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205E121F8617 for ; Wed, 2 Jan 2013 09:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.413 X-Spam-Level: X-Spam-Status: No, score=-10.413 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsWaV3vSmzir for ; Wed, 2 Jan 2013 09:10:57 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B921F860B for ; Wed, 2 Jan 2013 09:10:56 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02HAsT1009764; Wed, 2 Jan 2013 18:10:54 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r02HArq9017745; Wed, 2 Jan 2013 18:10:53 +0100 (CET) Message-ID: <50E46A1D.6070703@cisco.com> Date: Wed, 02 Jan 2013 18:10:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Edward Beili References: <50E440BA.1010208@cisco.com> <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> Content-Type: multipart/alternative; boundary="------------080802060102030109000901" Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:10:59 -0000 This is a multi-part message in MIME format. --------------080802060102030109000901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ed, > > Benoit, > > Thank you for the comments. > > I'm not sure I understand the need to change the ifCapStackMIB > MODULE-IDENTITY value. > > It has been allocated by IANA as { mib-2 166 } in RFC 5066. > > Since we did not change the name (or the content) it should stay with > the same OID, > If nothing is changed in the MIB module, then you're right. And the REVISION clause should be kept. Regards, Benoit > > similar say to MAU-MIB -- the last version is defined in RFC 4836, > where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as > mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC > 2668 and RFC 2239. > > Regards, > > -E. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Wednesday, January 02, 2013 16:14 > *To:* Edward Beili > *Cc:* opsawg@ietf.org > *Subject:* draft-ietf-opsawg-rfc5066bis-00.txt review > > Ed, > > Here is my draft-ietf-opsawg-rfc5066bis-00.txt review > > > 1. > OLD > > -- EdNote: Replace XXXX with the actual RFC number & > -- remove this note > > ::= { mib-2 166 } > > NEW > > -- EdNote: Replace XXXX with the actual RFC number & > -- remove this note > > ::= { mib-2 XXXX } > > _ > _Consequently, the IANA considerations section need to be changed/ > > 7. IANA Considerations > > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been > allocated by IANA in the MIB-2 sub-tree. > > 2. > > I don't believe that you need the following REVISION > REVISION "200711070000Z" -- November 07, 2007 > DESCRIPTION "Initial version, published as RFC 5066." > > _ > Editorial_ > 1. > OLD > > Abstract > > This document defines Management Information Base (MIB) module for > use with network management protocols in TCP/IP-based internets. > > NEW > > Abstract > > This document defines a Management Information Base (MIB) module for > use with network management protocols in TCP/IP-based internets. > > 2. > OLD > > In addition the Security Considerations section was updated to > > > NEW > In addition, the Security Considerations section was updated to > > > > Regards, Benoit (as a contributor) --------------080802060102030109000901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ed,

Benoit,

Thank you for the comments.

 

I’m not sure I understand the need to change the ifCapStackMIB MODULE-IDENTITY value.

It has been allocated by IANA as { mib-2 166 } in RFC 5066.

 

Since we did not change the name (or the content) it should stay with the same OID,

If nothing is changed in the MIB module, then you're right.
And the REVISION clause should be kept.

Regards, Benoit

similar say to MAU-MIB – the last version is defined in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 2239.

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, January 02, 2013 16:14
To: Edward Beili
Cc: opsawg@ietf.org
Subject: draft-ietf-opsawg-rfc5066bis-00.txt review

 

Ed,

Here is my draft-ietf-opsawg-rfc5066bis-00.txt review


1.
OLD

  -- EdNote: Replace XXXX with the actual RFC number &
   -- remove this note
 
       ::= { mib-2 166 }

NEW

  -- EdNote: Replace XXXX with the actual RFC number &
   -- remove this note
 
       ::= { mib-2 XXXX }


Consequently, the IANA considerations section need to be changed/

7.  IANA Considerations
 
   Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been
   allocated by IANA in the MIB-2 sub-tree.

2.

I don't believe that you need the following REVISION
       REVISION    "200711070000Z"  -- November 07, 2007
       DESCRIPTION "Initial version, published as RFC 5066."


Editorial
1.
OLD

Abstract
 
   This document defines Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.

NEW

Abstract
 
   This document defines a Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.

2.
OLD

   In addition the Security Considerations section was updated to
  
 
NEW
   In addition, the Security Considerations section was updated to
 
 
 
Regards, Benoit (as a contributor)

--------------080802060102030109000901-- From dromasca@avaya.com Thu Jan 3 07:58:42 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB25B21F8C0F for ; Thu, 3 Jan 2013 07:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InlX0waioS0n for ; Thu, 3 Jan 2013 07:58:42 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9B21F8BD7 for ; Thu, 3 Jan 2013 07:58:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAKAAEvoFDGmAcF/2dsb2JhbAA7CYF/bb0og0GBAQeCIAEBAxIoPxIBFRUUQiYBBA4NGodoAZ4wnAGMJoVYYQOcCYo2gm+CGQ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="42741868" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Jan 2013 10:48:04 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jan 2013 10:54:40 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 10:58:47 -0500 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: comments on draft-ietf-opsawg-rfc5066bis-00.txt Thread-Index: Ac3pyzXpo+zBWXaORXK/ZykDK2ItfQ== Date: Thu, 3 Jan 2013 15:58:46 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hfrazier@broadcom.com" Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 15:58:43 -0000 Thanks to Ed Beili for undertaking this work.=20 A few comments:=20 1. In the Abstract you are making the statement that this specification mov= es the EFM-CU-MIB module to an IEEE document. In fact the IETF does not hav= e the rights to do such a move alone, this document should rather just reco= gnize this move. Suggested change:=20 OLD:=20 It amends that specification by moving the entire EFM-CU- MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group.=20 NEW:=20 It amends that specification by taking out the entire EFM-CU- MIB module along with the relevant descriptive text. That MIB module=20 will be part of a separate document, maintained by the Institute of=20 Electrical and Electronics Engineers (IEEE) 802.3 working group. Also in Section 1:=20 OLD:=20 This version moves the entire EFM-CU-MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. NEW:=20 This version=20 removes the entire EFM-CU-MIB module along with the relevant descriptive= =20 text. That MIB module will be part of a separate document, maintained by= =20 the Institute of Electrical and Electronics Engineers (IEEE) 802.3. working group. =20 2. In Section 3.1:=20 The EFM-CU-MIB module defined in the previous version of this document, along with the relevant descriptive text, is now moved to a separate, IEEE maintained document, IEEE Std 802.3.1-2011 [802.3.1], which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. - Instead of 'the previous version of this document' we should just say [RF= C5066]. - We should provide a more updated version of the IEEE standard which conta= ins the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would be fine,= but the access is restricted. I suggest to ask advice from Howard Frazier.= =20 3. I suggest that Section 7 mentions that no (new) IANA actions are require= d because it's the same root already allocated in RFC 5066. OLD:=20 Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. NEW:=20 New action is required from IANA as the OID for ifCapStackMIB MODULE-IDE= NTITY was already allocated in [RFC5066]. Regards, Dan From rbonica@juniper.net Thu Jan 3 08:25:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0921F85F7 for ; Thu, 3 Jan 2013 08:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlB6AXfjTVrl for ; Thu, 3 Jan 2013 08:25:15 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id B47DF21F85F3 for ; Thu, 3 Jan 2013 08:25:15 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUOWw6iVbdm7pY31pc8HdwQUt9+1VX/5c@postini.com; Thu, 03 Jan 2013 08:25:15 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 3 Jan 2013 08:24:21 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 3 Jan 2013 08:24:20 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 3 Jan 2013 08:32:37 -0800 Received: from mail135-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 Jan 2013 16:24:20 +0000 Received: from mail135-ch1 (localhost [127.0.0.1]) by mail135-ch1-R.bigfish.com (Postfix) with ESMTP id 3F61E40319 for ; Thu, 3 Jan 2013 16:24:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -7 X-BigFish: PS-7(zz1444M148cI1418Izz1de0h1202h1e76h1d1ah1d2ahzz8275dh18602ehz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail135-ch1 (localhost.localdomain [127.0.0.1]) by mail135-ch1 (MessageSwitch) id 1357230255466764_11255; Thu, 3 Jan 2013 16:24:15 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail135-ch1.bigfish.com (Postfix) with ESMTP id 515B74C0065; Thu, 3 Jan 2013 16:24:15 +0000 (UTC) Received: from BY2PRD0512HT004.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 Jan 2013 16:24:10 +0000 Received: from BY2PRD0512MB653.namprd05.prod.outlook.com ([169.254.5.92]) by BY2PRD0512HT004.namprd05.prod.outlook.com ([10.255.243.37]) with mapi id 14.16.0245.002; Thu, 3 Jan 2013 16:24:07 +0000 From: Ronald Bonica To: "draft-ietf-opsawg-oam-overview@tools.ietf.org" Thread-Topic: Mail regarding draft-ietf-opsawg-oam-overview Thread-Index: Ac3pzsCsgrMcpMHgSAy7ETWuHNqNWQ== Date: Thu, 3 Jan 2013 16:24:07 +0000 Message-ID: <2CF4CB03E2AA464BA0982EC92A02CE2501E0394A@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "opsawg@ietf.org" Subject: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:25:16 -0000 Authors, Thanks for submitting this draft and for suffering through the drawn out pr= ocess. The following are a few comments. Section 1 and 1.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D The introduction is harder to parse than it needs to be. In the introductio= n, I think that that you are trying to make the following points: - This memo summarizes IETF OAM mechanisms - An OAM mechanism provides the following laundry list of functions (e.g., = connectivity checking, path discovery, etc.) Provide a definition for each = function. - The scope of this document is limited to OAM mechanisms that operate on t= he data plane. (SNMP is out of bounds). Do I have that much right? If so, would it be possible to craft Sections 1 = and 1.1 so that these points are brought to the forefront? Section 1.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Should every OAM mechanism listed in Table 1 should appear in the bullet = list. Some are missing (e.g., TRACEROUTE). - You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping. - For the most part, the bullet list is a list of tools. The notable except= ion is IPPM, which is a WG, not a tool. Should you replace that bullet item= with the tools that the produce (e.g., OWAMP, TWAMP)? Section 1.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - The title of this section is inappropriate, because some of the documents= that you list are not on the standards track. Maybe a better title would b= e IETF OAM Documents, Grouped by the OAM mechanism that they support.=20 - If you accept the suggestion listed above, the first column of Table 1 sh= ould specify an OAM mechanism, drawn from the bullet list in Section 1.2. T= he second column should be an RFC number. The third column should be an RFC= title, and the fourth column should be the type. - RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because th= ey all augment the ICMP Destination Unreachable message and their output is= intended for consumption by TRACEROUTE. (While RFC 4950 has something to d= o with MPLS, it is a different mechanism than MPLS LSP PING. Section 2.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Please do a brief scan of the document to make sure that you actually use= all of the acronyms that you define. I found quite a few that are unused. Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D The subsections of Section 3 should map to the bullet points in Section 1.2 Section 3.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By default, traceroute sends 3 probes per TTL. However, in most implementat= ions, this is configurable through the command line Nits =3D=3D=3D=3D Please run the nit checker and correct all errors and warnings -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From dromasca@avaya.com Thu Jan 3 10:00:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D163921F8A69 for ; Thu, 3 Jan 2013 10:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101 X-Spam-Level: X-Spam-Status: No, score=-101 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXffgG7-O11h for ; Thu, 3 Jan 2013 10:00:14 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 089BE21F85B4 for ; Thu, 3 Jan 2013 10:00:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIbQt1DGmAcF/2dsb2JhbAA7CYF/bb0ZFnOCHgEBAQECAQEBAQ8oNAsFBwQCAQgNBAQBAQsUCQcnCxQJCAEBBAENBQgah2gGAQuhe50IBIxSg05hA5wOijeCcoIh X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="382876632" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Jan 2013 12:50:48 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Jan 2013 12:56:11 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 13:00:19 -0500 From: "Romascanu, Dan (Dan)" To: Edward Beili , "opsawg@ietf.org" Thread-Topic: comments on draft-ietf-opsawg-rfc5066bis-00.txt Thread-Index: Ac3pyzXpo+zBWXaORXK/ZykDK2ItfQAD1e3QAABB2JA= Date: Thu, 3 Jan 2013 18:00:18 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hfrazier@broadcom.com" Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 18:00:14 -0000 Hi Ed, > 3. You probably meant "No action is required from IANA ..." Of course, thanks for catching this.=20 > 4. Shall I wait for other comments or should I just issue the next > version of the draft? > Let us wait for a couple of days. Hopefully we will get an answer from Howa= rd concerning a better reference for the IEEE 802.3.1a Rev 2 draft, and may= be other comments from the OPSAWG or the IEEE folks.=20 Please issue a revised version by the start of the next week, as I plan to = enter my Sponsor Ballot comment on the IEEE document, and I need a referenc= e to the best IETF I-D available at that moment.=20 Thanks and Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Thursday, January 03, 2013 7:55 PM > To: Romascanu, Dan (Dan); opsawg@ietf.org > Cc: hfrazier@broadcom.com > Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt >=20 > Dan, > Thank you for the comments, I agree with everything, except for the > following: >=20 > 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > 802.3 would provide a publically accessible link. >=20 > 3. You probably meant "No action is required from IANA ..." instead of > "New action is required form IANA ...", i.e. the correct paragraph would > be: >=20 > OLD: >=20 > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been > allocated by IANA in the MIB-2 sub-tree. >=20 > NEW: >=20 > No action is required from IANA as the OID for ifCapStackMIB MODULE- > IDENTITY > was already allocated in [RFC5066]. >=20 > 4. Shall I wait for other comments or should I just issue the next > version of the draft? >=20 > Regards, > -E. >=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Thursday, January 03, 2013 17:59 > To: opsawg@ietf.org > Cc: hfrazier@broadcom.com > Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >=20 >=20 > Thanks to Ed Beili for undertaking this work. >=20 > A few comments: >=20 > 1. In the Abstract you are making the statement that this specification > moves the EFM-CU-MIB module to an IEEE document. In fact the IETF does > not have the rights to do such a move alone, this document should rather > just recognize this move. >=20 > Suggested change: >=20 > OLD: >=20 > It amends that specification by moving the entire EFM-CU- > MIB module along with the relevant descriptive text, to a separate > document, maintained by the Institute of Electrical and Electronics > Engineers (IEEE) 802.3.1 working group. >=20 > NEW: >=20 > It amends that specification by taking out the entire EFM-CU- > MIB module along with the relevant descriptive text. That MIB module > will be part of a separate document, maintained by the Institute of > Electrical and Electronics Engineers (IEEE) 802.3 working group. >=20 > Also in Section 1: >=20 > OLD: >=20 > This > version moves the entire EFM-CU-MIB module along with the relevant > descriptive text, to a separate document, maintained by the Institute > of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. >=20 > NEW: >=20 > This version > removes the entire EFM-CU-MIB module along with the relevant > descriptive > text. That MIB module will be part of a separate document, maintained > by > the Institute of Electrical and Electronics Engineers (IEEE) 802.3. > working group. >=20 > 2. In Section 3.1: >=20 > The EFM-CU-MIB module defined in the previous version of this > document, along with the relevant descriptive text, is now moved to a > separate, IEEE maintained document, IEEE Std 802.3.1-2011 [802.3.1], > which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. >=20 > - Instead of 'the previous version of this document' we should just say > [RFC5066]. > - We should provide a more updated version of the IEEE standard which > contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would > be fine, but the access is restricted. I suggest to ask advice from > Howard Frazier. >=20 > 3. I suggest that Section 7 mentions that no (new) IANA actions are > required because it's the same root already allocated in RFC 5066. >=20 > OLD: >=20 > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been > allocated by IANA in the MIB-2 sub-tree. >=20 > NEW: >=20 > New action is required from IANA as the OID for ifCapStackMIB MODULE- > IDENTITY > was already allocated in [RFC5066]. >=20 > Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From cpignata@cisco.com Thu Jan 3 11:44:42 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3741821F8D01 for ; Thu, 3 Jan 2013 11:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbyVYE9ZPPYE for ; Thu, 3 Jan 2013 11:44:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF8A21F8D00 for ; Thu, 3 Jan 2013 11:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22377; q=dns/txt; s=iport; t=1357242280; x=1358451880; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FocUKi4jliynvitr3GoB+5Xs0fXtf+TCTJ1onW5mmms=; b=MnPyLZeNw1110qxy6NOAHO/cmcddbzZ8E3/WNGlcD5qkxOCZ3wUQbVMd 0abmZjiI2lBXF99TVe4GUBUArwwUcMJWjX43D2q5KENDfWq0pRh/+L9UE fuYrtXLSL+nfCTbwuxZBpZN/H7JZvWPSAUGAhEihxF0LRj7Ehk0KcWVQr I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACzf5VCtJXG//2dsb2JhbABFtDwBiRQWc4IfAQEEAQEBRiULEAIBCCIdBycLFBEBAQQOBQgBiAoMtj2MYQsGg0dhA5cojyyCdIFoCRce X-IronPort-AV: E=Sophos;i="4.84,404,1355097600"; d="scan'208,217";a="155583032" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 03 Jan 2013 19:44:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r03JiY9f026843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 19:44:34 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 3 Jan 2013 13:44:34 -0600 From: "Carlos Pignataro (cpignata)" To: "draft-ietf-opsawg-oam-overview@tools.ietf.org" Thread-Topic: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview Thread-Index: Ac3pzsCsgrMcpMHgSAy7ETWuHNqNWQATkq+A Date: Thu, 3 Jan 2013 19:44:34 +0000 Message-ID: <95067C434CE250468B77282634C96ED32284FE04@xmb-aln-x02.cisco.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E0394A@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E0394A@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.196] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED32284FE04xmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:44:42 -0000 --_000_95067C434CE250468B77282634C96ED32284FE04xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find an additional set of comments. Hopefully these are clear and us= eful, they include both substantive and editorial comments. 1. Introdoction 1.1. Background I agree with Ron that this is hard to parse, even more so describing plane = interactions without a diagram. Frankly, the Management-plane mentions are = a bit of a distraction from the main point (other than saying that it is ou= t of scope) 1.2. The OAM Toolsets ... The IETF has defined OAM protocols and mechanisms in several different fronts: This section is confusing, at least to me, in that it is not clear if it is= defining protocols, program, mechanisms, or all intertwined, and which one= it is cataloging or listing. I think it is very important for this document to have precision in the def= inition of OAM terms, differentiating a protocol from a tool from a program= . For example, the document says: o ICMP Ping: ICMP Echo request, also known as Ping, as defined in [ICMPv4], and [ICMPv6]. ICMP Ping is a very simple and basic mechanism in failure diagnosis. LSP Ping is to some extent based on ICMP Ping. AFAIK, "ICMP Echo request" is not known as Ping per se. ICMP Echo requests = are sent in some OSes traceroute implementations (with increasing TTL, etc.= ) Specifically, RFC1147 ("Tools for Monitoring and Debugging TCP/IP Interne= ts") describes: Ping a tool that sends packet probes such as ICMP echo mes- sages; to help distinguish tools, we do not consider NMS queries or protocol spoofing (see below) as probes. RFC1208 ("A Glossary of Networking Terms") defines: ping: Packet internet groper. A program used to test reachability of destinations by sending them an ICMP echo request and waiting for a reply. The term is used as a verb: "Ping host X to see if it is up!" RFC 1122 as: * Active probes such as "pinging" (i.e., using an ICMP Echo Request/Reply exchange) Further, that paragraph says: o ICMP Ping: ICMP Echo request, also known as Ping, as defined in [ICMPv4], and [ICMPv6]. ICMP Ping is a very simple and basic mechanism in failure diagnosis. LSP Ping is to some extent based on ICMP Ping. And LSP Ping is not "based" on ICMP Ping. It is, instead, as per RFC 4379: In this document, we describe a mechanism that accomplishes these goals. This mechanism is modeled after the ping/traceroute paradigm: ping (ICMP echo request [ICMP]) is used for connectivity checks, and traceroute is used for hop-by-hop fault localization as well as path tracing. This document specifies a "ping" mode and a "traceroute" mode for testing MPLS LSPs. 1.3. IETF OAM Standards Even further down, the document says: +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |ICMPv4 Ping| Internet Control Message Protocol |Tool | RFC 792 | | | | | | +-----------+--------------------------------------+-----+----------+ However Ping, if considered a tool, is not defined in RFC 792. ICMPv4, a pr= otocol, is defined, which can be used in ping and in traceroute probes and = other tools. +-----------+--------------------------------------+-----+----------+ |Traceroute | A Primer On Internet and TCP/IP |Tool | RFC 2151 | | | Tools and Utilities | | | +-----------+--------------------------------------+-----+----------+ What is the RFC column pointing to? There are traceroute (as a tool) mentio= ns and definitions earlier (RFC 1147) and later. +-----------+--------------------------------------+-----+----------+ |IETF MPLS | Operations and Management (OAM) |Misc.| RFC 4377 | |OAM | Requirements for Multi-Protocol Label| | | |(LSP Ping) | Switched (MPLS) Networks | | | | +--------------------------------------+-----+----------+ ... | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching | | | +-----------+--------------------------------------+-----+----------+ RFC 4950 does not define "LSP Ping". It is ICMP with Extension for MPLS, no= t MPLS OAM. Perhaps there needs to be a section on RFC 4884, and specific extensions li= ke RFC 4950, RFC 5837, etc? Also, RFC 4950 is cited here but not included in the References section. +-----------+--------------------------------------+-----+----------+ |PW VCCV | Pseudowire Virtual Circuit |Inf. | RFC 5085 | | | Connectivity Verification (VCCV): | | | | | A Control Channel for Pseudowires | | | +-----------+--------------------------------------+-----+----------+ This is missing RFC 5885 as well. 3. OAM Tools. This section seems to also somewhat mixed different things, since BFD and L= SP Ping are for example used within VCCV. 3.7.3.3 and 3.7.3.4 Lock ... This section seems to miss a pointer to RFC 6435. Thank you, -- Carlos. On Jan 3, 2013, at 11:24 AM, Ronald Bonica > wrote: Authors, Thanks for submitting this draft and for suffering through the drawn out pr= ocess. The following are a few comments. Section 1 and 1.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D The introduction is harder to parse than it needs to be. In the introductio= n, I think that that you are trying to make the following points: - This memo summarizes IETF OAM mechanisms - An OAM mechanism provides the following laundry list of functions (e.g., = connectivity checking, path discovery, etc.) Provide a definition for each = function. - The scope of this document is limited to OAM mechanisms that operate on t= he data plane. (SNMP is out of bounds). Do I have that much right? If so, would it be possible to craft Sections 1 = and 1.1 so that these points are brought to the forefront? Section 1.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Should every OAM mechanism listed in Table 1 should appear in the bullet = list. Some are missing (e.g., TRACEROUTE). - You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping. - For the most part, the bullet list is a list of tools. The notable except= ion is IPPM, which is a WG, not a tool. Should you replace that bullet item= with the tools that the produce (e.g., OWAMP, TWAMP)? Section 1.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - The title of this section is inappropriate, because some of the documents= that you list are not on the standards track. Maybe a better title would b= e IETF OAM Documents, Grouped by the OAM mechanism that they support. - If you accept the suggestion listed above, the first column of Table 1 sh= ould specify an OAM mechanism, drawn from the bullet list in Section 1.2. T= he second column should be an RFC number. The third column should be an RFC= title, and the fourth column should be the type. - RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because th= ey all augment the ICMP Destination Unreachable message and their output is= intended for consumption by TRACEROUTE. (While RFC 4950 has something to d= o with MPLS, it is a different mechanism than MPLS LSP PING. Section 2.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Please do a brief scan of the document to make sure that you actually use= all of the acronyms that you define. I found quite a few that are unused. Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D The subsections of Section 3 should map to the bullet points in Section 1.2 Section 3.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By default, traceroute sends 3 probes per TTL. However, in most implementat= ions, this is configurable through the command line Nits =3D=3D=3D=3D Please run the nit checker and correct all errors and warnings -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_95067C434CE250468B77282634C96ED32284FE04xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <10D2B9DF7635D14C9C8CACD9BD16EB87@cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

Please find an additional set of comments. Hopefully these are clear a= nd useful, they include both substantive and editorial comments.

1. Introdoction
1.1. Background

I agree with Ron that this is hard to parse, even more so describing p= lane interactions without a diagram. Frankly, the Management-plane mentions= are a bit of a distraction from the main point (other than saying that it = is out of scope)

1.2. The OAM Toolsets
...
   The IETF has defined OAM protocols and mechanisms=
 in several
   different fronts:

This section is confusing, at least to me, in that it is not clear if = it is defining protocols, program, mechanisms, or all intertwined, and whic= h one it is cataloging or listing. 

I think it is very important for this document to have precision in th= e definition of OAM terms, differentiating a protocol from a tool from a pr= ogram.

For example, the document says:

   o ICMP Ping:
      ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
      [ICMPv6].=
 ICMP Ping is a very simple and basic mechanism in
      failure diagnosis. LSP Ping is to some extent based on ICMP Ping.

AFAIK, "ICMP Echo request" is not known as Ping per se. ICMP=
 Echo requests are sent in some OSes traceroute implementations (with incre=
asing TTL, etc.) Specifically, RFC1147 ("Tools for Monitoring and Debu=
gging TCP/IP Internets") describes:









          Ping
               a tool that sends packet probes such as ICMP echo  mes-
               sages;  to  help  distinguish tools, we do not consider
               NMS queries or protocol spoofing (see below) as probes.



RFC1208 ("A Glossary of Networking Terms") defines:







   ping: Packet internet grop=
er.  A program used to test reachability of
   destinations by sending them an ICMP echo request and waiting for a
   reply.  The term is used as a verb: "Ping host X to see if it is up=
!"


RFC 1122 as:







            *    Active probes such as "pinging=
" (i.e., using an ICMP
                 Echo Request/Reply exchange) 


Further, that paragraph says:



   o ICMP Ping:
      ICMP Echo request, also known as Ping, as defined in [ICMPv4], and
      [ICMPv6].=
 ICMP Ping is a very simple and basic mechanism in
      failure diagnosis. LSP Ping is to some extent based on ICMP Ping.
And LSP Ping is not "based" on ICMP Ping. It is, instead, as= per RFC 4379:

   In this document, we describe a mechanism that ac=
complishes these
   goals.  This mechanism is modeled after the ping/traceroute paradigm:
   ping (ICMP echo request [ICMP])=
 is used for connectivity checks, and
   traceroute is used for hop-by-hop fault localization as well as path
   tracing.  This document specifies a "ping" mode and a "tr=
aceroute"
   mode for testing MPLS LSPs.
Even further down, the document says:
However Ping, if considered a tool, is not defined in RFC 792. ICMPv4,= a protocol, is defined, which can be used in ping and in traceroute probes= and other tools.

   +-----------+----------------------------=
----------+-----+----------+
   |Traceroute | A Primer On Internet and TCP/IP      |Tool | RFC 2151 |
   |           | Tools and Utilities                  |     |          |
   +-----------+--------------------------------------+-----=
3;----------+

What is the RFC column pointing to? There are traceroute (as a tool) m= entions and definitions earlier (RFC 1147) and later.


   +-----------+----------------------------=
----------+-----+----------+
   |IETF MPLS  | Operations and Management (OAM)      |Misc.| RFC 4377 |
   |OAM        | Requirements for Multi-Protocol Label|     |          |
   |(LSP Ping) | Switched (MPLS) Networks             |     |          |
   |           +--------------------------------------+-----+--=
--------+
...
   |           +--------------------------------=
------+-----+----------+
   |           | ICMP Extensions for Multiprotocol    |Tool | RFC 4950 |
   |           | Label Switching                      |     |          |
   +-----------+--------------------------------------+-----=
3;----------+
RFC 4950 does not define "LSP Ping". It is ICMP with Extensi= on for MPLS, not MPLS OAM. 

Perhaps there needs to be a section on RFC 4884, and specific extensio= ns like RFC 4950, RFC 5837, etc?

Also, RFC 4950 is cited here but not included in the References sectio= n.

   +-----------+----------------------------=
----------+-----+----------+
   |PW VCCV    | Pseudowire Virtual Circuit           |Inf. | RFC 5085 |
   |           | Connectivity Verification (VCCV):    |     |          |
   |           | A Control Channel for Pseudowires    |     |          |
   +-----------+--------------------------------------+-----=
3;----------+
This is missing RFC 5885 as well.

3. OAM Tools.
This section seems to also somewhat mixed different things, since BFD = and LSP Ping are for example used within VCCV.

3.7.3.3 and 3.7.3.4 Lock ...
This section seems to miss a pointer to RFC 6435.

Thank you,

-- Carlos.


On Jan 3, 2013, at 11:24 AM, Ronald Bonica <rbonica@juniper.net> wrote:

Authors,

Thanks for submitting this draft and for suffering through the drawn out pr= ocess. The following are a few comments.

Section 1 and 1.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The introduction is harder to parse than it needs to be. In the introductio= n, I think that that you are trying to make the following points:

- This memo summarizes IETF OAM mechanisms
- An OAM mechanism provides the following laundry list of functions (e.g., = connectivity checking, path discovery, etc.) Provide a definition for each = function.
- The scope of this document is limited to OAM mechanisms that operate on t= he data plane. (SNMP is out of bounds).

Do I have that much right? If so, would it be possible to craft Sections 1 = and 1.1 so that these points are brought to the forefront?

Section 1.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Should every OAM mechanism listed in Table 1 should appear in the bullet = list. Some are missing (e.g., TRACEROUTE).
- You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping.
- For the most part, the bullet list is a list of tools. The notable except= ion is IPPM, which is a WG, not a tool. Should you replace that bullet item= with the tools that the produce (e.g., OWAMP, TWAMP)?

Section 1.3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- The title of this section is inappropriate, because some of the documents= that you list are not on the standards track. Maybe a better title would b= e IETF OAM Documents, Grouped by the OAM mechanism that they support.
- If you accept the suggestion listed above, the first column of Table 1 sh= ould specify an OAM mechanism, drawn from the bullet list in Section 1.2. T= he second column should be an RFC number. The third column should be an RFC= title, and the fourth column should be the type.
- RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because th= ey all augment the ICMP Destination Unreachable message and their output is= intended for consumption by TRACEROUTE. (While RFC 4950 has something to d= o with MPLS, it is a different mechanism than MPLS LSP PING.

Section 2.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- Please do a brief scan of the document to make sure that you actually use= all of the acronyms that you define. I found quite a few that are unused.<= br>

Section 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D
The subsections of Section 3 should map to the bullet points in Section 1.2=

Section 3.2
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
By default, traceroute sends 3 probes per TTL. However, in most implementat= ions, this is configurable through the command line


Nits
=3D=3D=3D=3D
Please run the nit checker and correct all errors and warnings

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf



_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


--_000_95067C434CE250468B77282634C96ED32284FE04xmbalnx02ciscoc_-- From EdwardB@actelis.com Wed Jan 2 08:42:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DE21F8653 for ; Wed, 2 Jan 2013 08:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsZtGY5aeAnQ for ; Wed, 2 Jan 2013 08:42:02 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08B21F8694 for ; Wed, 2 Jan 2013 08:42:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,396,1355090400"; d="scan'208,217";a="1212668" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 02 Jan 2013 18:41:58 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Wed, 2 Jan 2013 18:41:58 +0200 From: Edward Beili To: Benoit Claise Date: Wed, 2 Jan 2013 18:41:56 +0200 Thread-Topic: draft-ietf-opsawg-rfc5066bis-00.txt review Thread-Index: Ac3o83W9kqh9Sl2TSm6FRU4k/9lYKQADMnYg Message-ID: <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> References: <50E440BA.1010208@cisco.com> In-Reply-To: <50E440BA.1010208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602500BF488CBilmail07act_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Jan 2013 12:29:13 -0800 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 16:42:03 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602500BF488CBilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, Thank you for the comments. I'm not sure I understand the need to change the ifCapStackMIB MODULE-IDENT= ITY value. It has been allocated by IANA as { mib-2 166 } in RFC 5066. Since we did not change the name (or the content) it should stay with the s= ame OID, similar say to MAU-MIB - the last version is defined in RFC 4836, = where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod = MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RF= C 2239. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, January 02, 2013 16:14 To: Edward Beili Cc: opsawg@ietf.org Subject: draft-ietf-opsawg-rfc5066bis-00.txt review Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::=3D { mib-2 166 } NEW -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::=3D { mib-2 XXXX } Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." Editorial 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor) --_000_4087887712E5C648B9F72BB9D912FD4602500BF488CBilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit,

Thank you f= or the comments.

&nbs= p;

I’m not sure I underst= and the need to change the ifCapStackMIB MODULE-IDENTITY value.<= /span>

It has been allocated by IANA as { mi= b-2 166 } in RFC 5066.

 

Since we did not chang= e the name (or the content) it should stay with the same OID, similar say t= o MAU-MIB – the last version is defined in RFC 4836, where mauMod MOD= ULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODULE-IDENTITY = in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 2239.

 

Regards,

-E.

 =

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind= owtext'> Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesda= y, January 02, 2013 16:14
To: Edward Beili
Cc: opsawg@i= etf.org
Subject: draft-ietf-opsawg-rfc5066bis-00.txt review<= /o:p>

 

Ed,

Here is my draft-ietf-opsawg-rfc5066bis-00.txt r= eview


1.
OLD

  -- EdNote: Replace XXX=
X with the actual RFC number &
   -- rem=
ove this note
 
  =
     ::=3D { mib-2 166 }

NEW

  -- EdNo=
te: Replace XXXX with the actual RFC number &
&nbs=
p;  -- remove this note
 
       ::=3D { mib-2 XXXX }


Consequently, the IANA considerations sec= tion need to be changed/

7.  IANA Considerations
 
   Object identifi=
er 166 for the ifCapStackMIB MODULE-IDENTITY have been
   allocated by IANA in the MIB-2 sub-tree.

2.

I don't believe that you need the fo=
llowing REVISION
       =
REVISION    "200711070000Z"  -- November 07, =
2007
       DESCRIPTION =
"Initial version, published as RFC 5066."


Editorial
1.
OLD

Abstrac=
t
 
   This docume=
nt defines Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based intern= ets.

NEW

Abstract
 
   This document =
defines a Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based interne= ts.

2.
OLD

 =
;  In addition the Security Considerations section was updated to=

  
 
N=
EW
   In addition, the Security Consideratio=
ns section was updated to
 
=
 
 
Regards, Benoit (as=
 a contributor)
= --_000_4087887712E5C648B9F72BB9D912FD4602500BF488CBilmail07act_-- From EdwardB@actelis.com Thu Jan 3 09:55:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62E21F86AA for ; Thu, 3 Jan 2013 09:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJgzOWeumIYM for ; Thu, 3 Jan 2013 09:55:11 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1C221F868B for ; Thu, 3 Jan 2013 09:55:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,404,1355090400"; d="scan'208";a="1216763" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 03 Jan 2013 19:55:06 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Thu, 3 Jan 2013 19:55:06 +0200 From: Edward Beili To: "Romascanu, Dan (Dan)" , "opsawg@ietf.org" Date: Thu, 3 Jan 2013 19:55:05 +0200 Thread-Topic: comments on draft-ietf-opsawg-rfc5066bis-00.txt Thread-Index: Ac3pyzXpo+zBWXaORXK/ZykDK2ItfQAD1e3Q Message-ID: <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Jan 2013 12:29:13 -0800 Cc: "hfrazier@broadcom.com" Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:55:12 -0000 Dan, Thank you for the comments, I agree with everything, except for the followi= ng: 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE 802.3 w= ould provide a publically accessible link. 3. You probably meant "No action is required from IANA ..." instead of "New= action is required form IANA ...", i.e. the correct paragraph would be: OLD:=20 Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. NEW:=20 No action is required from IANA as the OID for ifCapStackMIB MODULE-IDEN= TITY was already allocated in [RFC5066]. 4. Shall I wait for other comments or should I just issue the next version = of the draft? Regards, -E. -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Romascanu, Dan (Dan) Sent: Thursday, January 03, 2013 17:59 To: opsawg@ietf.org Cc: hfrazier@broadcom.com Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt Thanks to Ed Beili for undertaking this work.=20 A few comments:=20 1. In the Abstract you are making the statement that this specification mov= es the EFM-CU-MIB module to an IEEE document. In fact the IETF does not hav= e the rights to do such a move alone, this document should rather just reco= gnize this move. Suggested change:=20 OLD:=20 It amends that specification by moving the entire EFM-CU- MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group.=20 NEW:=20 It amends that specification by taking out the entire EFM-CU- MIB module along with the relevant descriptive text. That MIB module=20 will be part of a separate document, maintained by the Institute of=20 Electrical and Electronics Engineers (IEEE) 802.3 working group. Also in Section 1:=20 OLD:=20 This version moves the entire EFM-CU-MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. NEW:=20 This version=20 removes the entire EFM-CU-MIB module along with the relevant descriptive= =20 text. That MIB module will be part of a separate document, maintained by= =20 the Institute of Electrical and Electronics Engineers (IEEE) 802.3. working group. =20 2. In Section 3.1:=20 The EFM-CU-MIB module defined in the previous version of this document, along with the relevant descriptive text, is now moved to a separate, IEEE maintained document, IEEE Std 802.3.1-2011 [802.3.1], which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. - Instead of 'the previous version of this document' we should just say [RF= C5066]. - We should provide a more updated version of the IEEE standard which conta= ins the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would be fine,= but the access is restricted. I suggest to ask advice from Howard Frazier.= =20 3. I suggest that Section 7 mentions that no (new) IANA actions are require= d because it's the same root already allocated in RFC 5066. OLD:=20 Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. NEW:=20 New action is required from IANA as the OID for ifCapStackMIB MODULE-IDE= NTITY was already allocated in [RFC5066]. Regards, Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From ietfdbh@comcast.net Fri Jan 4 20:44:36 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6877121F8751 for ; Fri, 4 Jan 2013 20:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzOSd6UCQj4u for ; Fri, 4 Jan 2013 20:44:34 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71E21F874F for ; Fri, 4 Jan 2013 20:44:33 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta04.westchester.pa.mail.comcast.net with comcast id k4dL1k0041swQuc544kZM6; Sat, 05 Jan 2013 04:44:33 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta15.westchester.pa.mail.comcast.net with comcast id k4kY1k00Y3Ecudz3b4kYu4; Sat, 05 Jan 2013 04:44:33 +0000 From: "ietfdbh" To: "'Edward Beili'" , "'Benoit Claise'" References: <50E440BA.1010208@cisco.com> <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> Date: Fri, 4 Jan 2013 23:44:33 -0500 Message-ID: <017601cdeaff$5bffe730$13ffb590$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0177_01CDEAD5.732D3A90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9SFqD/JFHsd5+IABpPTgc6/Z9hACPaeowmFbs2zA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357361073; bh=h/Us1PxC09QN0O7fMkl46Yh9WdYnonKYnyr53yDobWg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Y4lr71TXFhQwDsTF4sGhdUqcLfE0cTn/W6f4RYIFxxt8kRE0jBRflov9iSfZrwppA k3lI0KCGMqXF6bqTVsPOHaPvu5547DHaBe06i8XGmJcTbIVbu0725wrDrBEeQYxjgh XQBwWhaujl3v9MukcbfO2CaFVMUbFh0OukeCR2hzxWyjQIqtOr3h6Cr+p53Q//n1wy wObTn1ZM/JOXVl7ugXORF1i6SZkbWueHVW6y79a1+EakUsudmoxiLJ2LMLpTagQ0Kq x6VW4V71ryFnWNgGmXsoO/1+/x2WrdkMdGqjyt4bgL0bz4+QE/0wrRpsZhQDcw5Z8Y LVcGEAdKyjYhg== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 04:44:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0177_01CDEAD5.732D3A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think the mib-2 subtree is an Internet-standard subtree, and requires an RFC to update: SMI Network Management MGMT Codes Internet-standard MIB Registration Procedures RFC Required Description iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) Reference [ RFC1213][ RFC2578] If IEEE802 modifies this MIB module that is under mib-2, specifically by adding new objects, . is it planned that IEEE802 will do so under the current IANA-assigned subtree mib-2, for which IANA has the authority to make assignments, using RFCs? Or is it planned they will relocate the MIB module into the IEEE802 subtree, where IEEE802 has the authority to make assignments? See RFC4663, section 2.3 and section 3.2 for a previous discussion of this issue. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Wednesday, January 02, 2013 11:42 AM To: Benoit Claise Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Benoit, Thank you for the comments. I'm not sure I understand the need to change the ifCapStackMIB MODULE-IDENTITY value. It has been allocated by IANA as { mib-2 166 } in RFC 5066. Since we did not change the name (or the content) it should stay with the same OID, similar say to MAU-MIB - the last version is defined in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 2239. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, January 02, 2013 16:14 To: Edward Beili Cc: opsawg@ietf.org Subject: draft-ietf-opsawg-rfc5066bis-00.txt review Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 166 } NEW -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 XXXX } Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." Editorial 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor) ------=_NextPart_000_0177_01CDEAD5.732D3A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think the mib-2 subtree is an Internet-standard subtree, and = requires an RFC to update:

SMI Network Management MGMT Codes Internet-standard = MIB

Registration Procedures

RFC = Required

Description

iso.org.dod.internet.mgmt.mib-2 = (1.3.6.1.2.1)

Reference

[

RFC1213][RFC2578]

 

If IEEE802 modifies this MIB module that is under mib-2, specifically = by adding new objects, …

is it planned that IEEE802 will do so under the current IANA-assigned = subtree mib-2, for which IANA has the authority to make assignments, = using RFCs?

Or is it planned they will relocate the MIB module into the IEEE802 = subtree, where IEEE802 has the authority to make = assignments?

 

See RFC4663, section 2.3 and section 3.2 for a previous discussion of = this issue.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Edward Beili
Sent: Wednesday, January 02, 2013 = 11:42 AM
To: Benoit Claise
Cc: = opsawg@ietf.org
Subject: Re: [OPSAWG] = draft-ietf-opsawg-rfc5066bis-00.txt = review

 

Benoit,

Thank you for the comments.

 

I’m not sure I understand the need to change the ifCapStackMIB = MODULE-IDENTITY value.

It has been allocated by IANA as { mib-2 166 } in RFC = 5066.

 

Since we did not change the name (or the content) it should stay with = the same OID, similar say to MAU-MIB – the last version is defined = in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the = same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC = 3636, RFC 2668 and RFC 2239.

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Wednesday, January 02, 2013 16:14
To: Edward = Beili
Cc: opsawg@ietf.org
Subject: = draft-ietf-opsawg-rfc5066bis-00.txt = review

 

Ed,

Here is my = draft-ietf-opsawg-rfc5066bis-00.txt = review


1.
OLD

  -- EdNote: Replace =
XXXX with the actual RFC number &
   =
-- remove this =
note
 
   &=
nbsp;   ::=3D { mib-2 166 }

NEW

  -- EdNote: =
Replace XXXX with the actual RFC number =
&
   -- remove this =
note
 
   &=
nbsp;   ::=3D { mib-2 XXXX }


Consequently, the IANA considerations = section need to be changed/

7.  IANA =
Considerations
 
 &nb=
sp; Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have =
been
   allocated by IANA in the MIB-2 =
sub-tree.

2.

I =
don't believe that you need the following =
REVISION
       =
REVISION    "200711070000Z"  -- November =
07, 2007
       =
DESCRIPTION "Initial version, published as RFC 5066." =


Editorial
1.
OLD

Ab=
stract
 
   =
This document defines Management Information Base (MIB) module =
for
   use with network management =
protocols in TCP/IP-based internets.

NEW

Abstract
 
   This document defines a =
Management Information Base (MIB) module =
for
   use with network management =
protocols in TCP/IP-based internets.

2.
OLD

   In addition =
the Security Considerations section was updated =
to
  =

 
NEW
   In addition, the Security Considerations section was = updated = to
 
 
 
Regards, Benoit (as a =
contributor)
------=_NextPart_000_0177_01CDEAD5.732D3A90-- From ietfc@btconnect.com Sat Jan 5 04:48:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112CE21F8703 for ; Sat, 5 Jan 2013 04:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBN5Ay9mWW3I for ; Sat, 5 Jan 2013 04:48:38 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id CDDBC21F8713 for ; Sat, 5 Jan 2013 04:48:28 -0800 (PST) Received: from mail207-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.23; Sat, 5 Jan 2013 12:48:28 +0000 Received: from mail207-co9 (localhost [127.0.0.1]) by mail207-co9-R.bigfish.com (Postfix) with ESMTP id 56C136602EE; Sat, 5 Jan 2013 12:48:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371I1521I148cI542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h304l1155h) Received: from mail207-co9 (localhost.localdomain [127.0.0.1]) by mail207-co9 (MessageSwitch) id 135739006756212_16702; Sat, 5 Jan 2013 12:47:47 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.252]) by mail207-co9.bigfish.com (Postfix) with ESMTP id 0B37294004B; Sat, 5 Jan 2013 12:47:47 +0000 (UTC) Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 5 Jan 2013 12:47:45 +0000 Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sat, 5 Jan 2013 12:47:43 +0000 Message-ID: <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> From: t.petch To: "Romascanu, Dan (Dan)" , Edward Beili , References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> Date: Sat, 5 Jan 2013 12:45:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 12:48:39 -0000 I wonder if this I-D should really supersede RFC5066. I would rather see RFC5066 become Historic with this as an Updates. Should the Copyright carry the caveat about old material for which the current rules may not apply? Since this MIB Module is going to see extensive use by another SDO, this seems particularly relevant. Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Edward Beili" ; Cc: Sent: Thursday, January 03, 2013 6:00 PM > Hi Ed, > > > 3. You probably meant "No action is required from IANA ..." > > Of course, thanks for catching this. > > > > 4. Shall I wait for other comments or should I just issue the next > > version of the draft? > > > > Let us wait for a couple of days. Hopefully we will get an answer from Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft, and maybe other comments from the OPSAWG or the IEEE folks. > > Please issue a revised version by the start of the next week, as I plan to enter my Sponsor Ballot comment on the IEEE document, and I need a reference to the best IETF I-D available at that moment. > > Thanks and Regards, > > Dan > > > > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: Thursday, January 03, 2013 7:55 PM > > To: Romascanu, Dan (Dan); opsawg@ietf.org > > Cc: hfrazier@broadcom.com > > Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt > > > > Dan, > > Thank you for the comments, I agree with everything, except for the > > following: > > > > 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > > 802.3 would provide a publically accessible link. > > > > 3. You probably meant "No action is required from IANA ..." instead of > > "New action is required form IANA ...", i.e. the correct paragraph would > > be: > > > > OLD: > > > > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been > > allocated by IANA in the MIB-2 sub-tree. > > > > NEW: > > > > No action is required from IANA as the OID for ifCapStackMIB MODULE- > > IDENTITY > > was already allocated in [RFC5066]. > > > > 4. Shall I wait for other comments or should I just issue the next > > version of the draft? > > > > Regards, > > -E. > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > > Of Romascanu, Dan (Dan) > > Sent: Thursday, January 03, 2013 17:59 > > To: opsawg@ietf.org > > Cc: hfrazier@broadcom.com > > Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > > > > > > Thanks to Ed Beili for undertaking this work. > > > > A few comments: > > > > 1. In the Abstract you are making the statement that this specification > > moves the EFM-CU-MIB module to an IEEE document. In fact the IETF does > > not have the rights to do such a move alone, this document should rather > > just recognize this move. > > > > Suggested change: > > > > OLD: > > > > It amends that specification by moving the entire EFM-CU- > > MIB module along with the relevant descriptive text, to a separate > > document, maintained by the Institute of Electrical and Electronics > > Engineers (IEEE) 802.3.1 working group. > > > > NEW: > > > > It amends that specification by taking out the entire EFM-CU- > > MIB module along with the relevant descriptive text. That MIB module > > will be part of a separate document, maintained by the Institute of > > Electrical and Electronics Engineers (IEEE) 802.3 working group. > > > > Also in Section 1: > > > > OLD: > > > > This > > version moves the entire EFM-CU-MIB module along with the relevant > > descriptive text, to a separate document, maintained by the Institute > > of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. > > > > NEW: > > > > This version > > removes the entire EFM-CU-MIB module along with the relevant > > descriptive > > text. That MIB module will be part of a separate document, maintained > > by > > the Institute of Electrical and Electronics Engineers (IEEE) 802.3. > > working group. > > > > 2. In Section 3.1: > > > > The EFM-CU-MIB module defined in the previous version of this > > document, along with the relevant descriptive text, is now moved to a > > separate, IEEE maintained document, IEEE Std 802.3.1-2011 [802.3.1], > > which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. > > > > - Instead of 'the previous version of this document' we should just say > > [RFC5066]. > > - We should provide a more updated version of the IEEE standard which > > contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot would > > be fine, but the access is restricted. I suggest to ask advice from > > Howard Frazier. > > > > 3. I suggest that Section 7 mentions that no (new) IANA actions are > > required because it's the same root already allocated in RFC 5066. > > > > OLD: > > > > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been > > allocated by IANA in the MIB-2 sub-tree. > > > > NEW: > > > > New action is required from IANA as the OID for ifCapStackMIB MODULE- > > IDENTITY > > was already allocated in [RFC5066]. > > > > Regards, > > > > Dan > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From sob@sobco.com Sat Jan 5 06:26:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B5021F86B6 for ; Sat, 5 Jan 2013 06:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENaSdoC4Ynw3 for ; Sat, 5 Jan 2013 06:26:01 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC321F86B3 for ; Sat, 5 Jan 2013 06:26:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id DCEC98CE66D; Sat, 5 Jan 2013 09:25:59 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y06icCRP49yr; Sat, 5 Jan 2013 09:25:52 -0500 (EST) Received: from [10.0.1.11] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id D27C18CE632; Sat, 5 Jan 2013 09:25:52 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Scott O Bradner In-Reply-To: <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> Date: Sat, 5 Jan 2013 09:25:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19B24B5B-D92B-471B-ABCE-8C67E8F11AD6@sobco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1499) Cc: opsawg@ietf.org, Edward Beili Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 14:26:02 -0000 On Jan 5, 2013, at 7:45 AM, t.petch wrote: > I wonder if this I-D should really supersede RFC5066. I would rather > see RFC5066 become Historic with this as an Updates. a historic document does not exist (standards track wise) so there would = be nothing to=20 update -=20 also- an update would not be a complete replacement (i.e. some of the=20 old document would still be in force) - is that the case here (i.e. do you think that this is not a full replacement?) >=20 > Should the Copyright carry the caveat about old material for which the > current rules may not apply? Since this MIB Module is going to see > extensive use by another SDO, this seems particularly relevant. the author of the old doc is the author of the new doc and is submitting = the=20 new doc under the current rules (and gave himself permission to do that) Scott >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "Edward Beili" ; > Cc: > Sent: Thursday, January 03, 2013 6:00 PM >=20 >> Hi Ed, >>=20 >>> 3. You probably meant "No action is required from IANA ..." >>=20 >> Of course, thanks for catching this. >>=20 >>=20 >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>>=20 >>=20 >> Let us wait for a couple of days. Hopefully we will get an answer = from > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 = draft, > and maybe other comments from the OPSAWG or the IEEE folks. >>=20 >> Please issue a revised version by the start of the next week, as I > plan to enter my Sponsor Ballot comment on the IEEE document, and I = need > a reference to the best IETF I-D available at that moment. >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Edward Beili [mailto:EdwardB@actelis.com] >>> Sent: Thursday, January 03, 2013 7:55 PM >>> To: Romascanu, Dan (Dan); opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt >>>=20 >>> Dan, >>> Thank you for the comments, I agree with everything, except for the >>> following: >>>=20 >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE >>> 802.3 would provide a publically accessible link. >>>=20 >>> 3. You probably meant "No action is required from IANA ..." instead > of >>> "New action is required form IANA ...", i.e. the correct paragraph > would >>> be: >>>=20 >>> OLD: >>>=20 >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>>=20 >>> NEW: >>>=20 >>> No action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>>=20 >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>>=20 >>> Regards, >>> -E. >>>=20 >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf >>> Of Romascanu, Dan (Dan) >>> Sent: Thursday, January 03, 2013 17:59 >>> To: opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >>>=20 >>>=20 >>> Thanks to Ed Beili for undertaking this work. >>>=20 >>> A few comments: >>>=20 >>> 1. In the Abstract you are making the statement that this > specification >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF > does >>> not have the rights to do such a move alone, this document should > rather >>> just recognize this move. >>>=20 >>> Suggested change: >>>=20 >>> OLD: >>>=20 >>> It amends that specification by moving the entire EFM-CU- >>> MIB module along with the relevant descriptive text, to a > separate >>> document, maintained by the Institute of Electrical and > Electronics >>> Engineers (IEEE) 802.3.1 working group. >>>=20 >>> NEW: >>>=20 >>> It amends that specification by taking out the entire EFM-CU- >>> MIB module along with the relevant descriptive text. That MIB > module >>> will be part of a separate document, maintained by the Institute > of >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. >>>=20 >>> Also in Section 1: >>>=20 >>> OLD: >>>=20 >>> This >>> version moves the entire EFM-CU-MIB module along with the > relevant >>> descriptive text, to a separate document, maintained by the > Institute >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > group. >>>=20 >>> NEW: >>>=20 >>> This version >>> removes the entire EFM-CU-MIB module along with the relevant >>> descriptive >>> text. That MIB module will be part of a separate document, > maintained >>> by >>> the Institute of Electrical and Electronics Engineers (IEEE) > 802.3. >>> working group. >>>=20 >>> 2. In Section 3.1: >>>=20 >>> The EFM-CU-MIB module defined in the previous version of this >>> document, along with the relevant descriptive text, is now moved > to a >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > [802.3.1], >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. >>>=20 >>> - Instead of 'the previous version of this document' we should just > say >>> [RFC5066]. >>> - We should provide a more updated version of the IEEE standard > which >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > would >>> be fine, but the access is restricted. I suggest to ask advice from >>> Howard Frazier. >>>=20 >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are >>> required because it's the same root already allocated in RFC 5066. >>>=20 >>> OLD: >>>=20 >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>>=20 >>> NEW: >>>=20 >>> New action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>>=20 >>> Regards, >>>=20 >>> Dan >>>=20 >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Sun Jan 6 01:09:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE73521F880E for ; Sun, 6 Jan 2013 01:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62pOCuEus-F6 for ; Sun, 6 Jan 2013 01:09:57 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1D47621F8734 for ; Sun, 6 Jan 2013 01:09:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAKUvoFCHCzI1/2dsb2JhbAA7BgOBf0ojwGmBCIIeAQEBAQMSG0wQAgEIDQQEAQELFgcHMhQJCAEBBAENBQgBGYdWAw8BnjCSHwiJWYwmgw2CS2EDnAmKNoJvghk X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208,217";a="338566652" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jan 2013 04:02:01 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jan 2013 03:44:46 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Sun, 6 Jan 2013 04:09:57 -0500 From: "Romascanu, Dan (Dan)" To: ietfdbh , 'Edward Beili' , 'Benoit Claise' Thread-Topic: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Thread-Index: Ac3o83W9kqh9Sl2TSm6FRU4k/9lYKQADMnYgAIpBGIAAMNZ4EA== Date: Sun, 6 Jan 2013 09:09:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA056E00@AZ-FFEXMB04.global.avaya.com> References: <50E440BA.1010208@cisco.com> <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> <017601cdeaff$5bffe730$13ffb590$@comcast.net> In-Reply-To: <017601cdeaff$5bffe730$13ffb590$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA056E00AZFFEXMB04globala_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 09:10:00 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA056E00AZFFEXMB04globala_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, There is no change in the mib-2 subtree in what concerns the ifCapStackMIB = Module Identity. RFC 5066 defines two MIB modules. One (this one) continues to be maintained= by the IETF. There is no need for a change. The other (EFM-CU-MIB) goes to= the IEEE, and will be relocated with new names under the IEEE802 subtree. = That document is now in Sponsor Ballot by the IEEE-SA. I hope this clarifies the issue. Regards, Dan From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= ietfdbh Sent: Saturday, January 05, 2013 6:45 AM To: 'Edward Beili'; 'Benoit Claise' Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Hi, I think the mib-2 subtree is an Internet-standard subtree, and requires an = RFC to update: SMI Network Management MGMT Codes Internet-standard MIB Registration Procedures RFC Required Description iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) Reference [ RFC1213][RFC2578] If IEEE802 modifies this MIB module that is under mib-2, specifically by ad= ding new objects, ... is it planned that IEEE802 will do so under the current IANA-assigned subtr= ee mib-2, for which IANA has the authority to make assignments, using RFCs? Or is it planned they will relocate the MIB module into the IEEE802 subtree= , where IEEE802 has the authority to make assignments? See RFC4663, section 2.3 and section 3.2 for a previous discussion of this = issue. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsaw= g-bounces@ietf.org] On Behalf Of Edward Beili Sent: Wednesday, January 02, 2013 11:42 AM To: Benoit Claise Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Benoit, Thank you for the comments. I'm not sure I understand the need to change the ifCapStackMIB MODULE-IDENT= ITY value. It has been allocated by IANA as { mib-2 166 } in RFC 5066. Since we did not change the name (or the content) it should stay with the s= ame OID, similar say to MAU-MIB - the last version is defined in RFC 4836, = where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod = MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RF= C 2239. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, January 02, 2013 16:14 To: Edward Beili Cc: opsawg@ietf.org Subject: draft-ietf-opsawg-rfc5066bis-00.txt review Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::=3D { mib-2 166 } NEW -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::=3D { mib-2 XXXX } Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." Editorial 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor) --_000_9904FB1B0159DA42B0B887B7FA8119CA056E00AZFFEXMB04globala_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 <= /p>

There is no change in the= mib-2 subtree in what concerns the ifCapStackMIB Module Identity.

 <= /p>

RFC 5066 defines two MIB = modules. One (this one) continues to be maintained by the IETF. There is no= need for a change. The other (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under the IEEE802 subtree. That docum= ent is now in Sponsor Ballot by the IEEE-SA.

 <= /p>

I hope this clarifies the= issue.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ie= tf.org] On Behalf Of ietfdbh
Sent: Saturday, January 05, 2013 6:45 AM
To: 'Edward Beili'; 'Benoit Claise'
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

 

Hi,

 <= /p>

I think the mib-2 subtree= is an Internet-standard subtree, and requires an RFC to update:=

SMI Network Management MGMT Codes Inte= rnet-standard MIB

Registration Procedures<= o:p>

RFC Required<= o:p>

Description

iso.org.dod.i= nternet.mgmt.mib-2 (1.3.6.1.2.1)

Reference<= /span>

[

RFC1213RFC2578]

 <= /p>

If IEEE802 modifies this = MIB module that is under mib-2, specifically by adding new objects, …=

is it planned that IEEE80= 2 will do so under the current IANA-assigned subtree mib-2, for which IANA = has the authority to make assignments, using RFCs?

Or is it planned they wil= l relocate the MIB module into the IEEE802 subtree, where IEEE802 has the a= uthority to make assignments?

 <= /p>

See RFC4663, section 2.3 = and section 3.2 for a previous discussion of this issue.<= /p>

 <= /p>

David Harrington

= ietfdbh@comcast.net

+1-603-828-1401<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili
Sent: Wednesday, January 02, 2013 11:42 AM
To: Benoit Claise
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review

 

Benoit,=

Thank you for the comment= s.

 <= /p>

I’m not sure I unde= rstand the need to change the ifCapStackMIB MODULE-IDENTITY value.

It has been allocated by = IANA as { mib-2 166 } in RFC 5066.

 <= /p>

Since we did not change t= he name (or the content) it should stay with the same OID, similar say to M= AU-MIB – the last version is defined in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODUL= E-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 223= 9.

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, January 02, 2013 16:14
To: Edward Beili
Cc: opsawg@ietf.org
Subject: draft-ietf-opsawg-rfc5066bis-00.txt review

 

Ed,

Here is my draft-ietf-opsawg-rfc5066bis-00.txt review


1.
OLD

  -- EdNote: Replace XXXX with the actual RFC number &
   -- remove this note
 
       ::=3D { mib-2 166 }

NEW


  -- EdNote: Replace XXXX with the actual RFC number &


   -- remove this note


 


       ::=3D { mib-2 XXXX }



Consequently, the IANA considerations section need to be changed/<=
/o:p>


7.  IANA Considerations


 


   Object identifier 166 for the ifCapStackMIB MODULE-IDENTI=
TY have been


   allocated by IANA in the MIB-2 sub-tree.


2.


I don't believe that you need the following REVISION


       REVISION    "=
200711070000Z"  -- November 07, 2007


       DESCRIPTION "Initial version=
, published as RFC 5066." 




Editorial

1.

OLD


Abstract


 


   This document defines Management Information Base (MIB) m=
odule for


   use with network management protocols in TCP/IP-based int=
ernets.


NEW


Abstract


 


   This document defines a Management Information Base (MIB)=
 module for


   use with network management protocols in TCP/IP-based int=
ernets.


2.

OLD


   In addition the Security Considerations section was updat=
ed to


  


 


NEW


   In addition, the Security Considerations section was upda=
ted to


 


 


 


Regards, Benoit (as a contributor)
--_000_9904FB1B0159DA42B0B887B7FA8119CA056E00AZFFEXMB04globala_-- From ietfdbh@comcast.net Sun Jan 6 06:51:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9221F8765 for ; Sun, 6 Jan 2013 06:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgR7CbTXvCT for ; Sun, 6 Jan 2013 06:51:03 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id DA1FB21F8703 for ; Sun, 6 Jan 2013 06:51:02 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id kcyR1k0031vXlb855er2xs; Sun, 06 Jan 2013 14:51:02 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta17.westchester.pa.mail.comcast.net with comcast id ker11k00B3Ecudz3der1Pj; Sun, 06 Jan 2013 14:51:02 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Edward Beili'" , "'Benoit Claise'" References: <50E440BA.1010208@cisco.com> <4087887712E5C648B9F72BB9D912FD4602500BF488CB@il-mail07.actelis.net> <017601cdeaff$5bffe730$13ffb590$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA056E00@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA056E00@AZ-FFEXMB04.global.avaya.com> Date: Sun, 6 Jan 2013 09:51:03 -0500 Message-ID: <01b301cdec1d$4048ec20$c0dac460$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B4_01CDEBF3.57763F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9SFqD/JFHsd5+IABpPTgc6/Z9hACPaeowAYh628MCWZpRy5g6HUyg Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357483862; bh=d/zri66vd/C7L0dHweymfrJE7TLKto9+hxBf+SeWgPY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=oDOQIqiTxKPZRXwN9tRJP/SoU1NhdC6mxGOESeisdddQIZho2KIiKbsJgfYhxMxqh ni3FqsP5kCc6d9Mnmi6BIdrZKYc3kZOWC66rLpgnkCuQ/VXcEgjJ19M7JstNLuSLrQ qmyB23jA+w6Hs57bszl81ARTkFZ/sSmEt33cDZBxjvX2a4GzNGPPAI1N8MX1d40Few Aq2dLHmvKfNkQeqITkVikMOTEwKRbtnrxh9tWnmlQ0JN5ne38gxqwsa/9o/AK9SEtr K5my7FM1DG0ALZ2TjeCVSalGxWoEy9KjGO2dE5WwVYNXR8gWC/PLyCUnmN/EDxOrAB SkHldbnWTghaQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 14:51:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B4_01CDEBF3.57763F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It does. Thank you. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Sunday, January 06, 2013 4:10 AM To: ietfdbh; 'Edward Beili'; 'Benoit Claise' Cc: opsawg@ietf.org Subject: RE: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Hi David, There is no change in the mib-2 subtree in what concerns the ifCapStackMIB Module Identity. RFC 5066 defines two MIB modules. One (this one) continues to be maintained by the IETF. There is no need for a change. The other (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA. I hope this clarifies the issue. Regards, Dan From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of ietfdbh Sent: Saturday, January 05, 2013 6:45 AM To: 'Edward Beili'; 'Benoit Claise' Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Hi, I think the mib-2 subtree is an Internet-standard subtree, and requires an RFC to update: SMI Network Management MGMT Codes Internet-standard MIB Registration Procedures RFC Required Description iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) Reference [ RFC1213][ RFC2578] If IEEE802 modifies this MIB module that is under mib-2, specifically by adding new objects, . is it planned that IEEE802 will do so under the current IANA-assigned subtree mib-2, for which IANA has the authority to make assignments, using RFCs? Or is it planned they will relocate the MIB module into the IEEE802 subtree, where IEEE802 has the authority to make assignments? See RFC4663, section 2.3 and section 3.2 for a previous discussion of this issue. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Wednesday, January 02, 2013 11:42 AM To: Benoit Claise Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt review Benoit, Thank you for the comments. I'm not sure I understand the need to change the ifCapStackMIB MODULE-IDENTITY value. It has been allocated by IANA as { mib-2 166 } in RFC 5066. Since we did not change the name (or the content) it should stay with the same OID, similar say to MAU-MIB - the last version is defined in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC 3636, RFC 2668 and RFC 2239. Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, January 02, 2013 16:14 To: Edward Beili Cc: opsawg@ietf.org Subject: draft-ietf-opsawg-rfc5066bis-00.txt review Ed, Here is my draft-ietf-opsawg-rfc5066bis-00.txt review 1. OLD -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 166 } NEW -- EdNote: Replace XXXX with the actual RFC number & -- remove this note ::= { mib-2 XXXX } Consequently, the IANA considerations section need to be changed/ 7. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. 2. I don't believe that you need the following REVISION REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." Editorial 1. OLD Abstract This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. NEW Abstract This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. 2. OLD In addition the Security Considerations section was updated to NEW In addition, the Security Considerations section was updated to Regards, Benoit (as a contributor) ------=_NextPart_000_01B4_01CDEBF3.57763F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It does. Thank you.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: = Sunday, January 06, 2013 4:10 AM
To: ietfdbh; 'Edward Beili'; = 'Benoit Claise'
Cc: opsawg@ietf.org
Subject: RE: = [OPSAWG] draft-ietf-opsawg-rfc5066bis-00.txt = review

 

Hi David,

 

There is no change in the mib-2 subtree in what concerns the = ifCapStackMIB Module Identity.

 

RFC 5066 defines two MIB modules. One (this one) continues to be = maintained by the IETF. There is no need for a change. The other = (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names = under the IEEE802 subtree. That document is now in Sponsor Ballot by the = IEEE-SA.

 

I hope this clarifies the issue.

 

Regards,

 

Dan

 

 

 

 

Hi,

 

I think the mib-2 subtree is an Internet-standard subtree, and = requires an RFC to update:

SMI Network Management MGMT Codes Internet-standard = MIB

Registration Procedures

RFC = Required

Description

iso.org.dod.internet.mgmt.mib-2 = (1.3.6.1.2.1)

Reference

[

RFC1213][RFC2578]

 

If IEEE802 modifies this MIB module that is under mib-2, specifically = by adding new objects, …

is it planned that IEEE802 will do so under the current IANA-assigned = subtree mib-2, for which IANA has the authority to make assignments, = using RFCs?

Or is it planned they will relocate the MIB module into the IEEE802 = subtree, where IEEE802 has the authority to make = assignments?

 

See RFC4663, section 2.3 and section 3.2 for a previous discussion of = this issue.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

 

Benoit,

Thank you for the comments.

 

I’m not sure I understand the need to change the ifCapStackMIB = MODULE-IDENTITY value.

It has been allocated by IANA as { mib-2 166 } in RFC = 5066.

 

Since we did not change the name (or the content) it should stay with = the same OID, similar say to MAU-MIB – the last version is defined = in RFC 4836, where mauMod MODULE-IDENTITY is { mib-2 26 6 }, exactly the = same as mauMod MODULE-IDENTITY in the RFCs it obsoleted, such as RFC = 3636, RFC 2668 and RFC 2239.

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Wednesday, January 02, 2013 16:14
To: Edward = Beili
Cc: opsawg@ietf.org
Subject: = draft-ietf-opsawg-rfc5066bis-00.txt = review

 

Ed,

Here is my = draft-ietf-opsawg-rfc5066bis-00.txt = review


1.
OLD

  -- EdNote: Replace =
XXXX with the actual RFC number &
   =
-- remove this =
note
 
   &=
nbsp;   ::=3D { mib-2 166 }

NEW

  -- EdNote: =
Replace XXXX with the actual RFC number =
&
   -- remove this =
note
 
   &=
nbsp;   ::=3D { mib-2 XXXX }


Consequently, the IANA considerations = section need to be changed/

7.  IANA =
Considerations
 
 &nb=
sp; Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have =
been
   allocated by IANA in the MIB-2 =
sub-tree.

2.

I =
don't believe that you need the following =
REVISION
       =
REVISION    "200711070000Z"  -- November =
07, 2007
       =
DESCRIPTION "Initial version, published as RFC 5066." =


Editorial
1.
OLD

Ab=
stract
 
   =
This document defines Management Information Base (MIB) module =
for
   use with network management =
protocols in TCP/IP-based internets.

NEW

Abstract
 
   This document defines a =
Management Information Base (MIB) module =
for
   use with network management =
protocols in TCP/IP-based internets.

2.
OLD

   In addition =
the Security Considerations section was updated =
to
  =

 
NEW
   In addition, the Security Considerations section was = updated = to
 
 
 
Regards, Benoit (as a =
contributor)
------=_NextPart_000_01B4_01CDEBF3.57763F80-- From dromasca@avaya.com Mon Jan 7 07:23:17 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C7B21F8936 for ; Mon, 7 Jan 2013 07:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.339 X-Spam-Level: X-Spam-Status: No, score=-103.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQfCF67jWGBv for ; Mon, 7 Jan 2013 07:23:15 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7903B21F8751 for ; Mon, 7 Jan 2013 07:23:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIbQt1CHCzI1/2dsb2JhbAA7CYF/bb0ZFnOCHgEBAQEDAQEBDyg0CwwEAgEIDQQEAQELFAkHJwsUCQgBAQQBDQUIGoduAQuhe50IBIxSg05hA5wOijeCcoIh X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="383306053" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jan 2013 10:13:42 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jan 2013 09:58:07 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 10:23:21 -0500 From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Edward Beili , "opsawg@ietf.org" Thread-Topic: comments on draft-ietf-opsawg-rfc5066bis-00.txt Thread-Index: Ac3pyzXpo+zBWXaORXK/ZykDK2ItfQAD1e3QAABB2JAAw8vo0A== Date: Mon, 7 Jan 2013 15:23:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA059292@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hfrazier@broadcom.com" Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:23:17 -0000 Hi Ed, Please issue the next version of the draft - I would like to enter my Spons= or Ballot comment in the next couple of days.=20 Thanks and Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Thursday, January 03, 2013 8:00 PM > To: Edward Beili; opsawg@ietf.org > Cc: hfrazier@broadcom.com > Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >=20 > Hi Ed, >=20 > > 3. You probably meant "No action is required from IANA ..." >=20 > Of course, thanks for catching this. >=20 >=20 > > 4. Shall I wait for other comments or should I just issue the next > > version of the draft? > > >=20 > Let us wait for a couple of days. Hopefully we will get an answer from > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft, > and maybe other comments from the OPSAWG or the IEEE folks. >=20 > Please issue a revised version by the start of the next week, as I plan > to enter my Sponsor Ballot comment on the IEEE document, and I need a > reference to the best IETF I-D available at that moment. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: Thursday, January 03, 2013 7:55 PM > > To: Romascanu, Dan (Dan); opsawg@ietf.org > > Cc: hfrazier@broadcom.com > > Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt > > > > Dan, > > Thank you for the comments, I agree with everything, except for the > > following: > > > > 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > > 802.3 would provide a publically accessible link. > > > > 3. You probably meant "No action is required from IANA ..." instead of > > "New action is required form IANA ...", i.e. the correct paragraph > > would > > be: > > > > OLD: > > > > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been > > allocated by IANA in the MIB-2 sub-tree. > > > > NEW: > > > > No action is required from IANA as the OID for ifCapStackMIB > > MODULE- IDENTITY > > was already allocated in [RFC5066]. > > > > 4. Shall I wait for other comments or should I just issue the next > > version of the draft? > > > > Regards, > > -E. > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of Romascanu, Dan (Dan) > > Sent: Thursday, January 03, 2013 17:59 > > To: opsawg@ietf.org > > Cc: hfrazier@broadcom.com > > Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > > > > > > Thanks to Ed Beili for undertaking this work. > > > > A few comments: > > > > 1. In the Abstract you are making the statement that this > > specification moves the EFM-CU-MIB module to an IEEE document. In fact > > the IETF does not have the rights to do such a move alone, this > > document should rather just recognize this move. > > > > Suggested change: > > > > OLD: > > > > It amends that specification by moving the entire EFM-CU- > > MIB module along with the relevant descriptive text, to a separate > > document, maintained by the Institute of Electrical and Electronics > > Engineers (IEEE) 802.3.1 working group. > > > > NEW: > > > > It amends that specification by taking out the entire EFM-CU- > > MIB module along with the relevant descriptive text. That MIB > module > > will be part of a separate document, maintained by the Institute of > > Electrical and Electronics Engineers (IEEE) 802.3 working group. > > > > Also in Section 1: > > > > OLD: > > > > This > > version moves the entire EFM-CU-MIB module along with the relevant > > descriptive text, to a separate document, maintained by the > Institute > > of Electrical and Electronics Engineers (IEEE) 802.3.1 working > group. > > > > NEW: > > > > This version > > removes the entire EFM-CU-MIB module along with the relevant > > descriptive > > text. That MIB module will be part of a separate document, > > maintained by > > the Institute of Electrical and Electronics Engineers (IEEE) 802.3. > > working group. > > > > 2. In Section 3.1: > > > > The EFM-CU-MIB module defined in the previous version of this > > document, along with the relevant descriptive text, is now moved to > a > > separate, IEEE maintained document, IEEE Std 802.3.1-2011 > [802.3.1], > > which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. > > > > - Instead of 'the previous version of this document' we should just > > say [RFC5066]. > > - We should provide a more updated version of the IEEE standard which > > contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > > would be fine, but the access is restricted. I suggest to ask advice > > from Howard Frazier. > > > > 3. I suggest that Section 7 mentions that no (new) IANA actions are > > required because it's the same root already allocated in RFC 5066. > > > > OLD: > > > > Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been > > allocated by IANA in the MIB-2 sub-tree. > > > > NEW: > > > > New action is required from IANA as the OID for ifCapStackMIB > > MODULE- IDENTITY > > was already allocated in [RFC5066]. > > > > Regards, > > > > Dan > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From sob@sobco.com Mon Jan 7 07:40:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088821F890E for ; Mon, 7 Jan 2013 07:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4l-MA5EOTd7M for ; Mon, 7 Jan 2013 07:40:34 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id E4CD921F8936 for ; Mon, 7 Jan 2013 07:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 217D49085BA; Mon, 7 Jan 2013 10:40:27 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m5NdYZotWEe; Mon, 7 Jan 2013 10:40:25 -0500 (EST) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 400FE9085AB; Mon, 7 Jan 2013 10:40:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Scott O Bradner In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA059292@AZ-FFEXMB04.global.avaya.com> Date: Mon, 7 Jan 2013 10:40:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44DCFE8C-0F06-48B7-8E52-6AA39812CCB6@sobco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA059292@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1499) Cc: "opsawg@ietf.org" , Edward Beili , "hfrazier@broadcom.com" Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:40:35 -0000 please revive the unused references while you are at it Scott On Jan 7, 2013, at 10:23 AM, "Romascanu, Dan (Dan)" = wrote: > Hi Ed, >=20 > Please issue the next version of the draft - I would like to enter my = Sponsor Ballot comment in the next couple of days.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf >> Of Romascanu, Dan (Dan) >> Sent: Thursday, January 03, 2013 8:00 PM >> To: Edward Beili; opsawg@ietf.org >> Cc: hfrazier@broadcom.com >> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >>=20 >> Hi Ed, >>=20 >>> 3. You probably meant "No action is required from IANA ..." >>=20 >> Of course, thanks for catching this. >>=20 >>=20 >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>>=20 >>=20 >> Let us wait for a couple of days. Hopefully we will get an answer = from >> Howard concerning a better reference for the IEEE 802.3.1a Rev 2 = draft, >> and maybe other comments from the OPSAWG or the IEEE folks. >>=20 >> Please issue a revised version by the start of the next week, as I = plan >> to enter my Sponsor Ballot comment on the IEEE document, and I need a >> reference to the best IETF I-D available at that moment. >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Edward Beili [mailto:EdwardB@actelis.com] >>> Sent: Thursday, January 03, 2013 7:55 PM >>> To: Romascanu, Dan (Dan); opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt >>>=20 >>> Dan, >>> Thank you for the comments, I agree with everything, except for the >>> following: >>>=20 >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE >>> 802.3 would provide a publically accessible link. >>>=20 >>> 3. You probably meant "No action is required from IANA ..." instead = of >>> "New action is required form IANA ...", i.e. the correct paragraph >>> would >>> be: >>>=20 >>> OLD: >>>=20 >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have >> been >>> allocated by IANA in the MIB-2 sub-tree. >>>=20 >>> NEW: >>>=20 >>> No action is required from IANA as the OID for ifCapStackMIB >>> MODULE- IDENTITY >>> was already allocated in [RFC5066]. >>>=20 >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>>=20 >>> Regards, >>> -E. >>>=20 >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >>> Behalf Of Romascanu, Dan (Dan) >>> Sent: Thursday, January 03, 2013 17:59 >>> To: opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >>>=20 >>>=20 >>> Thanks to Ed Beili for undertaking this work. >>>=20 >>> A few comments: >>>=20 >>> 1. In the Abstract you are making the statement that this >>> specification moves the EFM-CU-MIB module to an IEEE document. In = fact >>> the IETF does not have the rights to do such a move alone, this >>> document should rather just recognize this move. >>>=20 >>> Suggested change: >>>=20 >>> OLD: >>>=20 >>> It amends that specification by moving the entire EFM-CU- >>> MIB module along with the relevant descriptive text, to a separate >>> document, maintained by the Institute of Electrical and = Electronics >>> Engineers (IEEE) 802.3.1 working group. >>>=20 >>> NEW: >>>=20 >>> It amends that specification by taking out the entire EFM-CU- >>> MIB module along with the relevant descriptive text. That MIB >> module >>> will be part of a separate document, maintained by the Institute = of >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. >>>=20 >>> Also in Section 1: >>>=20 >>> OLD: >>>=20 >>> This >>> version moves the entire EFM-CU-MIB module along with the relevant >>> descriptive text, to a separate document, maintained by the >> Institute >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working >> group. >>>=20 >>> NEW: >>>=20 >>> This version >>> removes the entire EFM-CU-MIB module along with the relevant >>> descriptive >>> text. That MIB module will be part of a separate document, >>> maintained by >>> the Institute of Electrical and Electronics Engineers (IEEE) = 802.3. >>> working group. >>>=20 >>> 2. In Section 3.1: >>>=20 >>> The EFM-CU-MIB module defined in the previous version of this >>> document, along with the relevant descriptive text, is now moved = to >> a >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 >> [802.3.1], >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. >>>=20 >>> - Instead of 'the previous version of this document' we should just >>> say [RFC5066]. >>> - We should provide a more updated version of the IEEE standard = which >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot >>> would be fine, but the access is restricted. I suggest to ask advice >>> from Howard Frazier. >>>=20 >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are >>> required because it's the same root already allocated in RFC 5066. >>>=20 >>> OLD: >>>=20 >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have >> been >>> allocated by IANA in the MIB-2 sub-tree. >>>=20 >>> NEW: >>>=20 >>> New action is required from IANA as the OID for ifCapStackMIB >>> MODULE- IDENTITY >>> was already allocated in [RFC5066]. >>>=20 >>> Regards, >>>=20 >>> Dan >>>=20 >>>=20 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Mon Jan 7 07:57:51 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043F21F8614 for ; Mon, 7 Jan 2013 07:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.382 X-Spam-Level: X-Spam-Status: No, score=-103.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXnt0cGHGbOB for ; Mon, 7 Jan 2013 07:57:51 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8D121F842F for ; Mon, 7 Jan 2013 07:57:50 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAKUvoFCHCzI1/2dsb2JhbAA7CYF/bcBpgQiCHgEBAQEDAQEBDyg0CwwEAgEIDQQEAQEBChQJBycLFAkIAQEEDgUIGodoAQqeJpt8BIwmhVhhA5wJijaCb4IZ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="338729559" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jan 2013 10:49:54 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jan 2013 10:32:40 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0318.004; Mon, 7 Jan 2013 10:57:55 -0500 From: "Romascanu, Dan (Dan)" To: Scott O Bradner Thread-Topic: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt Thread-Index: Ac3pyzXpo+zBWXaORXK/ZykDK2ItfQAD1e3QAABB2JAAw8vo0AALHPKAAAnxvgA= Date: Mon, 7 Jan 2013 15:57:54 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA059337@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com> <4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA059292@AZ-FFEXMB04.global.avaya.com> <44DCFE8C-0F06-48B7-8E52-6AA39812CCB6@sobco.com> In-Reply-To: <44DCFE8C-0F06-48B7-8E52-6AA39812CCB6@sobco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , Edward Beili , "hfrazier@broadcom.com" Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:57:51 -0000 Hi Scott,=20 Running idnits does not result in any unused references. We have a problem = with [802.3.1] which should be IMO the more recent updated draft document, = but this one is now in IEEE ballot and restricted access. We are expecting = an answer from Howard Frazier on this matter, but IMO we should not delay t= he submission for this, we can improve this reference later.=20 Regards, Dan > -----Original Message----- > From: Scott O Bradner [mailto:sob@sobco.com] > Sent: Monday, January 07, 2013 5:40 PM > To: Romascanu, Dan (Dan) > Cc: Edward Beili; opsawg@ietf.org; hfrazier@broadcom.com > Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >=20 > please revive the unused references while you are at it >=20 > Scott >=20 > On Jan 7, 2013, at 10:23 AM, "Romascanu, Dan (Dan)" > wrote: >=20 > > Hi Ed, > > > > Please issue the next version of the draft - I would like to enter my > Sponsor Ballot comment in the next couple of days. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > >> Behalf Of Romascanu, Dan (Dan) > >> Sent: Thursday, January 03, 2013 8:00 PM > >> To: Edward Beili; opsawg@ietf.org > >> Cc: hfrazier@broadcom.com > >> Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > >> > >> Hi Ed, > >> > >>> 3. You probably meant "No action is required from IANA ..." > >> > >> Of course, thanks for catching this. > >> > >> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >> > >> Let us wait for a couple of days. Hopefully we will get an answer > >> from Howard concerning a better reference for the IEEE 802.3.1a Rev 2 > >> draft, and maybe other comments from the OPSAWG or the IEEE folks. > >> > >> Please issue a revised version by the start of the next week, as I > >> plan to enter my Sponsor Ballot comment on the IEEE document, and I > >> need a reference to the best IETF I-D available at that moment. > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >> > >>> -----Original Message----- > >>> From: Edward Beili [mailto:EdwardB@actelis.com] > >>> Sent: Thursday, January 03, 2013 7:55 PM > >>> To: Romascanu, Dan (Dan); opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> Dan, > >>> Thank you for the comments, I agree with everything, except for the > >>> following: > >>> > >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > >>> 802.3 would provide a publically accessible link. > >>> > >>> 3. You probably meant "No action is required from IANA ..." instead > >>> of "New action is required form IANA ...", i.e. the correct > >>> paragraph would > >>> be: > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > >> been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> No action is required from IANA as the OID for ifCapStackMIB > >>> MODULE- IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >>> Regards, > >>> -E. > >>> > >>> -----Original Message----- > >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > >>> Behalf Of Romascanu, Dan (Dan) > >>> Sent: Thursday, January 03, 2013 17:59 > >>> To: opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> > >>> Thanks to Ed Beili for undertaking this work. > >>> > >>> A few comments: > >>> > >>> 1. In the Abstract you are making the statement that this > >>> specification moves the EFM-CU-MIB module to an IEEE document. In > >>> fact the IETF does not have the rights to do such a move alone, this > >>> document should rather just recognize this move. > >>> > >>> Suggested change: > >>> > >>> OLD: > >>> > >>> It amends that specification by moving the entire EFM-CU- > >>> MIB module along with the relevant descriptive text, to a separate > >>> document, maintained by the Institute of Electrical and > Electronics > >>> Engineers (IEEE) 802.3.1 working group. > >>> > >>> NEW: > >>> > >>> It amends that specification by taking out the entire EFM-CU- > >>> MIB module along with the relevant descriptive text. That MIB > >> module > >>> will be part of a separate document, maintained by the Institute > of > >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. > >>> > >>> Also in Section 1: > >>> > >>> OLD: > >>> > >>> This > >>> version moves the entire EFM-CU-MIB module along with the relevant > >>> descriptive text, to a separate document, maintained by the > >> Institute > >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > >> group. > >>> > >>> NEW: > >>> > >>> This version > >>> removes the entire EFM-CU-MIB module along with the relevant > >>> descriptive > >>> text. That MIB module will be part of a separate document, > >>> maintained by > >>> the Institute of Electrical and Electronics Engineers (IEEE) > 802.3. > >>> working group. > >>> > >>> 2. In Section 3.1: > >>> > >>> The EFM-CU-MIB module defined in the previous version of this > >>> document, along with the relevant descriptive text, is now moved > >>> to > >> a > >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > >> [802.3.1], > >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. > >>> > >>> - Instead of 'the previous version of this document' we should just > >>> say [RFC5066]. > >>> - We should provide a more updated version of the IEEE standard > >>> which contains the IEEE-EFM-CU-MIB - the document now in Sponsor > >>> Ballot would be fine, but the access is restricted. I suggest to ask > >>> advice from Howard Frazier. > >>> > >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are > >>> required because it's the same root already allocated in RFC 5066. > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > >> been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> New action is required from IANA as the OID for ifCapStackMIB > >>> MODULE- IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> Regards, > >>> > >>> Dan > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg From internet-drafts@ietf.org Mon Jan 7 14:27:09 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02ED11E80AD; Mon, 7 Jan 2013 14:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXNbDdr01+un; Mon, 7 Jan 2013 14:27:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1233C11E809A; Mon, 7 Jan 2013 14:27:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107222709.26428.15743.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 14:27:09 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 22:27:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Interface Stack Capability MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-01.txt Pages : 15 Date : 2013-01-07 Abstract: This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document defines a set of objects, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. This document obsoletes RFC 5066. It amends that specification by taking out the entire EFM- CU-MIB module along with the relevant descriptive text. That MIB module will be part of a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-rfc5066bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfc@btconnect.com Tue Jan 8 02:20:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541B21F8904 for ; Tue, 8 Jan 2013 02:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPRXTnPSZq24 for ; Tue, 8 Jan 2013 02:20:34 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9218521F8900 for ; Tue, 8 Jan 2013 02:20:34 -0800 (PST) Received: from mail276-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 8 Jan 2013 10:20:34 +0000 Received: from mail276-tx2 (localhost [127.0.0.1]) by mail276-tx2-R.bigfish.com (Postfix) with ESMTP id 0A225DE0196; Tue, 8 Jan 2013 10:20:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I1521I148cI542I1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh304l1155h) Received: from mail276-tx2 (localhost.localdomain [127.0.0.1]) by mail276-tx2 (MessageSwitch) id 135764043155688_3958; Tue, 8 Jan 2013 10:20:31 +0000 (UTC) Received: from TX2EHSMHS013.bigfish.com (unknown [10.9.14.248]) by mail276-tx2.bigfish.com (Postfix) with ESMTP id 0AA17AC004E; Tue, 8 Jan 2013 10:20:31 +0000 (UTC) Received: from AMXPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.69) by TX2EHSMHS013.bigfish.com (10.9.99.113) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 8 Jan 2013 10:20:29 +0000 Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.242.9.165) with Microsoft SMTP Server (TLS) id 14.16.245.2; Tue, 8 Jan 2013 10:20:23 +0000 Message-ID: <017d01cded89$749f1ea0$4001a8c0@gateway.2wire.net> From: t.petch To: Scott O Bradner References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> <19B24B5B-D92B-471B-ABCE-8C67E8F11AD6@sobco.com> Date: Tue, 8 Jan 2013 10:17:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com Cc: opsawg@ietf.org, Edward Beili Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 10:20:35 -0000 ---- Original Message ----- From: "Scott O Bradner" To: "t.petch" Cc: "Romascanu, Dan (Dan)" ; "Edward Beili" ; Sent: Saturday, January 05, 2013 2:25 PM On Jan 5, 2013, at 7:45 AM, t.petch wrote: > I wonder if this I-D should really supersede RFC5066. I would rather > see RFC5066 become Historic with this as an Updates. a historic document does not exist (standards track wise) so there would be nothing to update - also- an update would not be a complete replacement (i.e. some of the old document would still be in force) - is that the case here (i.e. do you think that this is not a full replacement?) Scott As Dan said, "RFC 5066 defines two MIB modules. One (this one) continues to be maintained by the IETF. There is no need for a change. The other (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA." so the vast majority of RFC5066 vanishes into IEEE and is transformed therein. The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence the reuse of the number in the mib tree). I do not know what the best way to describe this in our documentation is! As to Copyright, RFC5066 has one editor but the work was "greatly advanced by the contributions of the following people" which lists eight such people, so no, I do not think that the editor of RFC5066bis can make the necessary grant. RFC5066 predates the change of rules, increasing the grants, by a year. Tom Petch > > Should the Copyright carry the caveat about old material for which the > current rules may not apply? Since this MIB Module is going to see > extensive use by another SDO, this seems particularly relevant. the author of the old doc is the author of the new doc and is submitting the new doc under the current rules (and gave himself permission to do that) Scott > Tom Petch > > > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "Edward Beili" ; > Cc: > Sent: Thursday, January 03, 2013 6:00 PM > >> Hi Ed, >> >>> 3. You probably meant "No action is required from IANA ..." >> >> Of course, thanks for catching this. >> >> >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>> >> >> Let us wait for a couple of days. Hopefully we will get an answer from > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft, > and maybe other comments from the OPSAWG or the IEEE folks. >> >> Please issue a revised version by the start of the next week, as I > plan to enter my Sponsor Ballot comment on the IEEE document, and I need > a reference to the best IETF I-D available at that moment. >> >> Thanks and Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: Edward Beili [mailto:EdwardB@actelis.com] >>> Sent: Thursday, January 03, 2013 7:55 PM >>> To: Romascanu, Dan (Dan); opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt >>> >>> Dan, >>> Thank you for the comments, I agree with everything, except for the >>> following: >>> >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE >>> 802.3 would provide a publically accessible link. >>> >>> 3. You probably meant "No action is required from IANA ..." instead > of >>> "New action is required form IANA ...", i.e. the correct paragraph > would >>> be: >>> >>> OLD: >>> >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>> >>> NEW: >>> >>> No action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>> >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>> >>> Regards, >>> -E. >>> >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf >>> Of Romascanu, Dan (Dan) >>> Sent: Thursday, January 03, 2013 17:59 >>> To: opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >>> >>> >>> Thanks to Ed Beili for undertaking this work. >>> >>> A few comments: >>> >>> 1. In the Abstract you are making the statement that this > specification >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF > does >>> not have the rights to do such a move alone, this document should > rather >>> just recognize this move. >>> >>> Suggested change: >>> >>> OLD: >>> >>> It amends that specification by moving the entire EFM-CU- >>> MIB module along with the relevant descriptive text, to a > separate >>> document, maintained by the Institute of Electrical and > Electronics >>> Engineers (IEEE) 802.3.1 working group. >>> >>> NEW: >>> >>> It amends that specification by taking out the entire EFM-CU- >>> MIB module along with the relevant descriptive text. That MIB > module >>> will be part of a separate document, maintained by the Institute > of >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. >>> >>> Also in Section 1: >>> >>> OLD: >>> >>> This >>> version moves the entire EFM-CU-MIB module along with the > relevant >>> descriptive text, to a separate document, maintained by the > Institute >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > group. >>> >>> NEW: >>> >>> This version >>> removes the entire EFM-CU-MIB module along with the relevant >>> descriptive >>> text. That MIB module will be part of a separate document, > maintained >>> by >>> the Institute of Electrical and Electronics Engineers (IEEE) > 802.3. >>> working group. >>> >>> 2. In Section 3.1: >>> >>> The EFM-CU-MIB module defined in the previous version of this >>> document, along with the relevant descriptive text, is now moved > to a >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > [802.3.1], >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. >>> >>> - Instead of 'the previous version of this document' we should just > say >>> [RFC5066]. >>> - We should provide a more updated version of the IEEE standard > which >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > would >>> be fine, but the access is restricted. I suggest to ask advice from >>> Howard Frazier. >>> >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are >>> required because it's the same root already allocated in RFC 5066. >>> >>> OLD: >>> >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>> >>> NEW: >>> >>> New action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>> >>> Regards, >>> >>> Dan >>> >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ietfdbh@comcast.net Tue Jan 8 14:07:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A678F11E80AE for ; Tue, 8 Jan 2013 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.137 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuPVBqjf+3b8 for ; Tue, 8 Jan 2013 14:07:43 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCC411E80E7 for ; Tue, 8 Jan 2013 14:07:43 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta04.westchester.pa.mail.comcast.net with comcast id lYMl1k0080ldTLk54a7juA; Tue, 08 Jan 2013 22:07:43 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta04.westchester.pa.mail.comcast.net with comcast id la7h1k0093Ecudz3Qa7hu5; Tue, 08 Jan 2013 22:07:43 +0000 From: "ietfdbh" To: "'t.petch'" , "'Scott O Bradner'" References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> <19B24B5B-D92B-471B-ABCE-8C67E8F11AD6@sobco.com> <017d01cded89$749f1ea0$4001a8c0@gateway.2wire.net> In-Reply-To: <017d01cded89$749f1ea0$4001a8c0@gateway.2wire.net> Date: Tue, 8 Jan 2013 17:07:44 -0500 Message-ID: <026801cdedec$96ce9c40$c46bd4c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM23p9FmINIEFMv+6S30avMTzIL1gHnSfxcAjmoNIwCKt1+wAIVlUEjAhpxm/2VGjprUA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357682863; bh=X5NBQ56wCVq+2Fy7nYFEmJhcpaL19xWjIx+xhrUoph8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=c+hnafqyok4+4rpyC1lrJw8uKTp2mw0hCD7eint367CCpu6pFJG+7cI3TeiYu64Ue LkCUPbUvc76KrEdLkhodNriQcpQB3lUhCeKQ6rVU9ti+Hynsw2oN0wDClAaIPyGM4c bUprgTnx+TebhPOAq8Dk5+x+rLNz7UWuRMbcq6gpQJ3t9wqH3nvM9b0fHP6qEAUVr3 wRFDxr+AdEhfULiygHcNUPftnWLGekQQLQbwITqSr2DxVMnwHr+CKy4L1vDvNc3k8b iOHDdi6Ox6PlfOIwENA+M0r5boB0T/2iKCjN5rgbCQLlsRKnaWU5sJVUbLJ1TQsIuq kaskI81Mr6t2Q== Cc: opsawg@ietf.org, 'Edward Beili' Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 22:07:44 -0000 Hi, I would be careful with assumptions about the existing IETF standards-track MIB vanishing, even if IEEE is going to maintain comparable definitions under an IEEE subtree going forward. Existing devices and managers might support the RFC5066 EFM-CU-MIB, and those devices may never be updated to the new IEEE version. The IETF standards-track EFM-CU-MIB should still be considered a valid MIB module; it just should not be modified going forward. The IEEE version should replace it for new implementations, and the IEEE version could supplement the IETF EFM-CU-MIB in new and updated implementations, to support continued interoperability. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of t.petch Sent: Tuesday, January 08, 2013 5:18 AM To: Scott O Bradner Cc: opsawg@ietf.org; Edward Beili Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt ---- Original Message ----- From: "Scott O Bradner" To: "t.petch" Cc: "Romascanu, Dan (Dan)" ; "Edward Beili" ; Sent: Saturday, January 05, 2013 2:25 PM On Jan 5, 2013, at 7:45 AM, t.petch wrote: > I wonder if this I-D should really supersede RFC5066. I would rather > see RFC5066 become Historic with this as an Updates. a historic document does not exist (standards track wise) so there would be nothing to update - also- an update would not be a complete replacement (i.e. some of the old document would still be in force) - is that the case here (i.e. do you think that this is not a full replacement?) Scott As Dan said, "RFC 5066 defines two MIB modules. One (this one) continues to be maintained by the IETF. There is no need for a change. The other (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA." so the vast majority of RFC5066 vanishes into IEEE and is transformed therein. The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence the reuse of the number in the mib tree). I do not know what the best way to describe this in our documentation is! As to Copyright, RFC5066 has one editor but the work was "greatly advanced by the contributions of the following people" which lists eight such people, so no, I do not think that the editor of RFC5066bis can make the necessary grant. RFC5066 predates the change of rules, increasing the grants, by a year. Tom Petch > > Should the Copyright carry the caveat about old material for which the > current rules may not apply? Since this MIB Module is going to see > extensive use by another SDO, this seems particularly relevant. the author of the old doc is the author of the new doc and is submitting the new doc under the current rules (and gave himself permission to do that) Scott > Tom Petch > > > ----- Original Message ----- > From: "Romascanu, Dan (Dan)" > To: "Edward Beili" ; > Cc: > Sent: Thursday, January 03, 2013 6:00 PM > >> Hi Ed, >> >>> 3. You probably meant "No action is required from IANA ..." >> >> Of course, thanks for catching this. >> >> >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>> >> >> Let us wait for a couple of days. Hopefully we will get an answer from > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 draft, > and maybe other comments from the OPSAWG or the IEEE folks. >> >> Please issue a revised version by the start of the next week, as I > plan to enter my Sponsor Ballot comment on the IEEE document, and I need > a reference to the best IETF I-D available at that moment. >> >> Thanks and Regards, >> >> Dan >> >> >> >>> -----Original Message----- >>> From: Edward Beili [mailto:EdwardB@actelis.com] >>> Sent: Thursday, January 03, 2013 7:55 PM >>> To: Romascanu, Dan (Dan); opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt >>> >>> Dan, >>> Thank you for the comments, I agree with everything, except for the >>> following: >>> >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE >>> 802.3 would provide a publically accessible link. >>> >>> 3. You probably meant "No action is required from IANA ..." instead > of >>> "New action is required form IANA ...", i.e. the correct paragraph > would >>> be: >>> >>> OLD: >>> >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>> >>> NEW: >>> >>> No action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>> >>> 4. Shall I wait for other comments or should I just issue the next >>> version of the draft? >>> >>> Regards, >>> -E. >>> >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf >>> Of Romascanu, Dan (Dan) >>> Sent: Thursday, January 03, 2013 17:59 >>> To: opsawg@ietf.org >>> Cc: hfrazier@broadcom.com >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt >>> >>> >>> Thanks to Ed Beili for undertaking this work. >>> >>> A few comments: >>> >>> 1. In the Abstract you are making the statement that this > specification >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF > does >>> not have the rights to do such a move alone, this document should > rather >>> just recognize this move. >>> >>> Suggested change: >>> >>> OLD: >>> >>> It amends that specification by moving the entire EFM-CU- >>> MIB module along with the relevant descriptive text, to a > separate >>> document, maintained by the Institute of Electrical and > Electronics >>> Engineers (IEEE) 802.3.1 working group. >>> >>> NEW: >>> >>> It amends that specification by taking out the entire EFM-CU- >>> MIB module along with the relevant descriptive text. That MIB > module >>> will be part of a separate document, maintained by the Institute > of >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. >>> >>> Also in Section 1: >>> >>> OLD: >>> >>> This >>> version moves the entire EFM-CU-MIB module along with the > relevant >>> descriptive text, to a separate document, maintained by the > Institute >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > group. >>> >>> NEW: >>> >>> This version >>> removes the entire EFM-CU-MIB module along with the relevant >>> descriptive >>> text. That MIB module will be part of a separate document, > maintained >>> by >>> the Institute of Electrical and Electronics Engineers (IEEE) > 802.3. >>> working group. >>> >>> 2. In Section 3.1: >>> >>> The EFM-CU-MIB module defined in the previous version of this >>> document, along with the relevant descriptive text, is now moved > to a >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > [802.3.1], >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. >>> >>> - Instead of 'the previous version of this document' we should just > say >>> [RFC5066]. >>> - We should provide a more updated version of the IEEE standard > which >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > would >>> be fine, but the access is restricted. I suggest to ask advice from >>> Howard Frazier. >>> >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are >>> required because it's the same root already allocated in RFC 5066. >>> >>> OLD: >>> >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > been >>> allocated by IANA in the MIB-2 sub-tree. >>> >>> NEW: >>> >>> New action is required from IANA as the OID for ifCapStackMIB > MODULE- >>> IDENTITY >>> was already allocated in [RFC5066]. >>> >>> Regards, >>> >>> Dan >>> >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From internet-drafts@ietf.org Wed Jan 9 05:46:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3036E21F8745; Wed, 9 Jan 2013 05:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaLVJATK3Fkk; Wed, 9 Jan 2013 05:46:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF2D21F844A; Wed, 9 Jan 2013 05:46:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130109134620.4905.12138.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 05:46:20 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:46:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : An Overview of Operations, Administration, and Maintenan= ce (OAM) Mechanisms Author(s) : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-08.txt Pages : 33 Date : 2013-01-09 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From talmi@marvell.com Wed Jan 9 05:50:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BB721F8799 for ; Wed, 9 Jan 2013 05:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUYB+JHd6Zv1 for ; Wed, 9 Jan 2013 05:50:58 -0800 (PST) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id AB68121F86CB for ; Wed, 9 Jan 2013 05:50:53 -0800 (PST) From: Tal Mizrahi To: Ronald Bonica , "draft-ietf-opsawg-oam-overview@tools.ietf.org" Date: Wed, 9 Jan 2013 15:50:48 +0200 Thread-Topic: Mail regarding draft-ietf-opsawg-oam-overview Thread-Index: Ac3pzsCsgrMcpMHgSAy7ETWuHNqNWQEoRq5Q Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F92197E7@IL-MB01.marvell.com> References: <2CF4CB03E2AA464BA0982EC92A02CE2501E0394A@BY2PRD0512MB653.namprd05.prod.outlook.com> In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501E0394A@BY2PRD0512MB653.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:50:59 -0000 Hi Ron, Thanks for your comments. We have revised the document following the comments from you and Carlos. http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08 The main changes: - Rewrote the introduction. - Added reference to a few RFCs/standards that were missing or were publish= ed in the last year. - Bug fixes in the reference list. - Changed the order of some of the sections following the comments we recei= ved. Tal. -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Ronald Bonica Sent: Thursday, January 03, 2013 6:24 PM To: draft-ietf-opsawg-oam-overview@tools.ietf.org Cc: opsawg@ietf.org Subject: [OPSAWG] Mail regarding draft-ietf-opsawg-oam-overview Authors, Thanks for submitting this draft and for suffering through the drawn out pr= ocess. The following are a few comments. Section 1 and 1.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D The introduction is harder to parse than it needs to be. In the introductio= n, I think that that you are trying to make the following points: - This memo summarizes IETF OAM mechanisms - An OAM mechanism provides the following laundry list of functions (e.g., = connectivity checking, path discovery, etc.) Provide a definition for each = function. - The scope of this document is limited to OAM mechanisms that operate on t= he data plane. (SNMP is out of bounds). Do I have that much right? If so, would it be possible to craft Sections 1 = and 1.1 so that these points are brought to the forefront? Section 1.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Should every OAM mechanism listed in Table 1 should appear in the bullet = list. Some are missing (e.g., TRACEROUTE). - You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping. - For the most part, the bullet list is a list of tools. The notable except= ion is IPPM, which is a WG, not a tool. Should you replace that bullet item= with the tools that the produce (e.g., OWAMP, TWAMP)? Section 1.3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - The title of this section is inappropriate, because some of the documents= that you list are not on the standards track. Maybe a better title would b= e IETF OAM Documents, Grouped by the OAM mechanism that they support.=20 - If you accept the suggestion listed above, the first column of Table 1 sh= ould specify an OAM mechanism, drawn from the bullet list in Section 1.2. T= he second column should be an RFC number. The third column should be an RFC= title, and the fourth column should be the type. - RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because th= ey all augment the ICMP Destination Unreachable message and their output is= intended for consumption by TRACEROUTE. (While RFC 4950 has something to d= o with MPLS, it is a different mechanism than MPLS LSP PING. Section 2.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Please do a brief scan of the document to make sure that you actually use= all of the acronyms that you define. I found quite a few that are unused. Section 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D The subsections of Section 3 should map to the bullet points in Section 1.2 Section 3.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By default, traceroute sends 3 probes per TTL. However, in most implementat= ions, this is configurable through the command line Nits =3D=3D=3D=3D Please run the nit checker and correct all errors and warnings -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From ietfc@btconnect.com Thu Jan 10 09:35:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AAD21F8A4E for ; Thu, 10 Jan 2013 09:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beQMsRF7ZQ0c for ; Thu, 10 Jan 2013 09:35:00 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1B721F8A41 for ; Thu, 10 Jan 2013 09:34:59 -0800 (PST) Received: from mail13-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.23; Thu, 10 Jan 2013 17:34:58 +0000 Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id E17E71600F3; Thu, 10 Jan 2013 17:34:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I1521I148cI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh304l1155h) Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 1357839295179940_25664; Thu, 10 Jan 2013 17:34:55 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.234]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 4A29AA008B; Thu, 10 Jan 2013 17:34:48 +0000 (UTC) Received: from DB3PRD0711HT004.eurprd07.prod.outlook.com (157.56.254.197) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 10 Jan 2013 17:34:31 +0000 Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.183.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 10 Jan 2013 17:34:30 +0000 Message-ID: <01af01cdef58$6c892460$4001a8c0@gateway.2wire.net> From: t.petch To: ietfdbh , 'Scott O Bradner' References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> <19B24B5B-D92B-471B-ABCE-8C67E8F11AD6@sobco.com> <017d01cded89$749f1ea0$4001a8c0@gateway.2wire.net> <026801cdedec$96ce9c40$c46bd4c0$@comcast.net> Date: Thu, 10 Jan 2013 10:18:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com Cc: opsawg@ietf.org, 'Edward Beili' Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 17:35:01 -0000 ---- Original Message ----- From: "ietfdbh" To: "'t.petch'" ; "'Scott O Bradner'" Cc: ; "'Edward Beili'" Sent: Tuesday, January 08, 2013 10:07 PM > Hi, > > I would be careful with assumptions about the existing IETF standards-track > MIB vanishing, even if IEEE is going to maintain comparable definitions > under an IEEE subtree going forward. > > Existing devices and managers might support the RFC5066 EFM-CU-MIB, and > those devices may never be updated to the new IEEE version. > The IETF standards-track EFM-CU-MIB should still be considered a valid MIB > module; it just should not be modified going forward. > The IEEE version should replace it for new implementations, and the IEEE > version could supplement the IETF EFM-CU-MIB in new and updated > implementations, to support continued interoperability. David So in practical terms, what would you do? Currently the I-D has an 'Obsoletes 5066' which I think wrong, since the new I-D omits the vast mass of 5066; and, as you rightly point out, the EFM-CU-MIB module could well be with us for a long time (and we have no change control over the IEEE module that one day may replace it). Leave 5066 as Standards Track with this as an Updates (which it isn't, its a reproduce a small part thereof unchanged as far as I can see)? I will go on objecting to Obsoletes even if I cannot see what the alternative should be:-) Tom Petch > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of > t.petch > Sent: Tuesday, January 08, 2013 5:18 AM > To: Scott O Bradner > Cc: opsawg@ietf.org; Edward Beili > Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > > ---- Original Message ----- > From: "Scott O Bradner" > To: "t.petch" > Cc: "Romascanu, Dan (Dan)" ; "Edward Beili" > ; > Sent: Saturday, January 05, 2013 2:25 PM > > On Jan 5, 2013, at 7:45 AM, t.petch wrote: > > > I wonder if this I-D should really supersede RFC5066. I would rather > > see RFC5066 become Historic with this as an Updates. > > a historic document does not exist (standards track wise) so there would be > nothing to update - > > also- an update would not be a complete replacement (i.e. some of the old > document would still be in force) - is that the case here (i.e. > do you think that this is not a full replacement?) > > Scott > > As Dan said, > "RFC 5066 defines two MIB modules. One (this one) continues to be maintained > by the IETF. There is no need for a change. The other > (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under > the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA." > > so the vast majority of RFC5066 vanishes into IEEE and is transformed > therein. > > The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence the > reuse of the number in the mib tree). > > I do not know what the best way to describe this in our documentation is! > > As to Copyright, RFC5066 has one editor but the work was "greatly advanced > by the contributions of the following people" > which lists eight such people, so no, I do not think that the editor of > RFC5066bis can make the necessary grant. > > RFC5066 predates the change of rules, increasing the grants, by a year. > > Tom Petch > > > > > Should the Copyright carry the caveat about old material for which the > > current rules may not apply? Since this MIB Module is going to see > > extensive use by another SDO, this seems particularly relevant. > > the author of the old doc is the author of the new doc and is submitting the > new doc under the current rules (and gave himself permission to do that) > > Scott > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Romascanu, Dan (Dan)" > > To: "Edward Beili" ; > > Cc: > > Sent: Thursday, January 03, 2013 6:00 PM > > > >> Hi Ed, > >> > >>> 3. You probably meant "No action is required from IANA ..." > >> > >> Of course, thanks for catching this. > >> > >> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >> > >> Let us wait for a couple of days. Hopefully we will get an answer > from > > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 > draft, > > and maybe other comments from the OPSAWG or the IEEE folks. > >> > >> Please issue a revised version by the start of the next week, as I > > plan to enter my Sponsor Ballot comment on the IEEE document, and I > need > > a reference to the best IETF I-D available at that moment. > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >> > >>> -----Original Message----- > >>> From: Edward Beili [mailto:EdwardB@actelis.com] > >>> Sent: Thursday, January 03, 2013 7:55 PM > >>> To: Romascanu, Dan (Dan); opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> Dan, > >>> Thank you for the comments, I agree with everything, except for the > >>> following: > >>> > >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > >>> 802.3 would provide a publically accessible link. > >>> > >>> 3. You probably meant "No action is required from IANA ..." instead > > of > >>> "New action is required form IANA ...", i.e. the correct paragraph > > would > >>> be: > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > > been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> No action is required from IANA as the OID for ifCapStackMIB > > MODULE- > >>> IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >>> Regards, > >>> -E. > >>> > >>> -----Original Message----- > >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf > >>> Of Romascanu, Dan (Dan) > >>> Sent: Thursday, January 03, 2013 17:59 > >>> To: opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> > >>> Thanks to Ed Beili for undertaking this work. > >>> > >>> A few comments: > >>> > >>> 1. In the Abstract you are making the statement that this > > specification > >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF > > does > >>> not have the rights to do such a move alone, this document should > > rather > >>> just recognize this move. > >>> > >>> Suggested change: > >>> > >>> OLD: > >>> > >>> It amends that specification by moving the entire EFM-CU- > >>> MIB module along with the relevant descriptive text, to a > > separate > >>> document, maintained by the Institute of Electrical and > > Electronics > >>> Engineers (IEEE) 802.3.1 working group. > >>> > >>> NEW: > >>> > >>> It amends that specification by taking out the entire EFM-CU- > >>> MIB module along with the relevant descriptive text. That MIB > > module > >>> will be part of a separate document, maintained by the Institute > > of > >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. > >>> > >>> Also in Section 1: > >>> > >>> OLD: > >>> > >>> This > >>> version moves the entire EFM-CU-MIB module along with the > > relevant > >>> descriptive text, to a separate document, maintained by the > > Institute > >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > > group. > >>> > >>> NEW: > >>> > >>> This version > >>> removes the entire EFM-CU-MIB module along with the relevant > >>> descriptive > >>> text. That MIB module will be part of a separate document, > > maintained > >>> by > >>> the Institute of Electrical and Electronics Engineers (IEEE) > > 802.3. > >>> working group. > >>> > >>> 2. In Section 3.1: > >>> > >>> The EFM-CU-MIB module defined in the previous version of this > >>> document, along with the relevant descriptive text, is now moved > > to a > >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > > [802.3.1], > >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. > >>> > >>> - Instead of 'the previous version of this document' we should just > > say > >>> [RFC5066]. > >>> - We should provide a more updated version of the IEEE standard > > which > >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > > would > >>> be fine, but the access is restricted. I suggest to ask advice from > >>> Howard Frazier. > >>> > >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are > >>> required because it's the same root already allocated in RFC 5066. > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > > been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> New action is required from IANA as the OID for ifCapStackMIB > > MODULE- > >>> IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> Regards, > >>> > >>> Dan > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > >> > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From ietfdbh@comcast.net Thu Jan 10 12:13:31 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3011F21F868D for ; Thu, 10 Jan 2013 12:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.077 X-Spam-Level: X-Spam-Status: No, score=-100.077 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iImNaQa+cYUC for ; Thu, 10 Jan 2013 12:13:30 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A864D21F879D for ; Thu, 10 Jan 2013 12:13:29 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id mC5B1k0020EZKEL51LDVrZ; Thu, 10 Jan 2013 20:13:29 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta01.westchester.pa.mail.comcast.net with comcast id mLDT1k00J3Ecudz3MLDU5s; Thu, 10 Jan 2013 20:13:28 +0000 From: "ietfdbh" To: "'t.petch'" , "'Scott O Bradner'" References: <9904FB1B0159DA42B0B887B7FA8119CA0563D8@AZ-FFEXMB04.global.avaya.com><4087887712E5C648B9F72BB9D912FD4602500BF48979@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA0564EA@AZ-FFEXMB04.global.avaya.com> <01c501cdeb42$8c0f6340$4001a8c0@gateway.2wire.net> <19B24B5B-D92B-471B-ABCE-8C67E8F11AD6@sobco.com> <017d01cded89$749f1ea0$4001a8c0@gateway.2wire.net> <026801cdedec$96ce9c40$c46bd4c0$@comcast.net> <01af01cdef58$6c892460$4001a8c0@gateway.2wire.net> In-Reply-To: <01af01cdef58$6c892460$4001a8c0@gateway.2wire.net> Date: Thu, 10 Jan 2013 15:13:22 -0500 Message-ID: <001f01cdef6e$f13b0370$d3b10a50$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM23p9FmINIEFMv+6S30avMTzIL1gHnSfxcAjmoNIwCKt1+wAIVlUEjAhpxm/0Bn8eBNgHj1nETlQEeDqA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357848809; bh=HrC48kwu9ngeFDyudShmuPptBBbNZ1FYxB7m50FIses=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=U1u6wqd+gg5dqt5JMZOsZ6fJk5wtuPTYnTFQc4PWFFTVIwZSLKo5+KeMVXO6eItbT tC5FlvR9aiKapYv317wWdTylKXKuOm2zZCX4xGwFh7ecC8PhZ6AUb3LtKlzk8iHLex f+JRMVfmdDWNFldFc1oBep0sO4+fkG4IDQ7moL7qWqVvtFbHgrYi38qzv45z2Zd+79 udFCTFsrRv2a6pl/v7rh0VFuvT+0SB2Re0oGalI3bpKPyUdcxOJLRI3991POTWbb/c fXxNvISyukRFm6twdUDL9w4YNrK5Daa+j54XEX8IOq1l398Q0At5gWPGgoNpRpgQ+t 4819iGBqH2RfQ== Cc: opsawg@ietf.org, 'Edward Beili' Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 20:13:31 -0000 Hi, I agree Obsoletes is not accurate. I think Updates might be accurate. However, I think the text is inaccurate: "That MIB module will be part of a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group." I disagree with this statement. The EFM-CU-MIB is being frozen as is, and a NEW MIB module is being created, called IEEE8023-EFM-CU-MIB. RFC2578 does not allow renaming of a MIB module: " Note that any definition contained in an information module is available to be IMPORT-ed by any other information module, and is referenced in an IMPORTS clause via the module name. Thus, a module name should not be changed. Specifically, the module name (e.g., "FIZBIN-MIB" in the example of Section 5.7) should not be changed when revising an information module (except to correct typographical errors), and definitions should not be moved from one information module to another. Also note that obsolete definitions must not be removed from MIB modules since their descriptors may still be referenced by other information modules, and the OBJECT IDENTIFIERs used to name them must never be re-assigned." So claiming that the EFM-CU-MIB is being renamed is inaccurate because that would violate SMIv2 rules. All the object definitions in EFM-CU-MIB will also need to be renamed and duplicated under IEEE8023-EFM-CU-MIB. Otherwise NMS applications that import EFM-CU-MIB and IEEE8023-EFM-CU-MIB would not be able to easily distinguish which OID is appropriate. Since EFM-CU-MIB cannot be legally "moved" to IEEE8023-EFM-CU-MIB, and existing devices and applications may continue to support it, I recommend the existing MIB module should retain its current status. If we want to recommend that people utilize IEEE8023-EFM-CU-MIB, we can provide an Updates clause to update the RFC5066 status, but since it contains an active MIB it really should not be Obsoleted. If we want to deprecate the EFM-CU-MIB and recommend IEEE8023-EFM-CU-MIB, then I think the EFM-CU-MIB MIB module would need to be published again with an SMIv2 deprecated status (and all the objects would presumably need to be deprecated as well). If we deprecate the EFM-CU-MIB module and its objects, the "relationship to other MIB modules" would need some serious updating to discuss the impact of the deprecation on other modules (including proprietary MIB modules) that depend on EFM-CU-MIB. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Thursday, January 10, 2013 5:19 AM To: ietfdbh; 'Scott O Bradner' Cc: opsawg@ietf.org; 'Edward Beili' Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt ---- Original Message ----- From: "ietfdbh" To: "'t.petch'" ; "'Scott O Bradner'" Cc: ; "'Edward Beili'" Sent: Tuesday, January 08, 2013 10:07 PM > Hi, > > I would be careful with assumptions about the existing IETF standards-track > MIB vanishing, even if IEEE is going to maintain comparable definitions > under an IEEE subtree going forward. > > Existing devices and managers might support the RFC5066 EFM-CU-MIB, and > those devices may never be updated to the new IEEE version. > The IETF standards-track EFM-CU-MIB should still be considered a valid MIB > module; it just should not be modified going forward. > The IEEE version should replace it for new implementations, and the IEEE > version could supplement the IETF EFM-CU-MIB in new and updated > implementations, to support continued interoperability. David So in practical terms, what would you do? Currently the I-D has an 'Obsoletes 5066' which I think wrong, since the new I-D omits the vast mass of 5066; and, as you rightly point out, the EFM-CU-MIB module could well be with us for a long time (and we have no change control over the IEEE module that one day may replace it). Leave 5066 as Standards Track with this as an Updates (which it isn't, its a reproduce a small part thereof unchanged as far as I can see)? I will go on objecting to Obsoletes even if I cannot see what the alternative should be:-) Tom Petch > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of > t.petch > Sent: Tuesday, January 08, 2013 5:18 AM > To: Scott O Bradner > Cc: opsawg@ietf.org; Edward Beili > Subject: Re: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > > ---- Original Message ----- > From: "Scott O Bradner" > To: "t.petch" > Cc: "Romascanu, Dan (Dan)" ; "Edward Beili" > ; > Sent: Saturday, January 05, 2013 2:25 PM > > On Jan 5, 2013, at 7:45 AM, t.petch wrote: > > > I wonder if this I-D should really supersede RFC5066. I would rather > > see RFC5066 become Historic with this as an Updates. > > a historic document does not exist (standards track wise) so there would be > nothing to update - > > also- an update would not be a complete replacement (i.e. some of the old > document would still be in force) - is that the case here (i.e. > do you think that this is not a full replacement?) > > Scott > > As Dan said, > "RFC 5066 defines two MIB modules. One (this one) continues to be maintained > by the IETF. There is no need for a change. The other > (EFM-CU-MIB) goes to the IEEE, and will be relocated with new names under > the IEEE802 subtree. That document is now in Sponsor Ballot by the IEEE-SA." > > so the vast majority of RFC5066 vanishes into IEEE and is transformed > therein. > > The bit that is left, ifCapStackMIB, is unaltered from RFC5066 (hence the > reuse of the number in the mib tree). > > I do not know what the best way to describe this in our documentation is! > > As to Copyright, RFC5066 has one editor but the work was "greatly advanced > by the contributions of the following people" > which lists eight such people, so no, I do not think that the editor of > RFC5066bis can make the necessary grant. > > RFC5066 predates the change of rules, increasing the grants, by a year. > > Tom Petch > > > > > Should the Copyright carry the caveat about old material for which the > > current rules may not apply? Since this MIB Module is going to see > > extensive use by another SDO, this seems particularly relevant. > > the author of the old doc is the author of the new doc and is submitting the > new doc under the current rules (and gave himself permission to do that) > > Scott > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Romascanu, Dan (Dan)" > > To: "Edward Beili" ; > > Cc: > > Sent: Thursday, January 03, 2013 6:00 PM > > > >> Hi Ed, > >> > >>> 3. You probably meant "No action is required from IANA ..." > >> > >> Of course, thanks for catching this. > >> > >> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >> > >> Let us wait for a couple of days. Hopefully we will get an answer > from > > Howard concerning a better reference for the IEEE 802.3.1a Rev 2 > draft, > > and maybe other comments from the OPSAWG or the IEEE folks. > >> > >> Please issue a revised version by the start of the next week, as I > > plan to enter my Sponsor Ballot comment on the IEEE document, and I > need > > a reference to the best IETF I-D available at that moment. > >> > >> Thanks and Regards, > >> > >> Dan > >> > >> > >> > >>> -----Original Message----- > >>> From: Edward Beili [mailto:EdwardB@actelis.com] > >>> Sent: Thursday, January 03, 2013 7:55 PM > >>> To: Romascanu, Dan (Dan); opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: RE: comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> Dan, > >>> Thank you for the comments, I agree with everything, except for the > >>> following: > >>> > >>> 2. I will leave the IEEE 803.2.1-2011 reference for now, until IEEE > >>> 802.3 would provide a publically accessible link. > >>> > >>> 3. You probably meant "No action is required from IANA ..." instead > > of > >>> "New action is required form IANA ...", i.e. the correct paragraph > > would > >>> be: > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > > been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> No action is required from IANA as the OID for ifCapStackMIB > > MODULE- > >>> IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> 4. Shall I wait for other comments or should I just issue the next > >>> version of the draft? > >>> > >>> Regards, > >>> -E. > >>> > >>> -----Original Message----- > >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf > >>> Of Romascanu, Dan (Dan) > >>> Sent: Thursday, January 03, 2013 17:59 > >>> To: opsawg@ietf.org > >>> Cc: hfrazier@broadcom.com > >>> Subject: [OPSAWG] comments on draft-ietf-opsawg-rfc5066bis-00.txt > >>> > >>> > >>> Thanks to Ed Beili for undertaking this work. > >>> > >>> A few comments: > >>> > >>> 1. In the Abstract you are making the statement that this > > specification > >>> moves the EFM-CU-MIB module to an IEEE document. In fact the IETF > > does > >>> not have the rights to do such a move alone, this document should > > rather > >>> just recognize this move. > >>> > >>> Suggested change: > >>> > >>> OLD: > >>> > >>> It amends that specification by moving the entire EFM-CU- > >>> MIB module along with the relevant descriptive text, to a > > separate > >>> document, maintained by the Institute of Electrical and > > Electronics > >>> Engineers (IEEE) 802.3.1 working group. > >>> > >>> NEW: > >>> > >>> It amends that specification by taking out the entire EFM-CU- > >>> MIB module along with the relevant descriptive text. That MIB > > module > >>> will be part of a separate document, maintained by the Institute > > of > >>> Electrical and Electronics Engineers (IEEE) 802.3 working group. > >>> > >>> Also in Section 1: > >>> > >>> OLD: > >>> > >>> This > >>> version moves the entire EFM-CU-MIB module along with the > > relevant > >>> descriptive text, to a separate document, maintained by the > > Institute > >>> of Electrical and Electronics Engineers (IEEE) 802.3.1 working > > group. > >>> > >>> NEW: > >>> > >>> This version > >>> removes the entire EFM-CU-MIB module along with the relevant > >>> descriptive > >>> text. That MIB module will be part of a separate document, > > maintained > >>> by > >>> the Institute of Electrical and Electronics Engineers (IEEE) > > 802.3. > >>> working group. > >>> > >>> 2. In Section 3.1: > >>> > >>> The EFM-CU-MIB module defined in the previous version of this > >>> document, along with the relevant descriptive text, is now moved > > to a > >>> separate, IEEE maintained document, IEEE Std 802.3.1-2011 > > [802.3.1], > >>> which also renamed the EFM-CU-MIB to IEEE8023-EFM-CU-MIB. > >>> > >>> - Instead of 'the previous version of this document' we should just > > say > >>> [RFC5066]. > >>> - We should provide a more updated version of the IEEE standard > > which > >>> contains the IEEE-EFM-CU-MIB - the document now in Sponsor Ballot > > would > >>> be fine, but the access is restricted. I suggest to ask advice from > >>> Howard Frazier. > >>> > >>> 3. I suggest that Section 7 mentions that no (new) IANA actions are > >>> required because it's the same root already allocated in RFC 5066. > >>> > >>> OLD: > >>> > >>> Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have > > been > >>> allocated by IANA in the MIB-2 sub-tree. > >>> > >>> NEW: > >>> > >>> New action is required from IANA as the OID for ifCapStackMIB > > MODULE- > >>> IDENTITY > >>> was already allocated in [RFC5066]. > >>> > >>> Regards, > >>> > >>> Dan > >>> > >>> > >>> _______________________________________________ > >>> OPSAWG mailing list > >>> OPSAWG@ietf.org > >>> https://www.ietf.org/mailman/listinfo/opsawg > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > >> > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From iesg-secretary@ietf.org Fri Jan 11 11:36:17 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5721F8A93; Fri, 11 Jan 2013 11:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LSTKhBo4oUv; Fri, 11 Jan 2013 11:36:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D87721F8A6E; Fri, 11 Jan 2013 11:36:16 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 11:36:16 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 19:36:17 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ No IPR declarations have been submitted directly on this I-D. From brian.e.carpenter@gmail.com Sat Jan 12 08:40:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E92121F874A for ; Sat, 12 Jan 2013 08:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9Bo8XN2QqqC for ; Sat, 12 Jan 2013 08:40:02 -0800 (PST) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D621F8749 for ; Sat, 12 Jan 2013 08:40:02 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x43so1304479wey.23 for ; Sat, 12 Jan 2013 08:40:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qjmFLpI5FN3WLRbJYxhNdYOgXc1zNP+ydXsQPc1U+MM=; b=CmBKooZDF7m2wzQTh0ykVCjfmKM9hrIqQJBTz1k3yCazfhNvGl9dbJLZNI7+y/Wi6x SJx3XnoIALBawRVxiJLomyTmIdKHOnaaoVafH+9ve7AmSl/MkKTgt+jGG31ZunHzhmC+ t7W8uQXzVMUBcDB8fwD89uy919sWRzAg8fQ1GjyeXTCQfYiw5UAiP2PclVMsROO5Pu2q JTrxhwL7eeRY+b6XgpXjjNSxPlRdIqs9zcUee/OmZEOZv8d8bYC1PO+GgsvJjotkPIpE o6sqS1QnAP3S1+jjLvpUsD4PQXRNbWY9ZZEpbzSO9DoswTQUjXsfoeRxoFcBcdomgELs NJfw== X-Received: by 10.180.86.36 with SMTP id m4mr4676370wiz.5.1358008801533; Sat, 12 Jan 2013 08:40:01 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-89.as13285.net. [2.101.188.89]) by mx.google.com with ESMTPS id bw9sm4357289wib.5.2013.01.12.08.39.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Jan 2013 08:40:00 -0800 (PST) Message-ID: <50F191EC.8040306@gmail.com> Date: Sat, 12 Jan 2013 16:40:12 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> In-Reply-To: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 16:40:03 -0000 Hi, My comments are on the discussion of flow IDs and hashing. I'm not commenting at all on the overall proposal, because I can't judge whether the problem is real or the solution is practical. > A large space of the flow identifications, i.e. finer > granularity of the flows, conducts more random in spreading the flows > over a set of component links. That isn't accurate. The requirement is an ID space in which the IDs belong to a uniform distribution. Technically speaking, if you have two links, a one-bit flow ID is sufficient, as long as the values 0 and 1 are equally likely to appear. Therefore, the practical issue is not the size of the ID space but the quality of the hash function used to generate the ID of each flow. However, whatever the initial ID space, the final hash has to be down to 0..N if you have N+1 alternative paths. I think the reason that your model needs a larger ID space is to reduce the probability of two flows colliding by chance in the ID space. That would defeat your wish to separate out large flows. > The advantages of hashing based load > distribution are the preservation of the packet sequence in a flow > and the real time distribution with the stateless of individual > flows. If the traffic flows randomly spread in the flow > identification space, the flow rates are much smaller compared to the > link capacity, That sounds like magic. I don't think you mean that at all. > and the rate differences are not dramatic, Do you mean that the total traffic rate is more fairly distributed across the links? In any case, "dramatic" isn't an engineering term. > the hashing > algorithm works very well in general. How can you say that without specifying a particular algorithm? Also, "very well in general" isn't an engineering term either. > There may be some false positives due to multiple other flows > masquerading as a large flow; the amount of false positives is > reduced by parallel hashing using different hash functions To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. [https://researchspace.auckland.ac.nz/handle/2292/13240] I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? Regards Brian Carpenter From ramk@Brocade.com Sat Jan 12 21:15:11 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC80B21F8A96 for ; Sat, 12 Jan 2013 21:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8I-HImfTzo0 for ; Sat, 12 Jan 2013 21:15:08 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4921F8A99 for ; Sat, 12 Jan 2013 21:15:03 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r0D5F2x5027488; Sat, 12 Jan 2013 21:15:02 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 19uk9701nk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 12 Jan 2013 21:15:01 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 12 Jan 2013 21:14:59 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sat, 12 Jan 2013 21:14:59 -0800 From: ramki Krishnan To: Brian E Carpenter , "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" Date: Sat, 12 Jan 2013 21:14:55 -0800 Thread-Topic: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: Ac3w43t0VsclSY70ToKgB2rM2w8ehQAVgiBQ Message-ID: References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> In-Reply-To: <50F191EC.8040306@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DE71HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-13_02:2013-01-11, 2013-01-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301120375 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 05:15:12 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DE71HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks a lot for your comments. Please find answers to some of your comment= s. We will respond to your other comments shortly. > There may be some false positives due to multiple other flows > masquerading as a large flow; the amount of false positives is > reduced by parallel hashing using different hash functions Brian: To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm = gives at most 5% collisions, based on IPv6 headers in real packet traces. = [https://researchspace.auckland.ac.nz/handle/2292/13240]. I wonder whether = the overhead of running several hashes in parallel is justified by this col= lision rate? Ram: The need for multiple hashes is specific to the suggested algorithm on auto= matic hardware identification - this algorithm is similar to a bloom filter= which uses multiple hash functions. "On packet arrival, a new flow is looked up in parallel in all the hash tab= les and the corresponding counter is incremented. If the counter exceeds a = programmed threshold in a given time interval in all the hash table entries= , a candidate large flow is learnt and programmed in a hardware table resou= rce like TCAM. For a short-lived flow to masquerade as a long-lived lived flow, it needs t= o match all the hash table entries which is a joint probability event - thu= s, the amount of false positives due to short-lived flows is reduced. Thanks, ram -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Brian E Carpenter Sent: Saturday, January 12, 2013 8:40 AM To: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org Cc: opsawg@ietf.org Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-bal= ancing-02.txt Hi, My comments are on the discussion of flow IDs and hashing. I'm not commenti= ng at all on the overall proposal, because I can't judge whether the proble= m is real or the solution is practical. > A large space of the flow identifications, i.e. finer > granularity of the flows, conducts more random in spreading the flows > over a set of component links. That isn't accurate. The requirement is an ID space in which the IDs belong= to a uniform distribution. Technically speaking, if you have two links, a = one-bit flow ID is sufficient, as long as the values 0 and 1 are equally li= kely to appear. Therefore, the practical issue is not the size of the ID space but the qual= ity of the hash function used to generate the ID of each flow. However, whatever the initial ID space, the final hash has to be down to 0.= .N if you have N+1 alternative paths. I think the reason that your model needs a larger ID space is to reduce the= probability of two flows colliding by chance in the ID space. That would defeat your wish to separate out large flows. > The advantages of hashing based load > distribution are the preservation of the packet sequence in a flow > and the real time distribution with the stateless of individual > flows. If the traffic flows randomly spread in the flow > identification space, the flow rates are much smaller compared to the > link capacity, That sounds like magic. I don't think you mean that at all. > and the rate differences are not dramatic, Do you mean that the total traffic rate is more fairly distributed across t= he links? In any case, "dramatic" isn't an engineering term. > the hashing > algorithm works very well in general. How can you say that without specifying a particular algorithm? Also, "very= well in general" isn't an engineering term either. > There may be some false positives due to multiple other flows > masquerading as a large flow; the amount of false positives is > reduced by parallel hashing using different hash functions To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm = gives at most 5% collisions, based on IPv6 headers in real packet traces. [https://researchspace.auckland.ac.nz/handle/2292/13240] I wonder whether the overhead of running several hashes in parallel is just= ified by this collision rate? Regards Brian Carpenter _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DE71HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

Thanks a lot for your comments. Please find answers to some of your co= mments. We will respond to your other comments shortly.

 

> There = may be some false positives due to multiple other flows   &n= bsp;

> masquerading as a large fl= ow; the amount of false positives is     

> reduced by parallel hashing using diffe= rent hash functions

 =

Brian:

T= o give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm g= ives at most 5% collisions, based on IPv6 headers in real packet traces.&nb= sp; [https://researchspace.auckland.ac.nz/handle/2292/13240]. I wonder whet= her the overhead of running several hashes in parallel is justified by this= collision rate?

 

Ram:

The nee= d for multiple hashes is specific to the suggested algorithm on automatic h= ardware identification - this algorithm is similar to a bloom filter which = uses multiple hash functions.

&= nbsp;

"On packet arrival, a new flow = is looked up in parallel in all the hash tables and the corresponding count= er is incremented. I= f the counter exceeds a programmed threshold in a given time interval in al= l the hash table entries, a candidate large flow is learnt and progr= ammed in a hardware table resource like TCAM.

 

For a short-lived flo= w to masquerade as a long-lived lived flow, it needs to match all the hash = table entries which is a joint probability event – thus, the amount o= f false positives due to short-lived flows is reduced.

 

Thanks,=

ram

 

-----Original Message-----From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf O= f Brian E Carpenter
Sent: Saturday, January 12, 2013 8:40 AM
To: draf= t-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org
Cc: opsawg@ie= tf.org
Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flo= w-load-balancing-02.txt

 

Hi,

<= o:p> 

My comments are on the discussi= on of flow IDs and hashing. I'm not commenting at all on the overall propos= al, because I can't judge whether the problem is real or the solution is pr= actical.

 

> A large space of the flow identifications, i.e. finer=   

> granularity of the= flows, conducts more random in spreading the flows    =

> over a set of component links. =

 

That isn't accurate. The requirement is an ID space in which the IDs be= long to a uniform distribution. Technically speaking, if you have two links= , a one-bit flow ID is sufficient, as long as the values 0 and 1 are equall= y likely to appear.

 =

Therefore, the practical issue is not the size = of the ID space but the quality of the hash function used to generate the I= D of each flow.

However, whatever the= initial ID space, the final hash has to be down to 0..N if you have N+1 al= ternative paths.

 

I think the reason that your model needs a larger = ID space is to reduce the probability of two flows colliding by chance in t= he ID space.

That would defeat your w= ish to separate out large flows.

 

> The advantages of hashing bas= ed load      

> distribution are the preservation of the packet sequence in a = flow

> and the real time distribu= tion with the stateless of individual      &n= bsp;   

> flows. I= f the traffic flows randomly spread in the flow    &nbs= p;  

> identification s= pace, the flow rates are much smaller compared to the   &nbs= p;

> link capacity,

 

That = sounds like magic. I don't think you mean that at all.

 

> and the= rate differences are not dramatic,

<= o:p> 

Do you mean that the total traf= fic rate is more fairly distributed across the links? In any case, "dr= amatic" isn't an engineering term.

 

> the hashing 

> algorithm works very well in genera= l.

 

How can you say that without specifying a particular algorithm? = Also, "very well in general" isn't an engineering term either.

 

> There may be some false positives due to multiple other flows&nb= sp;   

> masquerad= ing as a large flow; the amount of false positives is   &nbs= p; 

> reduced by parallel ha= shing using different hash functions

=  

To give you some data, with a = 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, b= ased on IPv6 headers in real packet traces.

[https://researchspace.auckland.ac.nz/handle/2292/13240]<= /p>

 

I w= onder whether the overhead of running several hashes in parallel is justifi= ed by this collision rate?

 = ;

Regards

   Brian Carpenter

 

________________________________= _______________

OPSAWG mailing list

OPSAWG@ietf.org

https://www.ietf.org/mailman/listinfo/opsawg

= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DE71HQ1EXCH01corp_-- From brian.e.carpenter@gmail.com Sun Jan 13 00:06:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7DA21F8AF8 for ; Sun, 13 Jan 2013 00:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.408 X-Spam-Level: X-Spam-Status: No, score=-101.408 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfEgezIal+Rv for ; Sun, 13 Jan 2013 00:06:06 -0800 (PST) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 682A121F8AE6 for ; Sun, 13 Jan 2013 00:06:06 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id r1so1526657wey.15 for ; Sun, 13 Jan 2013 00:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P2nHtCpzZAvzyZbUrfeWWk94JC8CLHZHKHs1awvPBEk=; b=sZee3n3Xv5rbb9S7MieDE/iG9RsYvFPq0tDfGgBQ/+2XINeZ6mEnyG5fIdTYeHbo47 vdqs26hzsmTvl4Upo7FaxYv1U9fY8/pYoWB7Xi+xbao9o6+XbykL/F6tPz7UHqmN1muV 8BJzaaCrKpz9XH2Z5NS6vxJR04/W7VdkE9JZUTWLt0+2BmQkDxDitzQJtOdtbm2jVcSx jCYyQ6oW8+nLb/HUOkqsrT4fJ00ADMQT4Y0+vEA4WnqVVn0PPMwrdu0UNQxmDGm4cv/a x70qEYaft5rT4gg8csOmw0fEYEDWE7vyACy+XE8Zwr3Zp3tcd/iIDiyStv8QD6Z9/fon 3mgg== X-Received: by 10.194.174.234 with SMTP id bv10mr13919017wjc.47.1358064365264; Sun, 13 Jan 2013 00:06:05 -0800 (PST) Received: from [192.168.1.65] (host-2-102-219-76.as13285.net. [2.102.219.76]) by mx.google.com with ESMTPS id dm3sm6957248wib.9.2013.01.13.00.06.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 13 Jan 2013 00:06:04 -0800 (PST) Message-ID: <50F26AE6.9070405@gmail.com> Date: Sun, 13 Jan 2013 08:05:58 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ramki Krishnan References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 08:06:08 -0000 Ram, On 13/01/2013 05:14, ramki Krishnan wrote: > Hi Brian, > > Thanks a lot for your comments. Please find answers to some of your comments. We will respond to your other comments shortly. > >> There may be some false positives due to multiple other flows >> masquerading as a large flow; the amount of false positives is >> reduced by parallel hashing using different hash functions > > Brian: > >> To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. [https://researchspace.auckland.ac.nz/handle/2292/13240]. I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > Ram: > > The need for multiple hashes is specific to the suggested algorithm on automatic hardware identification - this algorithm is similar to a bloom filter which uses multiple hash functions. I think didn't explain my point sufficiently. I understand why you suggest using several hashes. But this is statistical load balancing we are talking about. If a few % of the time, you mistakenly treat several medium flows as one large flow, and therefore rebalance them as a single unit, so what? You will still balance the traffic reasonably well. Brian > "On packet arrival, a new flow is looked up in parallel in all the hash tables and the corresponding counter is incremented. If the counter exceeds a programmed threshold in a given time interval in all the hash table entries, a candidate large flow is learnt and programmed in a hardware table resource like TCAM. > For a short-lived flow to masquerade as a long-lived lived flow, it needs to match all the hash table entries which is a joint probability event - thus, the amount of false positives due to short-lived flows is reduced. > Thanks, > > ram > > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Saturday, January 12, 2013 8:40 AM > To: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > Hi, > > My comments are on the discussion of flow IDs and hashing. I'm not commenting at all on the overall proposal, because I can't judge whether the problem is real or the solution is practical. > >> A large space of the flow identifications, i.e. finer > >> granularity of the flows, conducts more random in spreading the flows >> over a set of component links. > > That isn't accurate. The requirement is an ID space in which the IDs belong to a uniform distribution. Technically speaking, if you have two links, a one-bit flow ID is sufficient, as long as the values 0 and 1 are equally likely to appear. > Therefore, the practical issue is not the size of the ID space but the quality of the hash function used to generate the ID of each flow. > However, whatever the initial ID space, the final hash has to be down to 0..N if you have N+1 alternative paths. > I think the reason that your model needs a larger ID space is to reduce the probability of two flows colliding by chance in the ID space. > That would defeat your wish to separate out large flows. > >> The advantages of hashing based load >> distribution are the preservation of the packet sequence in a flow >> and the real time distribution with the stateless of individual >> flows. If the traffic flows randomly spread in the flow >> identification space, the flow rates are much smaller compared to the >> link capacity, > > That sounds like magic. I don't think you mean that at all. > >> and the rate differences are not dramatic, > > Do you mean that the total traffic rate is more fairly distributed across the links? In any case, "dramatic" isn't an engineering term. >> the hashing >> algorithm works very well in general. > > How can you say that without specifying a particular algorithm? Also, "very well in general" isn't an engineering term either. > >> There may be some false positives due to multiple other flows >> masquerading as a large flow; the amount of false positives is >> reduced by parallel hashing using different hash functions > > To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. > [https://researchspace.auckland.ac.nz/handle/2292/13240] > I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > Regards > > Brian Carpenter > _______________________________________________ > > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From bclaise@cisco.com Mon Jan 14 09:07:41 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871A521F848B; Mon, 14 Jan 2013 09:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7hYUqq-Yb5z; Mon, 14 Jan 2013 09:07:37 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7847C21F89B9; Mon, 14 Jan 2013 09:07:31 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EGqaXa022363; Mon, 14 Jan 2013 17:52:36 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0EGqFJ6005038; Mon, 14 Jan 2013 17:52:26 +0100 (CET) Message-ID: <50F437BF.8040005@cisco.com> Date: Mon, 14 Jan 2013 17:52:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "draft-ietf-opsawg-oam-overview@tools.ietf.org" References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> In-Reply-To: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090402040208020001020605" Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:07:41 -0000 This is a multi-part message in MIME format. --------------090402040208020001020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit draft-ietf-opsawg-oam-overview authors, Here is my feedback on this document. 1. Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04? * For example, the following definitions could be reused. Fault: The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. Defect: The term Defect refers to an interruption in the normal operation, such that over a period of time no packets are delivered successfully. Failure: The term Failure refers to the termination of the required function over a longer period of time. Persistence of a defect for a period of time is interpreted as a failure. * For example, on the basic abstract Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. Abstract (draft-ietf-trill-oam-req-04) OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. So, as an example: does OAM include function? I advice to review draft-ietf-trill-oam-req-04 2. draft-ietf-trill-oam is not mentioned, while the abstract mentions: This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references. Ok, I see later on: This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. Ok, fine then: we don't need a reference to all the drafts. However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned. 3. Section 1 The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def ], focusing on the forwarding plane of OAM. What does it mean "focusing on the forwarding plane of OAM"? Do you take a subset of the definition for this document? Btw, I don't see a definition in the terminology section. In section 2.2.3 A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. Which plane is MP? 4. Section 1, Introduction "Hence, management aspects are outside the scope of this document." I don't understand which management aspects we speak about here. 5. Clarifying question regarding 1.2 If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane? Note that I found later on in the draft: OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same feedback from Stewart Bryant: Provide a clear view of OAM functionality and its relationship to various "planes" of networking (data plane, control plane, management plane). In particular, the importance of fate-sharing of OAM and user traffic flows in packet networks should be explained. 6. I see a multiplication of "plane" terms in the IETF document, and in this document in particular. I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane. Way too many. Please be consistent 7. Table 1 summarizes the IETF OAM related RFCs discussed in this document. Table 2 summarizes the OAM standards mentioned in this document. You need to change the Table 2 description. Do you want to say something along the lines of: Table 2 summarizes the OAM standards specified by other Standard Development Organization (SDO) than the IETF, along with IETF references where applicable. 8. Section 2.2.1 For a formal definition of each term, refer to the references at the end of this document. Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references. You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms, just read first all references!" 9. You specify some terms and some OAM categories, 2.2.2 . OAM Maintenance Entities ..........................13 2.2.3 . OAM Maintenance Points ............................14 2.2.4 . Proactive and On-demand activation ................15 2.2.5 . Connectivity Verification and Continuity Checks ...15 2.2.6 . Failures ..........................................15 ... but you don't use them in the section 3 Just_one_example with section 3.2.2 - o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5 - OLD: Each of the end-points of the monitored path maintains its own session identification NEW: Each of the MEP maintains its own session identification OR NEW (actually I don't know) Each of the MP maintains its own session identification - OLD A BFD echo packet is sent to a peer system Peer system = MEP, MP, or something else? - etc... 10. This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience". When we did RFC 6632, which is the companion document, we hadhttp://tools.ietf.org/html/rfc6632#section-1.1 The target audience of the document is, on the one hand, IETF working groups, which aim to select appropriate standard management protocols and data models to address their needs concerning network management. On the other hand, the document can be used as an overview and guideline by non-IETF Standards Development Organizations (SDOs) planning to use IETF management technologies and data models for the realization of management applications. The document can also be used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties that seek to get an overview of the current set of the IETF network management protocols such as network administrators or newcomers to the IETF. You should have something similar. 11. Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM ], [TP-LM-DM ]), and in Ethernet OAM [ITU-T-Y1731 ]. My conclusions: this document still needs some work Regards, Benoit > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: > - 'An Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > --------------090402040208020001020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract 
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL. 

So, as an example: does OAM include function? 
I advice to review draft-ietf-trill-oam-req-04

2. 
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
Ok, I see later on:	
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts. 
However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document. 

You need to change the Table 2 description. Do you want to say something along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard Development Organization 
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the end of
   this document.
Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories, 
   2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
         2.2.4. Proactive and On-demand activation ................ 15
         2.2.5. Connectivity Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system = MEP, MP, or something else?
- etc... 

10. 
This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/


No IPR declarations have been submitted directly on this I-D.

--------------090402040208020001020605-- From ramk@Brocade.com Mon Jan 14 09:48:51 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B999A21F88C4 for ; Mon, 14 Jan 2013 09:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoBwY7oWofTs for ; Mon, 14 Jan 2013 09:48:50 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id E25DC21F85D7 for ; Mon, 14 Jan 2013 09:48:49 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r0EHmDZC022247; Mon, 14 Jan 2013 09:48:48 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 19vn6hr20x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Jan 2013 09:48:47 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 14 Jan 2013 09:48:46 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 14 Jan 2013 09:48:46 -0800 From: ramki Krishnan To: Brian E Carpenter Date: Mon, 14 Jan 2013 09:48:40 -0800 Thread-Topic: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: Ac3xZNiY1z+FA/4ST1ytCbw7aXUWKABA1T1A Message-ID: References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> In-Reply-To: <50F26AE6.9070405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DF42HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-14_04:2013-01-14, 2013-01-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301140149 Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:48:52 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DF42HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCg0KDQo+PkkgdGhpbmsgZGlkbid0IGV4cGxhaW4gbXkgcG9pbnQgc3VmZmlj aWVudGx5LiBJIHVuZGVyc3RhbmQgd2h5IHlvdSBzdWdnZXN0IHVzaW5nIHNldmVyYWwgaGFzaGVz LiBCdXQgdGhpcyBpcyBzdGF0aXN0aWNhbCBsb2FkIGJhbGFuY2luZyB3ZSBhcmUgdGFsa2luZyA+ PmFib3V0LiBJZiBhIGZldyAlIG9mIHRoZSB0aW1lLCB5b3UgbWlzdGFrZW5seSB0cmVhdCBzZXZl cmFsIG1lZGl1bSBmbG93cyBhcyBvbmUgbGFyZ2UgZmxvdywgYW5kIHRoZXJlZm9yZSByZWJhbGFu Y2UgdGhlbSBhcyBhIHNpbmdsZSB1bml0LCBzbyB3aGF0PyA+PllvdSB3aWxsIHN0aWxsIGJhbGFu Y2UgdGhlIHRyYWZmaWMgcmVhc29uYWJseSB3ZWxsLg0KDQoNCg0KRWFjaCBvZiB0aGUgZmxvd3Mg aXMgZXZlbnR1YWxseSBsZWFybnQvcHJvZ3JhbW1lZCBpbiBhIGZsb3cgdGFibGUgKGhhcmR3YXJl IHRhYmxlIHJlc291cmNlIHdoZXJlIHRoZSBmbG93IGlzIGZpbmFsbHkgY29tbWl0dGVkKTsgdGhl cmUgaXMgbmV2ZXIgYSBjYXNlIG9mIGJ1bmRsaW5nIG11bHRpcGxlIGZsb3dzLiBNb3JlIGRldGFp bHMgYmVsb3cNCg0KDQoNCjEpICAgIFNjYWxhYmxlIGRldGVjdGlvbiBvZiBsb25nLWxpdmVkIGxh cmdlIGZsb3dzDQoNCmEuICAgIFRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIHNpemUgb2YgdGhlIGZs b3cgdGFibGUgKGhhcmR3YXJlIHRhYmxlIHJlc291cmNlIHdoZXJlIHRoZSBsb25nLWxpdmVkIGxh cmdlIGZsb3cgaXMgZmluYWxseSBjb21taXR0ZWQpIGJvdW5kZWQgYW5kIHRoZSBwcm9jZXNzaW5n IHJlcXVpcmVtZW50cyAoQ1BVIHV0aWxpemF0aW9uKSBmb3IgZmxvdyBsZWFybmluZyBib3VuZGVk Lg0KDQpiLiAgICBGb3Igc2F0aXNmeWluZyB0aGUgYWJvdmUgZ29hbCwgc2V2ZXJhbCBoYXNoZXMg aGVscHMuDQoNCg0KDQoyKSAgICBTY2FsYWJsZSBsb2FkLWJhbGFuY2luZyBvZiBsb25nLWxpdmVk IGxhcmdlIGZsb3dzDQoNCmEuICAgIFRoZSBnb2FsIGlzIHRvIGhhdmUgYSBzY2FsYWJsZSBsb2Fk IGJhbGFuY2luZyBzb2x1dGlvbiB3aGljaCBwcm9kdWNlcyBtZWFuaW5nZnVsIHJlc3VsdHMgd2hp bGUga2VlcGluZyB0aGUgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMgKENQVSB1dGlsaXphdGlvbikg Zm9yIGxvYWQtYmFsYW5jaW5nIGJvdW5kZWQuDQoNCmIuICAgIEZvciBzYXRpc2Z5aW5nIHRoZSBh Ym92ZSBnb2FsLCBpdCBpcyBub3Qgd29ydGh3aGlsZSB0byBsb2FkLWJhbGFuY2UgbWVkaXVtL3Nt YWxsIGZsb3dzLg0KDQoNCg0KVGhhbmtzLA0KDQpyYW0NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVu dGVyQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxMjowNiBBTQ0K VG86IHJhbWtpIEtyaXNobmFuDQpDYzogZHJhZnQta3Jpc2huYW4tb3BzYXdnLWxhcmdlLWZsb3ct bG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtPUFNBV0ddIEktRCBBY3Rpb246IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93 LWxvYWQtYmFsYW5jaW5nLTAyLnR4dA0KDQoNCg0KUmFtLA0KDQoNCg0KT24gMTMvMDEvMjAxMyAw NToxNCwgcmFta2kgS3Jpc2huYW4gd3JvdGU6DQoNCj4gSGkgQnJpYW4sDQoNCj4NCg0KPiBUaGFu a3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBmaW5kIGFuc3dlcnMgdG8gc29tZSBv ZiB5b3VyIGNvbW1lbnRzLiBXZSB3aWxsIHJlc3BvbmQgdG8geW91ciBvdGhlciBjb21tZW50cyBz aG9ydGx5Lg0KDQo+DQoNCj4+IFRoZXJlIG1heSBiZSBzb21lIGZhbHNlIHBvc2l0aXZlcyBkdWUg dG8gbXVsdGlwbGUgb3RoZXIgZmxvd3MNCg0KPj4gbWFzcXVlcmFkaW5nIGFzIGEgbGFyZ2UgZmxv dzsgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3NpdGl2ZXMgaXMNCg0KPj4gcmVkdWNlZCBieSBwYXJh bGxlbCBoYXNoaW5nIHVzaW5nIGRpZmZlcmVudCBoYXNoIGZ1bmN0aW9ucw0KDQo+DQoNCj4gQnJp YW46DQoNCj4NCg0KPj4gVG8gZ2l2ZSB5b3Ugc29tZSBkYXRhLCB3aXRoIGEgMjAgYml0IElEIHNw YWNlLCB0aGUgRk5WMWEtMzIgaGFzaCBhbGdvcml0aG0gZ2l2ZXMgYXQgbW9zdCA1JSBjb2xsaXNp b25zLCBiYXNlZCBvbiBJUHY2IGhlYWRlcnMgaW4gcmVhbCBwYWNrZXQgdHJhY2VzLiAgW2h0dHBz Oi8vcmVzZWFyY2hzcGFjZS5hdWNrbGFuZC5hYy5uei9oYW5kbGUvMjI5Mi8xMzI0MF0uIEkgd29u ZGVyIHdoZXRoZXIgdGhlIG92ZXJoZWFkIG9mIHJ1bm5pbmcgc2V2ZXJhbCBoYXNoZXMgaW4gcGFy YWxsZWwgaXMganVzdGlmaWVkIGJ5IHRoaXMgY29sbGlzaW9uIHJhdGU/DQoNCj4NCg0KPiBSYW06 DQoNCj4NCg0KPiBUaGUgbmVlZCBmb3IgbXVsdGlwbGUgaGFzaGVzIGlzIHNwZWNpZmljIHRvIHRo ZSBzdWdnZXN0ZWQgYWxnb3JpdGhtIG9uIGF1dG9tYXRpYyBoYXJkd2FyZSBpZGVudGlmaWNhdGlv biAtIHRoaXMgYWxnb3JpdGhtIGlzIHNpbWlsYXIgdG8gYSBibG9vbSBmaWx0ZXIgd2hpY2ggdXNl cyBtdWx0aXBsZSBoYXNoIGZ1bmN0aW9ucy4NCg0KDQoNCkkgdGhpbmsgZGlkbid0IGV4cGxhaW4g bXkgcG9pbnQgc3VmZmljaWVudGx5LiBJIHVuZGVyc3RhbmQgd2h5IHlvdSBzdWdnZXN0IHVzaW5n IHNldmVyYWwgaGFzaGVzLiBCdXQgdGhpcyBpcyBzdGF0aXN0aWNhbCBsb2FkIGJhbGFuY2luZyB3 ZSBhcmUgdGFsa2luZyBhYm91dC4gSWYgYSBmZXcgJSBvZiB0aGUgdGltZSwgeW91IG1pc3Rha2Vu bHkgdHJlYXQgc2V2ZXJhbCBtZWRpdW0gZmxvd3MgYXMgb25lIGxhcmdlIGZsb3csIGFuZCB0aGVy ZWZvcmUgcmViYWxhbmNlIHRoZW0gYXMgYSBzaW5nbGUgdW5pdCwgc28gd2hhdD8gWW91IHdpbGwg c3RpbGwgYmFsYW5jZSB0aGUgdHJhZmZpYyByZWFzb25hYmx5IHdlbGwuDQoNCg0KDQogICAgQnJp YW4NCg0KDQoNCj4gIk9uIHBhY2tldCBhcnJpdmFsLCBhIG5ldyBmbG93IGlzIGxvb2tlZCB1cCBp biBwYXJhbGxlbCBpbiBhbGwgdGhlIGhhc2ggdGFibGVzIGFuZCB0aGUgY29ycmVzcG9uZGluZyBj b3VudGVyIGlzIGluY3JlbWVudGVkLiBJZiB0aGUgY291bnRlciBleGNlZWRzIGEgcHJvZ3JhbW1l ZCB0aHJlc2hvbGQgaW4gYSBnaXZlbiB0aW1lIGludGVydmFsIGluIGFsbCB0aGUgaGFzaCB0YWJs ZSBlbnRyaWVzLCBhIGNhbmRpZGF0ZSBsYXJnZSBmbG93IGlzIGxlYXJudCBhbmQgcHJvZ3JhbW1l ZCBpbiBhIGhhcmR3YXJlIHRhYmxlIHJlc291cmNlIGxpa2UgVENBTS4NCg0KDQoNCj4gRm9yIGEg c2hvcnQtbGl2ZWQgZmxvdyB0byBtYXNxdWVyYWRlIGFzIGEgbG9uZy1saXZlZCBsaXZlZCBmbG93 LCBpdCBuZWVkcyB0byBtYXRjaCBhbGwgdGhlIGhhc2ggdGFibGUgZW50cmllcyB3aGljaCBpcyBh IGpvaW50IHByb2JhYmlsaXR5IGV2ZW50IC0gdGh1cywgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3Np dGl2ZXMgZHVlIHRvIHNob3J0LWxpdmVkIGZsb3dzIGlzIHJlZHVjZWQuDQoNCg0KDQo+IFRoYW5r cywNCg0KPg0KDQo+IHJhbQ0KDQo+DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0K PiBGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQoNCj4gQmVoYWxmIE9m IEJyaWFuIEUgQ2FycGVudGVyDQoNCj4gU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTIsIDIwMTMg ODo0MCBBTQ0KDQo+IFRvOiBkcmFmdC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJh bGFuY2luZ0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQta3Jpc2huYW4tb3BzYXdnLWxhcmdl LWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmc+DQoNCj4gQ2M6IG9wc2F3Z0BpZXRm Lm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KDQo+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBJ LUQgQWN0aW9uOg0KDQo+IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFs YW5jaW5nLTAyLnR4dA0KDQo+DQoNCj4gSGksDQoNCj4NCg0KPiBNeSBjb21tZW50cyBhcmUgb24g dGhlIGRpc2N1c3Npb24gb2YgZmxvdyBJRHMgYW5kIGhhc2hpbmcuIEknbSBub3QgY29tbWVudGlu ZyBhdCBhbGwgb24gdGhlIG92ZXJhbGwgcHJvcG9zYWwsIGJlY2F1c2UgSSBjYW4ndCBqdWRnZSB3 aGV0aGVyIHRoZSBwcm9ibGVtIGlzIHJlYWwgb3IgdGhlIHNvbHV0aW9uIGlzIHByYWN0aWNhbC4N Cg0KPg0KDQo+PiBBIGxhcmdlIHNwYWNlIG9mIHRoZSBmbG93IGlkZW50aWZpY2F0aW9ucywgaS5l LiBmaW5lcg0KDQo+DQoNCj4+IGdyYW51bGFyaXR5IG9mIHRoZSBmbG93cywgY29uZHVjdHMgbW9y ZSByYW5kb20gaW4gc3ByZWFkaW5nIHRoZSBmbG93cw0KDQo+PiBvdmVyIGEgc2V0IG9mIGNvbXBv bmVudCBsaW5rcy4NCg0KPg0KDQo+IFRoYXQgaXNuJ3QgYWNjdXJhdGUuIFRoZSByZXF1aXJlbWVu dCBpcyBhbiBJRCBzcGFjZSBpbiB3aGljaCB0aGUgSURzIGJlbG9uZyB0byBhIHVuaWZvcm0gZGlz dHJpYnV0aW9uLiBUZWNobmljYWxseSBzcGVha2luZywgaWYgeW91IGhhdmUgdHdvIGxpbmtzLCBh IG9uZS1iaXQgZmxvdyBJRCBpcyBzdWZmaWNpZW50LCBhcyBsb25nIGFzIHRoZSB2YWx1ZXMgMCBh bmQgMSBhcmUgZXF1YWxseSBsaWtlbHkgdG8gYXBwZWFyLg0KDQo+IFRoZXJlZm9yZSwgdGhlIHBy YWN0aWNhbCBpc3N1ZSBpcyBub3QgdGhlIHNpemUgb2YgdGhlIElEIHNwYWNlIGJ1dCB0aGUgcXVh bGl0eSBvZiB0aGUgaGFzaCBmdW5jdGlvbiB1c2VkIHRvIGdlbmVyYXRlIHRoZSBJRCBvZiBlYWNo IGZsb3cuDQoNCj4gSG93ZXZlciwgd2hhdGV2ZXIgdGhlIGluaXRpYWwgSUQgc3BhY2UsIHRoZSBm aW5hbCBoYXNoIGhhcyB0byBiZSBkb3duIHRvIDAuLk4gaWYgeW91IGhhdmUgTisxIGFsdGVybmF0 aXZlIHBhdGhzLg0KDQo+IEkgdGhpbmsgdGhlIHJlYXNvbiB0aGF0IHlvdXIgbW9kZWwgbmVlZHMg YSBsYXJnZXIgSUQgc3BhY2UgaXMgdG8gcmVkdWNlIHRoZSBwcm9iYWJpbGl0eSBvZiB0d28gZmxv d3MgY29sbGlkaW5nIGJ5IGNoYW5jZSBpbiB0aGUgSUQgc3BhY2UuDQoNCj4gVGhhdCB3b3VsZCBk ZWZlYXQgeW91ciB3aXNoIHRvIHNlcGFyYXRlIG91dCBsYXJnZSBmbG93cy4NCg0KPg0KDQo+PiBU aGUgYWR2YW50YWdlcyBvZiBoYXNoaW5nIGJhc2VkIGxvYWQNCg0KPj4gZGlzdHJpYnV0aW9uIGFy ZSB0aGUgcHJlc2VydmF0aW9uIG9mIHRoZSBwYWNrZXQgc2VxdWVuY2UgaW4gYSBmbG93DQoNCj4+ IGFuZCB0aGUgcmVhbCB0aW1lIGRpc3RyaWJ1dGlvbiB3aXRoIHRoZSBzdGF0ZWxlc3Mgb2YgaW5k aXZpZHVhbA0KDQo+PiBmbG93cy4gSWYgdGhlIHRyYWZmaWMgZmxvd3MgcmFuZG9tbHkgc3ByZWFk IGluIHRoZSBmbG93DQoNCj4+IGlkZW50aWZpY2F0aW9uIHNwYWNlLCB0aGUgZmxvdyByYXRlcyBh cmUgbXVjaCBzbWFsbGVyIGNvbXBhcmVkIHRvIHRoZQ0KDQo+PiBsaW5rIGNhcGFjaXR5LA0KDQo+ DQoNCj4gVGhhdCBzb3VuZHMgbGlrZSBtYWdpYy4gSSBkb24ndCB0aGluayB5b3UgbWVhbiB0aGF0 IGF0IGFsbC4NCg0KPg0KDQo+PiBhbmQgdGhlIHJhdGUgZGlmZmVyZW5jZXMgYXJlIG5vdCBkcmFt YXRpYywNCg0KPg0KDQo+IERvIHlvdSBtZWFuIHRoYXQgdGhlIHRvdGFsIHRyYWZmaWMgcmF0ZSBp cyBtb3JlIGZhaXJseSBkaXN0cmlidXRlZCBhY3Jvc3MgdGhlIGxpbmtzPyBJbiBhbnkgY2FzZSwg ImRyYW1hdGljIiBpc24ndCBhbiBlbmdpbmVlcmluZyB0ZXJtLg0KDQoNCg0KPj4gdGhlIGhhc2hp bmcNCg0KPj4gYWxnb3JpdGhtIHdvcmtzIHZlcnkgd2VsbCBpbiBnZW5lcmFsLg0KDQo+DQoNCj4g SG93IGNhbiB5b3Ugc2F5IHRoYXQgd2l0aG91dCBzcGVjaWZ5aW5nIGEgcGFydGljdWxhciBhbGdv cml0aG0/IEFsc28sICJ2ZXJ5IHdlbGwgaW4gZ2VuZXJhbCIgaXNuJ3QgYW4gZW5naW5lZXJpbmcg dGVybSBlaXRoZXIuDQoNCj4NCg0KPj4gVGhlcmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9zaXRpdmVz IGR1ZSB0byBtdWx0aXBsZSBvdGhlciBmbG93cw0KDQo+PiBtYXNxdWVyYWRpbmcgYXMgYSBsYXJn ZSBmbG93OyB0aGUgYW1vdW50IG9mIGZhbHNlIHBvc2l0aXZlcyBpcw0KDQo+PiByZWR1Y2VkIGJ5 IHBhcmFsbGVsIGhhc2hpbmcgdXNpbmcgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb25zDQoNCj4NCg0K PiBUbyBnaXZlIHlvdSBzb21lIGRhdGEsIHdpdGggYSAyMCBiaXQgSUQgc3BhY2UsIHRoZSBGTlYx YS0zMiBoYXNoIGFsZ29yaXRobSBnaXZlcyBhdCBtb3N0IDUlIGNvbGxpc2lvbnMsIGJhc2VkIG9u IElQdjYgaGVhZGVycyBpbiByZWFsIHBhY2tldCB0cmFjZXMuDQoNCj4gW2h0dHBzOi8vcmVzZWFy Y2hzcGFjZS5hdWNrbGFuZC5hYy5uei9oYW5kbGUvMjI5Mi8xMzI0MF0NCg0KPiBJIHdvbmRlciB3 aGV0aGVyIHRoZSBvdmVyaGVhZCBvZiBydW5uaW5nIHNldmVyYWwgaGFzaGVzIGluIHBhcmFsbGVs IGlzIGp1c3RpZmllZCBieSB0aGlzIGNvbGxpc2lvbiByYXRlPw0KDQo+DQoNCj4gUmVnYXJkcw0K DQo+DQoNCj4gICAgQnJpYW4gQ2FycGVudGVyDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KPg0KDQo+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCg0K PiBPUFNBV0dAaWV0Zi5vcmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGll dGYub3JnJTNjbWFpbHRvOk9QU0FXR0BpZXRmLm9yZz4+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DF42HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwg ZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NDQwOTk3Nzg5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxMjYyNzk2ODkyIDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkhpIEJyaWFuLDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDtJIHRoaW5rIGRpZG4ndCBleHBsYWluIG15IHBv aW50IHN1ZmZpY2llbnRseS4gSSB1bmRlcnN0YW5kIHdoeSB5b3Ugc3VnZ2VzdCB1c2luZyBzZXZl cmFsIGhhc2hlcy4gQnV0IHRoaXMgaXMgc3RhdGlzdGljYWwgbG9hZCBiYWxhbmNpbmcgd2UgYXJl IHRhbGtpbmcgJmd0OyZndDthYm91dC4gSWYgYSBmZXcgJSBvZiB0aGUgdGltZSwgeW91IG1pc3Rh a2VubHkgdHJlYXQgc2V2ZXJhbCBtZWRpdW0gZmxvd3MgYXMgb25lIGxhcmdlIGZsb3csIGFuZCB0 aGVyZWZvcmUgcmViYWxhbmNlIHRoZW0gYXMgYSBzaW5nbGUgdW5pdCwgc28gd2hhdD8gJmd0OyZn dDtZb3Ugd2lsbCBzdGlsbCBiYWxhbmNlIHRoZSB0cmFmZmljIHJlYXNvbmFibHkgd2VsbC48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PkVhY2ggb2YgdGhlIGZsb3dzIGlzIGV2ZW50dWFsbHkgbGVhcm50 L3Byb2dyYW1tZWQgaW4gYSBmbG93IHRhYmxlIChoYXJkd2FyZSB0YWJsZSByZXNvdXJjZSB3aGVy ZSB0aGUgZmxvdyBpcyBmaW5hbGx5IGNvbW1pdHRlZCk7IHRoZXJlIGlzIG5ldmVyIGEgY2FzZSBv ZiBidW5kbGluZyBtdWx0aXBsZSBmbG93cy4gTW9yZSBkZXRhaWxzIGJlbG93PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdt c28tbGlzdDpJZ25vcmUnPjEpPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21h biInPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TY2FsYWJsZSBk ZXRlY3Rpb24gb2YgbG9uZy1saXZlZCBsYXJnZSBmbG93cyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+YS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBn b2FsIGlzIHRvIGtlZXAgdGhlIHNpemUgb2YgdGhlIGZsb3cgdGFibGUgKGhhcmR3YXJlIHRhYmxl IHJlc291cmNlIHdoZXJlIHRoZSBsb25nLWxpdmVkIGxhcmdlIGZsb3cgaXMgZmluYWxseSBjb21t aXR0ZWQpIGJvdW5kZWQgYW5kIHRoZSBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cyAoQ1BVIHV0aWxp emF0aW9uKSBmb3IgZmxvdyBsZWFybmluZyBib3VuZGVkLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dCBzdHlsZT0nbWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMiBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0nbXNvLWxpc3Q6SWdub3JlJz5iLjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcg Um9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+Rm9yIHNh dGlzZnlpbmcgdGhlIGFib3ZlIGdvYWwsIHNldmVyYWwgaGFzaGVzIGhlbHBzLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0n bXNvLWxpc3Q6SWdub3JlJz4yKTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9t YW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U2NhbGFibGUg bG9hZC1iYWxhbmNpbmcgb2YgbG9uZy1saXZlZCBsYXJnZSBmbG93cyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9J21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+YS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PlRoZSBnb2FsIGlzIHRvIGhhdmUgYSBzY2FsYWJsZSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiB3 aGljaCBwcm9kdWNlcyBtZWFuaW5nZnVsIHJlc3VsdHMgd2hpbGUga2VlcGluZyB0aGUgcHJvY2Vz c2luZyByZXF1aXJlbWVudHMgKENQVSB1dGlsaXphdGlvbikgZm9yIGxvYWQtYmFsYW5jaW5nIGJv dW5kZWQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSdtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzInPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPmIuPHNwYW4g c3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5Gb3Igc2F0aXNmeWluZyB0aGUgYWJvdmUgZ29hbCwgaXQg aXMgbm90IHdvcnRod2hpbGUgdG8gbG9hZC1iYWxhbmNlIG1lZGl1bS9zbWFsbCBmbG93cy48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PlRoYW5rcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+cmFtPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj5Gcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0gPGJyPlNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxMjowNiBBTTxicj5U bzogcmFta2kgS3Jpc2huYW48YnI+Q2M6IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93 LWxvYWQtYmFsYW5jaW5nQHRvb2xzLmlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc8YnI+U3ViamVj dDogUmU6IFtPUFNBV0ddIEktRCBBY3Rpb246IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1m bG93LWxvYWQtYmFsYW5jaW5nLTAyLnR4dDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+UmFtLDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+T24gMTMvMDEvMjAxMyAwNToxNCwgcmFta2kgS3Jpc2huYW4gd3Jv dGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgSGkgQnJpYW4sPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQ bGVhc2UgZmluZCBhbnN3ZXJzIHRvIHNvbWUgb2YgeW91ciBjb21tZW50cy4gV2Ugd2lsbCByZXNw b25kIHRvIHlvdXIgb3RoZXIgY29tbWVudHMgc2hvcnRseS48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyZndDsgVGhlcmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBtdWx0aXBs ZSBvdGhlciBmbG93cyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZn dDsgbWFzcXVlcmFkaW5nIGFzIGEgbGFyZ2UgZmxvdzsgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3Np dGl2ZXMgaXMgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IHJl ZHVjZWQgYnkgcGFyYWxsZWwgaGFzaGluZyB1c2luZyBkaWZmZXJlbnQgaGFzaCBmdW5jdGlvbnM8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBCcmlhbjo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyZndDsgVG8gZ2l2ZSB5b3Ugc29tZSBkYXRhLCB3aXRoIGEgMjAgYml0IElEIHNwYWNlLCB0aGUg Rk5WMWEtMzIgaGFzaCBhbGdvcml0aG0gZ2l2ZXMgYXQgbW9zdCA1JSBjb2xsaXNpb25zLCBiYXNl ZCBvbiBJUHY2IGhlYWRlcnMgaW4gcmVhbCBwYWNrZXQgdHJhY2VzLsKgIFtodHRwczovL3Jlc2Vh cmNoc3BhY2UuYXVja2xhbmQuYWMubnovaGFuZGxlLzIyOTIvMTMyNDBdLiBJIHdvbmRlciB3aGV0 aGVyIHRoZSBvdmVyaGVhZCBvZiBydW5uaW5nIHNldmVyYWwgaGFzaGVzIGluIHBhcmFsbGVsIGlz IGp1c3RpZmllZCBieSB0aGlzIGNvbGxpc2lvbiByYXRlPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgUmFtOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFRoZSBuZWVkIGZvciBtdWx0 aXBsZSBoYXNoZXMgaXMgc3BlY2lmaWMgdG8gdGhlIHN1Z2dlc3RlZCBhbGdvcml0aG0gb24gYXV0 b21hdGljIGhhcmR3YXJlIGlkZW50aWZpY2F0aW9uIC0gdGhpcyBhbGdvcml0aG0gaXMgc2ltaWxh ciB0byBhIGJsb29tIGZpbHRlciB3aGljaCB1c2VzIG11bHRpcGxlIGhhc2ggZnVuY3Rpb25zLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+SSB0aGluayBkaWRuJ3QgZXhwbGFpbiBteSBwb2ludCBzdWZm aWNpZW50bHkuIEkgdW5kZXJzdGFuZCB3aHkgeW91IHN1Z2dlc3QgdXNpbmcgc2V2ZXJhbCBoYXNo ZXMuIEJ1dCB0aGlzIGlzIHN0YXRpc3RpY2FsIGxvYWQgYmFsYW5jaW5nIHdlIGFyZSB0YWxraW5n IGFib3V0LiBJZiBhIGZldyAlIG9mIHRoZSB0aW1lLCB5b3UgbWlzdGFrZW5seSB0cmVhdCBzZXZl cmFsIG1lZGl1bSBmbG93cyBhcyBvbmUgbGFyZ2UgZmxvdywgYW5kIHRoZXJlZm9yZSByZWJhbGFu Y2UgdGhlbSBhcyBhIHNpbmdsZSB1bml0LCBzbyB3aGF0PyBZb3Ugd2lsbCBzdGlsbCBiYWxhbmNl IHRoZSB0cmFmZmljIHJlYXNvbmFibHkgd2VsbC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PsKgwqDC oCBCcmlhbjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyAmcXVvdDtPbiBwYWNrZXQgYXJyaXZh bCwgYSBuZXcgZmxvdyBpcyBsb29rZWQgdXAgaW4gcGFyYWxsZWwgaW4gYWxsIHRoZSBoYXNoIHRh YmxlcyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgY291bnRlciBpcyBpbmNyZW1lbnRlZC4gSWYgdGhl IGNvdW50ZXIgZXhjZWVkcyBhIHByb2dyYW1tZWQgdGhyZXNob2xkIGluIGEgZ2l2ZW4gdGltZSBp bnRlcnZhbCBpbiBhbGwgdGhlIGhhc2ggdGFibGUgZW50cmllcywgYSBjYW5kaWRhdGUgbGFyZ2Ug ZmxvdyBpcyBsZWFybnQgYW5kIHByb2dyYW1tZWQgaW4gYSBoYXJkd2FyZSB0YWJsZSByZXNvdXJj ZSBsaWtlIFRDQU0uPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IEZvciBhIHNob3J0LWxpdmVk IGZsb3cgdG8gbWFzcXVlcmFkZSBhcyBhIGxvbmctbGl2ZWQgbGl2ZWQgZmxvdywgaXQgbmVlZHMg dG8gbWF0Y2ggYWxsIHRoZSBoYXNoIHRhYmxlIGVudHJpZXMgd2hpY2ggaXMgYSBqb2ludCBwcm9i YWJpbGl0eSBldmVudCAtIHRodXMsIHRoZSBhbW91bnQgb2YgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0 byBzaG9ydC1saXZlZCBmbG93cyBpcyByZWR1Y2VkLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyBUaGFua3MsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgcmFtPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86b3BzYXdnLWJvdW5jZXNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lJz5vcHNhd2ctYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IFs8YSBocmVmPSJtYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lJz5tYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9hPl0gT24gPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgQmVoYWxm IE9mIEJyaWFuIEUgQ2FycGVudGVyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTIsIDIwMTMgODo0MCBBTTxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQt a3Jpc2huYW4tb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lJz5kcmFm dC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9y Zzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgQ2M6 IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lJz5vcHNhd2dAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFN1YmplY3Q6IFJlOiBbT1BT QVdHXSBJLUQgQWN0aW9uOiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyBkcmFmdC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZy0wMi50eHQ8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBIaSw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBN eSBjb21tZW50cyBhcmUgb24gdGhlIGRpc2N1c3Npb24gb2YgZmxvdyBJRHMgYW5kIGhhc2hpbmcu IEknbSBub3QgY29tbWVudGluZyBhdCBhbGwgb24gdGhlIG92ZXJhbGwgcHJvcG9zYWwsIGJlY2F1 c2UgSSBjYW4ndCBqdWRnZSB3aGV0aGVyIHRoZSBwcm9ibGVtIGlzIHJlYWwgb3IgdGhlIHNvbHV0 aW9uIGlzIHByYWN0aWNhbC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgQSBsYXJnZSBz cGFjZSBvZiB0aGUgZmxvdyBpZGVudGlmaWNhdGlvbnMsIGkuZS4gZmluZXI8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyZndDsgZ3JhbnVsYXJpdHkgb2YgdGhlIGZsb3dzLCBjb25kdWN0cyBtb3Jl IHJhbmRvbSBpbiBzcHJlYWRpbmcgdGhlIGZsb3dzIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyBvdmVyIGEgc2V0IG9mIGNvbXBvbmVudCBsaW5rcy48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyBUaGF0IGlzbid0IGFjY3VyYXRlLiBUaGUgcmVxdWlyZW1lbnQg aXMgYW4gSUQgc3BhY2UgaW4gd2hpY2ggdGhlIElEcyBiZWxvbmcgdG8gYSB1bmlmb3JtIGRpc3Ry aWJ1dGlvbi4gVGVjaG5pY2FsbHkgc3BlYWtpbmcsIGlmIHlvdSBoYXZlIHR3byBsaW5rcywgYSBv bmUtYml0IGZsb3cgSUQgaXMgc3VmZmljaWVudCwgYXMgbG9uZyBhcyB0aGUgdmFsdWVzIDAgYW5k IDEgYXJlIGVxdWFsbHkgbGlrZWx5IHRvIGFwcGVhci48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyBUaGVyZWZvcmUsIHRoZSBwcmFjdGljYWwgaXNzdWUgaXMgbm90IHRo ZSBzaXplIG9mIHRoZSBJRCBzcGFjZSBidXQgdGhlIHF1YWxpdHkgb2YgdGhlIGhhc2ggZnVuY3Rp b24gdXNlZCB0byBnZW5lcmF0ZSB0aGUgSUQgb2YgZWFjaCBmbG93LjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IEhvd2V2ZXIsIHdoYXRldmVyIHRoZSBpbml0aWFsIElE IHNwYWNlLCB0aGUgZmluYWwgaGFzaCBoYXMgdG8gYmUgZG93biB0byAwLi5OIGlmIHlvdSBoYXZl IE4rMSBhbHRlcm5hdGl2ZSBwYXRocy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyBJIHRoaW5rIHRoZSByZWFzb24gdGhhdCB5b3VyIG1vZGVsIG5lZWRzIGEgbGFyZ2Vy IElEIHNwYWNlIGlzIHRvIHJlZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgdHdvIGZsb3dzIGNvbGxp ZGluZyBieSBjaGFuY2UgaW4gdGhlIElEIHNwYWNlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IFRoYXQgd291bGQgZGVmZWF0IHlvdXIgd2lzaCB0byBzZXBhcmF0ZSBv dXQgbGFyZ2UgZmxvd3MuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFRoZSBhZHZhbnRh Z2VzIG9mIGhhc2hpbmcgYmFzZWQgbG9hZDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7Jmd0OyBkaXN0cmlidXRpb24gYXJlIHRoZSBwcmVzZXJ2YXRpb24gb2YgdGhlIHBh Y2tldCBzZXF1ZW5jZSBpbiBhIGZsb3cgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsmZ3Q7IGFuZCB0aGUgcmVhbCB0aW1lIGRpc3RyaWJ1dGlvbiB3aXRoIHRoZSBzdGF0 ZWxlc3Mgb2YgaW5kaXZpZHVhbCA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyZndDsgZmxvd3MuIElmIHRoZSB0cmFmZmljIGZsb3dzIHJhbmRvbWx5IHNwcmVhZCBpbiB0 aGUgZmxvdyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgaWRl bnRpZmljYXRpb24gc3BhY2UsIHRoZSBmbG93IHJhdGVzIGFyZSBtdWNoIHNtYWxsZXIgY29tcGFy ZWQgdG8gdGhlIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBs aW5rIGNhcGFjaXR5LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFRoYXQgc291bmRzIGxpa2Ug bWFnaWMuIEkgZG9uJ3QgdGhpbmsgeW91IG1lYW4gdGhhdCBhdCBhbGwuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsmZ3Q7IGFuZCB0aGUgcmF0ZSBkaWZmZXJlbmNlcyBhcmUgbm90IGRyYW1hdGlj LDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IERvIHlvdSBtZWFuIHRoYXQgdGhlIHRvdGFsIHRy YWZmaWMgcmF0ZSBpcyBtb3JlIGZhaXJseSBkaXN0cmlidXRlZCBhY3Jvc3MgdGhlIGxpbmtzPyBJ biBhbnkgY2FzZSwgJnF1b3Q7ZHJhbWF0aWMmcXVvdDsgaXNuJ3QgYW4gZW5naW5lZXJpbmcgdGVy bS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IHRoZSBoYXNoaW5nPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IGFsZ29yaXRobSB3b3JrcyB2ZXJ5IHdl bGwgaW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBIb3cgY2FuIHlvdSBzYXkg dGhhdCB3aXRob3V0IHNwZWNpZnlpbmcgYSBwYXJ0aWN1bGFyIGFsZ29yaXRobT8gQWxzbywgJnF1 b3Q7dmVyeSB3ZWxsIGluIGdlbmVyYWwmcXVvdDsgaXNuJ3QgYW4gZW5naW5lZXJpbmcgdGVybSBl aXRoZXIuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFRoZXJlIG1heSBiZSBzb21lIGZh bHNlIHBvc2l0aXZlcyBkdWUgdG8gbXVsdGlwbGUgb3RoZXIgZmxvd3MgPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IG1hc3F1ZXJhZGluZyBhcyBhIGxhcmdlIGZs b3c7IHRoZSBhbW91bnQgb2YgZmFsc2UgcG9zaXRpdmVzIGlzIDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyByZWR1Y2VkIGJ5IHBhcmFsbGVsIGhhc2hpbmcgdXNp bmcgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb25zPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgVG8g Z2l2ZSB5b3Ugc29tZSBkYXRhLCB3aXRoIGEgMjAgYml0IElEIHNwYWNlLCB0aGUgRk5WMWEtMzIg aGFzaCBhbGdvcml0aG0gZ2l2ZXMgYXQgbW9zdCA1JSBjb2xsaXNpb25zLCBiYXNlZCBvbiBJUHY2 IGhlYWRlcnMgaW4gcmVhbCBwYWNrZXQgdHJhY2VzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IFtodHRwczovL3Jlc2VhcmNoc3BhY2UuYXVja2xhbmQuYWMubnovaGFu ZGxlLzIyOTIvMTMyNDBdPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg SSB3b25kZXIgd2hldGhlciB0aGUgb3ZlcmhlYWQgb2YgcnVubmluZyBzZXZlcmFsIGhhc2hlcyBp biBwYXJhbGxlbCBpcyBqdXN0aWZpZWQgYnkgdGhpcyBjb2xsaXNpb24gcmF0ZT88bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyBSZWdhcmRzPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDvCoMKgwqAg QnJpYW4gQ2FycGVudGVyPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyBPUFNBV0cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgPGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9yZyUzY21h aWx0bzpPUFNBV0dAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lJz5PUFNBV0dAaWV0Zi5vcmcmbHQ7bWFpbHRvOk9QU0FXR0BpZXRmLm9y Zzwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnIj48 c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSc+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1DF42HQ1EXCH01corp_-- From lucy.yong@huawei.com Mon Jan 14 10:00:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513D921F88C7 for ; Mon, 14 Jan 2013 10:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kASFjGzzVBRd for ; Mon, 14 Jan 2013 10:00:26 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E78F021F88BE for ; Mon, 14 Jan 2013 10:00:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT60249; Mon, 14 Jan 2013 18:00:24 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Jan 2013 18:00:17 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 02:00:22 +0800 Received: from DFWEML505-MBB.china.huawei.com ([169.254.1.58]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 14 Jan 2013 10:00:18 -0800 From: Lucy yong To: Brian E Carpenter , "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" Thread-Topic: I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: AQHN8OOGoNx0rEEcvEGwd3lyK+WVX5hJHNOg Date: Mon, 14 Jan 2013 18:00:17 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D4486FD3B@dfweml505-mbb.china.huawei.com> References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> In-Reply-To: <50F191EC.8040306@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ElGA GT+8 Jdx0 KaPr LYAm L4Er MDQa MIaW OmmQ TaIp To7e Tpup UHv8 Vne6 X7CJ ZE9Y; 3; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBkAHIAYQBmAHQALQBrAHIAaQBzAGgAbgBhAG4ALQBvAHAAcwBhAHcAZwAtAGwAYQByAGcAZQAtAGYAbABvAHcALQBsAG8AYQBkAC0AYgBhAGwAYQBuAGMAaQBuAGcAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBvAHAAcwBhAHcAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {C9113EFB-ECE3-4788-B20A-8C4A1E371FEE}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon, 14 Jan 2013 18:00:12 GMT; UgBFADoAIABJAC0ARAAgAEEAYwB0AGkAbwBuADoAIABkAHIAYQBmAHQALQBrAHIAaQBzAGgAbgBhAG4ALQBvAHAAcwBhAHcAZwAtAGwAYQByAGcAZQAtAGYAbABvAHcALQBsAG8AYQBkAC0AYgBhAGwAYQBuAGMAaQBuAGcALQAwADIALgB0AHgAdAA= x-cr-puzzleid: {C9113EFB-ECE3-4788-B20A-8C4A1E371FEE} x-originating-ip: [10.47.86.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 14 Jan 2013 14:22:07 -0800 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:00:28 -0000 SGkgQnJpYW4sDQoNCkkgdGhpbmsgd2UgYXJlIG5vdCBkaXNjdXNzaW5nIGRpZmZlcmVudCB0aGlu Z3MuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tXQ0KPiBTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxMiwgMjAxMyAxMDo0MCBBTQ0KPiBUbzog ZHJhZnQta3Jpc2huYW4tb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0 Zi5vcmcNCj4gQ2M6IG9wc2F3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSS1EIEFjdGlvbjog ZHJhZnQta3Jpc2huYW4tb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC0NCj4gYmFsYW5jaW5nLTAyLnR4 dA0KPiANCj4gSGksDQo+IA0KPiBNeSBjb21tZW50cyBhcmUgb24gdGhlIGRpc2N1c3Npb24gb2Yg ZmxvdyBJRHMgYW5kIGhhc2hpbmcuIEknbSBub3QNCj4gY29tbWVudGluZyBhdCBhbGwgb24gdGhl IG92ZXJhbGwgcHJvcG9zYWwsIGJlY2F1c2UgSSBjYW4ndCBqdWRnZQ0KPiB3aGV0aGVyIHRoZSBw cm9ibGVtIGlzIHJlYWwgb3IgdGhlIHNvbHV0aW9uIGlzIHByYWN0aWNhbC4NCj4gDQo+ID4gQSBs YXJnZSBzcGFjZSBvZiB0aGUgZmxvdyBpZGVudGlmaWNhdGlvbnMsIGkuZS4gZmluZXINCj4gPiBn cmFudWxhcml0eSBvZiB0aGUgZmxvd3MsIGNvbmR1Y3RzIG1vcmUgcmFuZG9tIGluIHNwcmVhZGlu ZyB0aGUgZmxvd3MNCj4gDQo+ID4gb3ZlciBhIHNldCBvZiBjb21wb25lbnQgbGlua3MuDQo+IA0K PiBUaGF0IGlzbid0IGFjY3VyYXRlLiBUaGUgcmVxdWlyZW1lbnQgaXMgYW4gSUQgc3BhY2UgaW4g d2hpY2ggdGhlIElEcw0KPiBiZWxvbmcgdG8gYSB1bmlmb3JtIGRpc3RyaWJ1dGlvbi4gVGVjaG5p Y2FsbHkgc3BlYWtpbmcsIGlmIHlvdSBoYXZlIHR3bw0KPiBsaW5rcywgYSBvbmUtYml0IGZsb3cg SUQgaXMgc3VmZmljaWVudCwgYXMgbG9uZyBhcyB0aGUgdmFsdWVzIDAgYW5kIDENCj4gYXJlDQo+ IGVxdWFsbHkgbGlrZWx5IHRvIGFwcGVhci4NCltMdWN5XSBUaGlzIGlzIG5vdCByZXF1aXJlbWVu dCBmb3IgdGhlIElEIHNwYWNlLiBJdCBpcyB0byBzYXkgdGhhdCB1c2luZyA1IHR1cGxlIG9yIDMg dHVwbGUgdG8gZGVmaW5lIGEgZmxvdyByZXN1bHRzIGEgdmVyeSBsYXJnZSBmbG93IElEIHNwYWNl LiBUaGlzIGZsb3cgZGVmaW5pdGlvbiBpcyB0eXBpY2FsbHkgdXNlZCBpbiBoYXNoaW5nIGJhc2Vk IGxvYWQgYmFsYW5jZSB0b2RheS4gVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIGhvdyBtYW55 IGxpbmtzLiBXZSB3aWxsIHJlZmluZSB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFyLiANCg0KPiAN Cj4gVGhlcmVmb3JlLCB0aGUgcHJhY3RpY2FsIGlzc3VlIGlzIG5vdCB0aGUgc2l6ZSBvZiB0aGUg SUQgc3BhY2UgYnV0IHRoZQ0KPiBxdWFsaXR5IG9mIHRoZSBoYXNoIGZ1bmN0aW9uIHVzZWQgdG8g Z2VuZXJhdGUgdGhlIElEIG9mIGVhY2ggZmxvdy4NCj4gSG93ZXZlciwgd2hhdGV2ZXIgdGhlIGlu aXRpYWwgSUQgc3BhY2UsIHRoZSBmaW5hbCBoYXNoIGhhcyB0byBiZSBkb3duDQo+IHRvIDAuLk4g aWYgeW91IGhhdmUgTisxIGFsdGVybmF0aXZlIHBhdGhzLg0KW0x1Y3ldIFRoZSBkcmFmdCBkb2Vz IG5vdCBhZGRyZXNzIHVzaW5nIGhhc2hpbmcgdG8gZ2VuZXJhdGUgdGhlIGZsb3cgSUQgYXQgYWxs LiBXZSBhcmUgYWNyb3NzIGVhY2ggb3RoZXIgaGVyZS4gWW91IG1heSByZWZlciBzb21lIGRpZmZl cmVudCBhcHBsaWNhdGlvbnMuDQoNClJlZ2FyZHMsDQpMdWN5DQo+IA0KPiBJIHRoaW5rIHRoZSBy ZWFzb24gdGhhdCB5b3VyIG1vZGVsIG5lZWRzIGEgbGFyZ2VyIElEIHNwYWNlIGlzIHRvDQo+IHJl ZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgdHdvIGZsb3dzIGNvbGxpZGluZyBieSBjaGFuY2UgaW4g dGhlIElEIHNwYWNlLg0KPiBUaGF0IHdvdWxkIGRlZmVhdCB5b3VyIHdpc2ggdG8gc2VwYXJhdGUg b3V0IGxhcmdlIGZsb3dzLg0KPiANCj4gPiBUaGUgYWR2YW50YWdlcyBvZiBoYXNoaW5nIGJhc2Vk IGxvYWQNCj4gPiBkaXN0cmlidXRpb24gYXJlIHRoZSBwcmVzZXJ2YXRpb24gb2YgdGhlIHBhY2tl dCBzZXF1ZW5jZSBpbiBhIGZsb3cNCj4gDQo+ID4gYW5kIHRoZSByZWFsIHRpbWUgZGlzdHJpYnV0 aW9uIHdpdGggdGhlIHN0YXRlbGVzcyBvZiBpbmRpdmlkdWFsDQo+ID4gZmxvd3MuIElmIHRoZSB0 cmFmZmljIGZsb3dzIHJhbmRvbWx5IHNwcmVhZCBpbiB0aGUgZmxvdw0KPiA+IGlkZW50aWZpY2F0 aW9uIHNwYWNlLCB0aGUgZmxvdyByYXRlcyBhcmUgbXVjaCBzbWFsbGVyIGNvbXBhcmVkIHRvIHRo ZQ0KPiANCj4gPiBsaW5rIGNhcGFjaXR5LA0KPiANCj4gVGhhdCBzb3VuZHMgbGlrZSBtYWdpYy4g SSBkb24ndCB0aGluayB5b3UgbWVhbiB0aGF0IGF0IGFsbC4NCj4gDQo+ID4gYW5kIHRoZSByYXRl IGRpZmZlcmVuY2VzIGFyZSBub3QgZHJhbWF0aWMsDQo+IA0KPiBEbyB5b3UgbWVhbiB0aGF0IHRo ZSB0b3RhbCB0cmFmZmljIHJhdGUgaXMgbW9yZSBmYWlybHkgZGlzdHJpYnV0ZWQNCj4gYWNyb3Nz IHRoZSBsaW5rcz8gSW4gYW55IGNhc2UsICJkcmFtYXRpYyIgaXNuJ3QgYW4gZW5naW5lZXJpbmcg dGVybS4NCj4gDQo+ID4gdGhlIGhhc2hpbmcNCj4gPiBhbGdvcml0aG0gd29ya3MgdmVyeSB3ZWxs IGluIGdlbmVyYWwuDQo+IA0KPiBIb3cgY2FuIHlvdSBzYXkgdGhhdCB3aXRob3V0IHNwZWNpZnlp bmcgYSBwYXJ0aWN1bGFyIGFsZ29yaXRobT8gQWxzbywNCj4gInZlcnkgd2VsbCBpbiBnZW5lcmFs IiBpc24ndCBhbiBlbmdpbmVlcmluZyB0ZXJtIGVpdGhlci4NCj4gDQo+ID4gVGhlcmUgbWF5IGJl IHNvbWUgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBtdWx0aXBsZSBvdGhlciBmbG93cw0KPiA+IG1h c3F1ZXJhZGluZyBhcyBhIGxhcmdlIGZsb3c7IHRoZSBhbW91bnQgb2YgZmFsc2UgcG9zaXRpdmVz IGlzDQo+ID4gcmVkdWNlZCBieSBwYXJhbGxlbCBoYXNoaW5nIHVzaW5nIGRpZmZlcmVudCBoYXNo IGZ1bmN0aW9ucw0KPiANCj4gVG8gZ2l2ZSB5b3Ugc29tZSBkYXRhLCB3aXRoIGEgMjAgYml0IElE IHNwYWNlLCB0aGUgRk5WMWEtMzIgaGFzaA0KPiBhbGdvcml0aG0gZ2l2ZXMgYXQgbW9zdCA1JSBj b2xsaXNpb25zLCBiYXNlZCBvbiBJUHY2IGhlYWRlcnMgaW4gcmVhbA0KPiBwYWNrZXQgdHJhY2Vz Lg0KPiBbaHR0cHM6Ly9yZXNlYXJjaHNwYWNlLmF1Y2tsYW5kLmFjLm56L2hhbmRsZS8yMjkyLzEz MjQwXQ0KPiANCj4gSSB3b25kZXIgd2hldGhlciB0aGUgb3ZlcmhlYWQgb2YgcnVubmluZyBzZXZl cmFsIGhhc2hlcyBpbiBwYXJhbGxlbA0KPiBpcyBqdXN0aWZpZWQgYnkgdGhpcyBjb2xsaXNpb24g cmF0ZT8NCj4gDQo+IFJlZ2FyZHMNCj4gICAgQnJpYW4gQ2FycGVudGVyDQoNCg== From brian.e.carpenter@gmail.com Tue Jan 15 00:05:46 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6647021F8B11 for ; Tue, 15 Jan 2013 00:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.458 X-Spam-Level: X-Spam-Status: No, score=-101.458 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lFoFL4XcttK for ; Tue, 15 Jan 2013 00:05:45 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9A821F8AC3 for ; Tue, 15 Jan 2013 00:05:44 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so2004281wib.7 for ; Tue, 15 Jan 2013 00:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0d5nAKoT3x/mTB1u7VSrsr3XlTejHtOCJUUKfwc4jz4=; b=pHbACT5dzTx6J2gONAO/Mx5TQvezaqEDTYQv59MuiqJz/XjL8JpMiCvXxD9ivQjpbn 11fa0SGqgsLpHMu33e+KiI9Csj2vJ70DxMGaoDLsXmn4MGLWUcgoFLHotT7+9wTzfTum 8eHqNm0wR9xhGBSS1GwZdk4R9iDwMMJjX2ok1nzdgekzGl1LUDL6rjbz5c/bDSBA4VmY J+C5AzV+nINN8qMfWQS1XiqwLnKCDFUdpurF0K9LW3cEXoKa7fUu35LAIAPzzY9a4I2N 8E3q7uWNa7Oy/C0V5iuvrtq9wvhBp0YGzHC0+1UK9uwkajdXKlGudX/rid3KAWQpPKsA MC1g== X-Received: by 10.194.158.100 with SMTP id wt4mr36410806wjb.37.1358237144227; Tue, 15 Jan 2013 00:05:44 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-126.as13285.net. [2.102.216.126]) by mx.google.com with ESMTPS id hg17sm2325242wib.1.2013.01.15.00.05.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 00:05:43 -0800 (PST) Message-ID: <50F50DDB.4020603@gmail.com> Date: Tue, 15 Jan 2013 08:05:47 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lucy yong References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4486FD3B@dfweml505-mbb.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D4486FD3B@dfweml505-mbb.china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:05:46 -0000 On 14/01/2013 18:00, Lucy yong wrote: > Hi Brian, > > I think we are not discussing different things. Please see inline. I think the problem is that the draft doesn't explain the fundamental model very well. I fully agree with your comments below (and these aspects are discussed in RFC 6438). Brian > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Saturday, January 12, 2013 10:40 AM >> To: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org >> Cc: opsawg@ietf.org >> Subject: Re: I-D Action: draft-krishnan-opsawg-large-flow-load- >> balancing-02.txt >> >> Hi, >> >> My comments are on the discussion of flow IDs and hashing. I'm not >> commenting at all on the overall proposal, because I can't judge >> whether the problem is real or the solution is practical. >> >>> A large space of the flow identifications, i.e. finer >>> granularity of the flows, conducts more random in spreading the flows >>> over a set of component links. >> That isn't accurate. The requirement is an ID space in which the IDs >> belong to a uniform distribution. Technically speaking, if you have two >> links, a one-bit flow ID is sufficient, as long as the values 0 and 1 >> are >> equally likely to appear. > [Lucy] This is not requirement for the ID space. It is to say that using 5 tuple or 3 tuple to define a flow results a very large flow ID space. This flow definition is typically used in hashing based load balance today. This has nothing to do with how many links. We will refine the text to make it clear. > >> Therefore, the practical issue is not the size of the ID space but the >> quality of the hash function used to generate the ID of each flow. >> However, whatever the initial ID space, the final hash has to be down >> to 0..N if you have N+1 alternative paths. > [Lucy] The draft does not address using hashing to generate the flow ID at all. We are across each other here. You may refer some different applications. > > Regards, > Lucy >> I think the reason that your model needs a larger ID space is to >> reduce the probability of two flows colliding by chance in the ID space. >> That would defeat your wish to separate out large flows. >> >>> The advantages of hashing based load >>> distribution are the preservation of the packet sequence in a flow >>> and the real time distribution with the stateless of individual >>> flows. If the traffic flows randomly spread in the flow >>> identification space, the flow rates are much smaller compared to the >>> link capacity, >> That sounds like magic. I don't think you mean that at all. >> >>> and the rate differences are not dramatic, >> Do you mean that the total traffic rate is more fairly distributed >> across the links? In any case, "dramatic" isn't an engineering term. >> >>> the hashing >>> algorithm works very well in general. >> How can you say that without specifying a particular algorithm? Also, >> "very well in general" isn't an engineering term either. >> >>> There may be some false positives due to multiple other flows >>> masquerading as a large flow; the amount of false positives is >>> reduced by parallel hashing using different hash functions >> To give you some data, with a 20 bit ID space, the FNV1a-32 hash >> algorithm gives at most 5% collisions, based on IPv6 headers in real >> packet traces. >> [https://researchspace.auckland.ac.nz/handle/2292/13240] >> >> I wonder whether the overhead of running several hashes in parallel >> is justified by this collision rate? >> >> Regards >> Brian Carpenter > From brian.e.carpenter@gmail.com Tue Jan 15 00:12:41 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044CC21F852C for ; Tue, 15 Jan 2013 00:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.467 X-Spam-Level: X-Spam-Status: No, score=-101.467 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpwIwFd4EbLV for ; Tue, 15 Jan 2013 00:12:40 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9821F84C6 for ; Tue, 15 Jan 2013 00:12:39 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm2so2008807wib.10 for ; Tue, 15 Jan 2013 00:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=irjXFYBEv1tEvYVQLC1kJHXvTgwKFoGCPOD3JqJ3bLo=; b=Y1wQQBS+/SasQzMHYaKy/t/mD7JQdsRC43IdMGj4QHJfngkW+Ou77S2buYoysoxHra lzxQjzbIQx3/Dk1pyvz4p97+5Jm3ZL9J/9avnEQEygc1rMbaOhKWRCX8LX0p+RGDEHzl /ujI1lu3AhksYqvB2pGmnGkzHAK0JX3BxXsjos6Vh4vWyKf+SWYfy9gSJiT1rI/iQSso Wjfu4O0SOdsOq+M9jXqBtGetgdUyrua4O6IggiQd1P0eQSP+pK9zygCtOq4hkNubOMms j1DOtLZmouYBJsMU51vIb7gMi6E9r4SPh1yFwXpv/ofEWU/VCg+t/OKBwsYBbXsjDEuU Nyig== X-Received: by 10.194.142.162 with SMTP id rx2mr27896531wjb.17.1358237558811; Tue, 15 Jan 2013 00:12:38 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-126.as13285.net. [2.102.216.126]) by mx.google.com with ESMTPS id s10sm2591920wiw.4.2013.01.15.00.12.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 00:12:38 -0800 (PST) Message-ID: <50F50F7A.1070001@gmail.com> Date: Tue, 15 Jan 2013 08:12:42 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ramki Krishnan References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org, "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:12:41 -0000 Ram, I understand everything you say below. But you aren't commenting on my main point: why is it worth the *extra* cost of running several hashes in parallel to exclude a *small* fraction of mis-identified large flows? To me, that is not a useful engineering trade-off. Regards Brian On 14/01/2013 17:48, ramki Krishnan wrote: > Hi Brian, > > > >>> I think didn't explain my point sufficiently. I understand why you suggest using several hashes. But this is statistical load balancing we are talking >>about. If a few % of the time, you mistakenly treat several medium flows as one large flow, and therefore rebalance them as a single unit, so what? >>You will still balance the traffic reasonably well. > > > > Each of the flows is eventually learnt/programmed in a flow table (hardware table resource where the flow is finally committed); there is never a case of bundling multiple flows. More details below > > > > 1) Scalable detection of long-lived large flows > > a. The goal is to keep the size of the flow table (hardware table resource where the long-lived large flow is finally committed) bounded and the processing requirements (CPU utilization) for flow learning bounded. > > b. For satisfying the above goal, several hashes helps. > > > > 2) Scalable load-balancing of long-lived large flows > > a. The goal is to have a scalable load balancing solution which produces meaningful results while keeping the processing requirements (CPU utilization) for load-balancing bounded. > > b. For satisfying the above goal, it is not worthwhile to load-balance medium/small flows. > > > > Thanks, > > ram > > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Sunday, January 13, 2013 12:06 AM > To: ramki Krishnan > Cc: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > > > Ram, > > > > On 13/01/2013 05:14, ramki Krishnan wrote: > >> Hi Brian, > > >> Thanks a lot for your comments. Please find answers to some of your comments. We will respond to your other comments shortly. > > >>> There may be some false positives due to multiple other flows > >>> masquerading as a large flow; the amount of false positives is > >>> reduced by parallel hashing using different hash functions > > >> Brian: > > >>> To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. [https://researchspace.auckland.ac.nz/handle/2292/13240]. I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > >> Ram: > > >> The need for multiple hashes is specific to the suggested algorithm on automatic hardware identification - this algorithm is similar to a bloom filter which uses multiple hash functions. > > > > I think didn't explain my point sufficiently. I understand why you suggest using several hashes. But this is statistical load balancing we are talking about. If a few % of the time, you mistakenly treat several medium flows as one large flow, and therefore rebalance them as a single unit, so what? You will still balance the traffic reasonably well. > > > > Brian > > > >> "On packet arrival, a new flow is looked up in parallel in all the hash tables and the corresponding counter is incremented. If the counter exceeds a programmed threshold in a given time interval in all the hash table entries, a candidate large flow is learnt and programmed in a hardware table resource like TCAM. > > > >> For a short-lived flow to masquerade as a long-lived lived flow, it needs to match all the hash table entries which is a joint probability event - thus, the amount of false positives due to short-lived flows is reduced. > > > >> Thanks, > > >> ram > > >> -----Original Message----- > >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > >> Behalf Of Brian E Carpenter > >> Sent: Saturday, January 12, 2013 8:40 AM > >> To: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org > >> Cc: opsawg@ietf.org > >> Subject: Re: [OPSAWG] I-D Action: > >> draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > >> Hi, > > >> My comments are on the discussion of flow IDs and hashing. I'm not commenting at all on the overall proposal, because I can't judge whether the problem is real or the solution is practical. > > >>> A large space of the flow identifications, i.e. finer > > >>> granularity of the flows, conducts more random in spreading the flows > >>> over a set of component links. > > >> That isn't accurate. The requirement is an ID space in which the IDs belong to a uniform distribution. Technically speaking, if you have two links, a one-bit flow ID is sufficient, as long as the values 0 and 1 are equally likely to appear. > >> Therefore, the practical issue is not the size of the ID space but the quality of the hash function used to generate the ID of each flow. > >> However, whatever the initial ID space, the final hash has to be down to 0..N if you have N+1 alternative paths. > >> I think the reason that your model needs a larger ID space is to reduce the probability of two flows colliding by chance in the ID space. > >> That would defeat your wish to separate out large flows. > > >>> The advantages of hashing based load > >>> distribution are the preservation of the packet sequence in a flow > >>> and the real time distribution with the stateless of individual > >>> flows. If the traffic flows randomly spread in the flow > >>> identification space, the flow rates are much smaller compared to the > >>> link capacity, > > >> That sounds like magic. I don't think you mean that at all. > > >>> and the rate differences are not dramatic, > > >> Do you mean that the total traffic rate is more fairly distributed across the links? In any case, "dramatic" isn't an engineering term. > > > >>> the hashing > >>> algorithm works very well in general. > > >> How can you say that without specifying a particular algorithm? Also, "very well in general" isn't an engineering term either. > > >>> There may be some false positives due to multiple other flows > >>> masquerading as a large flow; the amount of false positives is > >>> reduced by parallel hashing using different hash functions > > >> To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. > >> [https://researchspace.auckland.ac.nz/handle/2292/13240] > >> I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > >> Regards > > >> Brian Carpenter > >> _______________________________________________ > > >> OPSAWG mailing list > >> OPSAWG@ietf.org> > >> https://www.ietf.org/mailman/listinfo/opsawg From bclaise@cisco.com Tue Jan 15 06:49:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3C21F8650; Tue, 15 Jan 2013 06:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE0xIIH1jILy; Tue, 15 Jan 2013 06:49:18 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 998FD21F8635; Tue, 15 Jan 2013 06:49:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0FEnCkM028129; Tue, 15 Jan 2013 15:49:13 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0FEmf99029043; Tue, 15 Jan 2013 15:48:51 +0100 (CET) Message-ID: <50F56C49.6090103@cisco.com> Date: Tue, 15 Jan 2013 15:48:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "draft-ietf-opsawg-oam-overview@tools.ietf.org" References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> In-Reply-To: <50F437BF.8040005@cisco.com> Content-Type: multipart/alternative; boundary="------------090504060000040407050407" Cc: opsawg@ietf.org, ietf@ietf.org, Al Morton Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:49:22 -0000 This is a multi-part message in MIME format. --------------090504060000040407050407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some more feedback, send on behalf of Al Morton. Regards, Benoit ================================================= Hi Benoit, Here are some additional comments, just checking a few things I know a little about. Al -=-=-=-=-=-=-=-=-=-=-=-=-=-=- 1.1. The Building Blocks of OAM ... o Performance Monitoring: Consists of 3 main functions o Loss Measurement (LM) - monitors the packet loss rate of a connection. o Delay Measurement (DM) - monitors the delay and delay variation between MPs. o Throughput measurement - monitors the throughput of a connection. >>> Apparently, no OAM tool currently measures Throughput, because no such tool is cited in the memo (and the term "throughput" never appears again). my guess is that there was some reference to RFC 2544 that has now been removed. Remove Throughput from the list. 1.3 OAM Toolsets ... o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. >>> and Delay variation, duplication, reordering, etc. (all the metrics limited tools completely ignore). 1.4 IETF OAM Documents >>> Expand Table 1 as noted above, to include all the metrics they missed. 3.6.1 ... TWAMP [TWAMP] is a similar protocol that enables measurement of >>> both one-way and two-way (round trip) characteristics. >>> sentence below is simply not true, because the authors did not understand the one-way measurement capability: TWAMP does not require accurate time of day, and, furthermore, allows the use of a simple session reflector, making it an attractive alternative to OWAMP. >>> go back and read the memo... 3.7. Summary of OAM Functions Table 3 summarizes the OAM functions that are supported in each of the categories that were analyzed in this section. +-----------+-------+--------+--------+-----------+-------+--------+ | Standard |Continu|Connecti|Path |Defect |Perform|Other | | |ity |vity |Discover|Indications|ance |Function| | |Check |Verifica|y | |Monitor|s | | | |tion | | |ing | | +-----------+-------+--------+--------+-----------+-------+--------+ ... + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |OWAMP and | | | | |-Delay | | |TWAMP | Yes | Yes | | | measur| | | | | | | | ement | | | | | | | |-Packet| | | | | | | | loss | | | | | | | | measur| | | | | | | | ement | | +-----------+-------+--------+--------+-----------+-------+--------+ Table 3 Summary of OAM Functions >>> Both Continuity Check and Connectivity Verification are tested and confirmed by establishing the *WAMP Control Protocol TCP connection, so this should be indicated the table. > draft-ietf-opsawg-oam-overview authors, > > Here is my feedback on this document. > > 1. > Is this document in line with > http://tools.ietf.org/html/draft-ietf-trill-oam-req-04? > * For example, the following definitions could be reused. > Fault: The term Fault refers to an inability to perform a required > action, e.g., an unsuccessful attempt to deliver a packet. > > Defect: The term Defect refers to an interruption in the normal > operation, such that over a period of time no packets are delivered > successfully. > > Failure: The term Failure refers to the termination of the required > function over a longer period of time. Persistence of a defect for a > period of time is interpreted as a failure. > > * For example, on the basic abstract > Abstract > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. > > Abstract (draft-ietf-trill-oam-req-04) > > OAM (Operations, Administration and Maintenance) is a general term > used to identify functions and toolsets to troubleshoot and monitor > networks. This document presents, OAM Requirements applicable to > TRILL. > > So, as an example: does OAM include function? > I advice to review draft-ietf-trill-oam-req-04 > > 2. > draft-ietf-trill-oam is not mentioned, while the abstract mentions: > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references. > Ok, I see later on: > This document focuses on IETF > documents that have been published as RFCs, while other ongoing OAM- > related work is outside the scope. > Ok, fine then: we don't need a reference to all the drafts. > However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned. > > > 3. > Section 1 > The term OAM in this document refers to Operations, Administration > and Maintenance [OAM-Def ], focusing on the forwarding plane of OAM. > What does it mean "focusing on the forwarding plane of OAM"? > Do you take a subset of the definition for this document? > Btw, I don't see a definition in the terminology section. > In section 2.2.3 > A Maintenance Point (MP) is a functional entity that is defined at a > node in the network, and either initiates or reacts to OAM messages. > Which plane is MP? > > 4. > Section 1, Introduction > "Hence, management aspects are outside the scope of this document." > I don't understand which management aspects we speak about here. > 5. > Clarifying question regarding 1.2 > If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, > control plane, or management plane? > Note that I found later on in the draft: > OWAMP and TWAMP use two separate protocols: a Control plane protocol, > and a Test plane protocol. > Interestingly enough, after reading the document, I reviewed > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and > saw the same feedback from Stewart Bryant: > > Provide a clear view of OAM functionality and its relationship > to various "planes" of networking (data plane, control plane, > management plane). In particular, the importance of > fate-sharing of OAM and user traffic flows in packet networks > should be explained. > > 6. > I see a multiplication of "plane" terms in the IETF document, and in this document in particular. > I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane. > Way too many. > Please be consistent > 7. > Table 1 summarizes the IETF OAM related RFCs discussed in this > document. > > Table 2 summarizes the OAM standards mentioned in this document. > > You need to change the Table 2 description. Do you want to say something along the lines of: > Table 2 summarizes the OAM standards specified by other Standard Development Organization > (SDO) than the IETF, along with IETF references where applicable. > > > 8. > Section 2.2.1 > For a formal definition of each term, refer to the references at the end of > this document. > Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references. > You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms, > just read first all references!" > > 9. > You specify some terms and some OAM categories, > 2.2.2 . OAM Maintenance Entities ..........................13 > 2.2.3 . OAM Maintenance Points ............................14 > 2.2.4 . Proactive and On-demand activation ................15 > 2.2.5 . Connectivity Verification and Continuity Checks ...15 > 2.2.6 . Failures ..........................................15 > ... but you don't use them in the section 3 > > Just_one_example with section 3.2.2 > - > o Demand mode: in this mode, BFD control packets are sent on-demand. > Upon need, a system initiates a series of BFD control packets to > verify the liveness of the session > Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5 > - OLD: > Each of the end-points of the monitored path maintains its own > session identification > NEW: > Each of the MEP maintains its own session identification > OR NEW (actually I don't know) > Each of the MP maintains its own session identification > - OLD > A BFD echo packet is sent to a peer system > Peer system = MEP, MP, or something else? > - etc... > > 10. > This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience". > When we did RFC 6632, which is the companion document, we hadhttp://tools.ietf.org/html/rfc6632#section-1.1 > > The target audience of the document is, on the one hand, IETF working > groups, which aim to select appropriate standard management protocols > and data models to address their needs concerning network management. > On the other hand, the document can be used as an overview and > guideline by non-IETF Standards Development Organizations (SDOs) > planning to use IETF management technologies and data models for the > realization of management applications. The document can also be > used to initiate a discussion between the bodies with the goal to > gather new requirements and to detect possible gaps. Finally, this > document is directed to all interested parties that seek to get an > overview of the current set of the IETF network management protocols > such as network administrators or newcomers to the IETF. > > You should have something similar. > > > 11. > Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense > Alternative protocols for performance measurement are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM ], [TP-LM-DM ]), and in Ethernet > OAM [ITU-T-Y1731 ]. > > > My conclusions: this document still needs some work > > Regards, Benoit > >> The IESG has received a request from the Operations and Management Area >> Working Group WG (opsawg) to consider the following document: >> - 'An Overview of Operations, Administration, and Maintenance (OAM) >> Mechanisms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be >> sent toiesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Operations, Administration, and Maintenance (OAM) is a general term >> that refers to a toolset that can be used for fault detection and >> isolation, and for performance measurement. OAM mechanisms have been >> defined for various layers in the protocol stack, and are used with a >> variety of protocols. >> >> This document presents an overview of the OAM mechanisms that have >> been defined and are currently being defined by the IETF. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> > --------------090504060000040407050407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Some more feedback, send on behalf of Al Morton.

Regards, Benoit

=================================================
Hi Benoit,
 
Here are some additional comments, just checking a few things
I know a little about.
 
Al
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 
1.1. The Building Blocks of OAM
...
   o Performance Monitoring:
      Consists of 3 main functions
 
        o Loss Measurement (LM) - monitors the packet loss rate of a
          connection.
 
        o Delay Measurement (DM) - monitors the delay and delay
          variation between MPs.
 
        o Throughput measurement - monitors the throughput of a
          connection.
 
>>> Apparently, no OAM tool currently measures Throughput,
    because no such tool is cited in the memo (and the term “throughput”
    never appears again).  my guess is that there was some reference to
    RFC 2544 that has now been removed. Remove Throughput from the list.
 
1.3 OAM Toolsets
...
   o OWAMP and TWAMP:
      The One Way Active Measurement Protocol (OWAMP) and the Two Way
      Active Measurement Protocols (TWAMP) are two protocols defined in
      the IP Performance Metrics (IPPM) working group in the IETF. These
      protocols allow delay and packet loss measurement in IP networks.
 
>>> and Delay variation, duplication, reordering, etc. (all the metrics limited tools
    completely ignore).
 
1.4 IETF OAM Documents
 
>>> Expand Table 1 as noted above, to include all the metrics they missed.
 
 
3.6.1
...
   TWAMP [TWAMP] is a similar protocol that enables measurement of
>>> both one-way and
   two-way (round trip) characteristics. 
 
>>> sentence below is simply not true, because the authors did not understand
   the one-way measurement capability:
   TWAMP does not require accurate
   time of day, and, furthermore, allows the use of a simple session
   reflector, making it an attractive alternative to OWAMP.
>>> go back and read the memo...
 
 
3.7. Summary of OAM Functions
 
   Table 3 summarizes the OAM functions that are supported in each of
   the categories that were analyzed in this section.
 
   +-----------+-------+--------+--------+-----------+-------+--------+
   | Standard  |Continu|Connecti|Path    |Defect     |Perform|Other   |
   |           |ity    |vity    |Discover|Indications|ance   |Function|
   |           |Check  |Verifica|y       |           |Monitor|s       |
   |           |       |tion    |        |           |ing    |        |
   +-----------+-------+--------+--------+-----------+-------+--------+
...
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |OWAMP and  |       |        |        |           |-Delay |        |
   |TWAMP      |  Yes  |  Yes   |        |           | measur|        |
   |           |       |        |        |           | ement |        |
   |           |       |        |        |           |-Packet|        |
   |           |       |        |        |           | loss  |        |
   |           |       |        |        |           | measur|        |
   |           |       |        |        |           | ement |        |
   +-----------+-------+--------+--------+-----------+-------+--------+
                     Table 3 Summary of OAM Functions
 
>>> Both Continuity Check and Connectivity Verification are tested and
confirmed by establishing the *WAMP Control Protocol TCP connection,
so this should be indicated the table.


draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract 
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL. 

So, as an example: does OAM include function? 
I advice to review draft-ietf-trill-oam-req-04

2. 
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
Ok, I see later on:	
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts. 
However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document. 

You need to change the Table 2 description. Do you want to say something along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard Development Organization 
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the end of
   this document.
Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories, 
   2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
         2.2.4. Proactive and On-demand activation ................ 15
         2.2.5. Connectivity Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system = MEP, MP, or something else?
- etc... 

10. 
This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/


No IPR declarations have been submitted directly on this I-D.


--------------090504060000040407050407-- From C.Donley@cablelabs.com Tue Jan 15 07:51:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F71521F88CC for ; Tue, 15 Jan 2013 07:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ4M5pt4wtUb for ; Tue, 15 Jan 2013 07:51:46 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 53D0C21F88DD for ; Tue, 15 Jan 2013 07:51:46 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r0FFph2Y008117 for ; Tue, 15 Jan 2013 08:51:43 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 15 Jan 2013 08:51:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0298.004; Tue, 15 Jan 2013 08:51:44 -0700 From: Chris Donley To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-donley-behave-deterministic-cgn-05.txt Thread-Index: AQHN8zg2pVTMh+IW7kOX/deyhOryMg== Date: Tue, 15 Jan 2013 15:51:42 +0000 Message-ID: In-Reply-To: <20130112153652.18279.20416.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1B286E8D7E2F5146A5FE18B24E3C0371@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [OPSAWG] FW: New Version Notification for draft-donley-behave-deterministic-cgn-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:51:49 -0000 Dear Opsawg, We have posted an updated version of our Deterministic CGN draft, which describes a way to significantly reduce or eliminate CGN logging while providing traceability for abuse response. We'd appreciate your feedback. We'd also like to request adoption as a WG item. Thanks, Chris --=20 Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) On 1/12/13 8:36 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-donley-behave-deterministic-cgn-05.txt >has been successfully submitted by Chris Donley and posted to the >IETF repository. > >Filename: draft-donley-behave-deterministic-cgn >Revision: 05 >Title: Deterministic Address Mapping to Reduce Logging in Carrier Grade >NAT Deployments >Creation date: 2013-01-12 >WG ID: Individual Submission >Number of pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic-cgn- >05.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn >Htmlized: =20 >http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-donley-behave-deterministic-cgn-0= 5 > >Abstract: > In some instances, Service Providers have a legal logging requirement > to be able to map a subscriber's inside address with the address used > on the public Internet (e.g. for abuse response). Unfortunately, > many Carrier Grade NAT logging solutions require active logging of > dynamic translations. Carrier Grade NAT port assignments are often > per-connection, but could optionally use port ranges. Research > indicates that per-connection logging is not scalable in many > residential broadband services. This document suggests a way to > manage Carrier Grade NAT translations in such a way as to > significantly reduce the amount of logging required while providing > traceability for abuse response. While the authors acknowledge that > IPv6 is a preferred solution, Carrier Grade NAT is a reality in many > networks, and is needed in situations where either customer equipment > or Internet content only supports IPv4; this approach should in no > way slow the deployment of IPv6. > > > =20 > =20 > > >The IETF Secretariat > From lucy.yong@huawei.com Tue Jan 15 09:46:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1463B21F876E for ; Tue, 15 Jan 2013 09:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1ybMftap7Nq for ; Tue, 15 Jan 2013 09:46:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B81B121F86E3 for ; Tue, 15 Jan 2013 09:46:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANO48003; Tue, 15 Jan 2013 17:46:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 17:46:47 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 17:46:55 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 09:46:52 -0800 From: Lucy yong To: Brian E Carpenter Thread-Topic: I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: AQHN8OOGoNx0rEEcvEGwd3lyK+WVX5hJHNOggAF1woCAABmpgA== Date: Tue, 15 Jan 2013 17:46:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448765DE@dfweml505-mbx> References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <2691CE0099834E4A9C5044EEC662BB9D4486FD3B@dfweml505-mbb.china.huawei.com> <50F50DDB.4020603@gmail.com> In-Reply-To: <50F50DDB.4020603@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BZ34 BoB+ DVTt E8t8 FLor IFKy Nhxv Qo+e S7AY TCuf UFEJ V2Fl Yk+F Zcmc crAH h54a; 3; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBkAHIAYQBmAHQALQBrAHIAaQBzAGgAbgBhAG4ALQBvAHAAcwBhAHcAZwAtAGwAYQByAGcAZQAtAGYAbABvAHcALQBsAG8AYQBkAC0AYgBhAGwAYQBuAGMAaQBuAGcAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwBvAHAAcwBhAHcAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D7B70410-E1C0-4DFE-8476-CC621AF7B635}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue, 15 Jan 2013 17:46:47 GMT; UgBFADoAIABJAC0ARAAgAEEAYwB0AGkAbwBuADoAIABkAHIAYQBmAHQALQBrAHIAaQBzAGgAbgBhAG4ALQBvAHAAcwBhAHcAZwAtAGwAYQByAGcAZQAtAGYAbABvAHcALQBsAG8AYQBkAC0AYgBhAGwAYQBuAGMAaQBuAGcALQAwADIALgB0AHgAdAA= x-cr-puzzleid: {D7B70410-E1C0-4DFE-8476-CC621AF7B635} x-originating-ip: [10.47.88.216] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:46:59 -0000 QnJpYW4sDQoNCkkgbWVhbiB0byBzYXkgdGhhdCB3ZSBhcmUgbm90IGRpc2N1c3NpbmcgdGhlIHNh bWUgdGhpbmcuIEl0IHNlZW1zIHRoYXQgeW91IGNhcHR1cmUgbXkgZXJyb3IgYW5kIHJlc3BvbnNl IHByb3Blcmx5LiBXZSB3aWxsIG1ha2UgYmV0dGVyIGV4cGxhbmF0aW9uIGluIG5leHQgdmVyc2lv bi4gDQoNClRoZSBmdW5kYW1lbnRhbCBtb2RlbCBmb3IgdGhlIGxvYWQgYmFsYW5jZSBpcyB0byBo YXNoIG9uIHNvbWUgZmllbGRzIGluIHRoZSBwYWNrZXRzLiBIYXNoaW5nIG1lY2hhbmlzbSBlbnN1 cmVzIHRoZSBhcHBsaWNhdGlvbiBvciBjbGllbnQgZmxvd3MgdHJhdmVyc2luZyBvbiB0aGUgc2Ft ZSBwYXRoIGFuZCBhIG5vZGUgZG9lcyBub3QgbmVlZCB0byB0cmFjayB0aGUgbWFwcGluZyBiZXR3 ZWVuIGZsb3cgYW5kIHBhdGgsIGkuZS4gZmxvdyBzdGF0ZWxlc3MuIA0KDQpUaGFua3MsDQpMdWN5 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMTUsIDIwMTMgMjowNiBBTQ0KPiBUbzogTHVjeSB5b25nDQo+IENjOiBkcmFmdC1r cmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9yZzsN Cj4gb3BzYXdnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1rcmlz aG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLQ0KPiBiYWxhbmNpbmctMDIudHh0DQo+IA0KPiBP biAxNC8wMS8yMDEzIDE4OjAwLCBMdWN5IHlvbmcgd3JvdGU6DQo+ID4gSGkgQnJpYW4sDQo+ID4N Cj4gPiBJIHRoaW5rIHdlIGFyZSBub3QgZGlzY3Vzc2luZyBkaWZmZXJlbnQgdGhpbmdzLiBQbGVh c2Ugc2VlIGlubGluZS4NCj4gDQo+IEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgZHJh ZnQgZG9lc24ndCBleHBsYWluIHRoZSBmdW5kYW1lbnRhbA0KPiBtb2RlbCB2ZXJ5IHdlbGwuIEkg ZnVsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzIGJlbG93IChhbmQgdGhlc2UNCj4gYXNwZWN0 cyBhcmUgZGlzY3Vzc2VkIGluIFJGQyA2NDM4KS4NCj4gDQo+ICAgIEJyaWFuDQo+IA0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBTYXR1 cmRheSwgSmFudWFyeSAxMiwgMjAxMyAxMDo0MCBBTQ0KPiA+PiBUbzogZHJhZnQta3Jpc2huYW4t b3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gQ2M6 IG9wc2F3Z0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQta3Jp c2huYW4tb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC0NCj4gPj4gYmFsYW5jaW5nLTAyLnR4dA0KPiA+ Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gTXkgY29tbWVudHMgYXJlIG9uIHRoZSBkaXNjdXNzaW9u IG9mIGZsb3cgSURzIGFuZCBoYXNoaW5nLiBJJ20gbm90DQo+ID4+IGNvbW1lbnRpbmcgYXQgYWxs IG9uIHRoZSBvdmVyYWxsIHByb3Bvc2FsLCBiZWNhdXNlIEkgY2FuJ3QganVkZ2UNCj4gPj4gd2hl dGhlciB0aGUgcHJvYmxlbSBpcyByZWFsIG9yIHRoZSBzb2x1dGlvbiBpcyBwcmFjdGljYWwuDQo+ ID4+DQo+ID4+PiBBIGxhcmdlIHNwYWNlIG9mIHRoZSBmbG93IGlkZW50aWZpY2F0aW9ucywgaS5l LiBmaW5lcg0KPiA+Pj4gZ3JhbnVsYXJpdHkgb2YgdGhlIGZsb3dzLCBjb25kdWN0cyBtb3JlIHJh bmRvbSBpbiBzcHJlYWRpbmcgdGhlDQo+IGZsb3dzDQo+ID4+PiBvdmVyIGEgc2V0IG9mIGNvbXBv bmVudCBsaW5rcy4NCj4gPj4gVGhhdCBpc24ndCBhY2N1cmF0ZS4gVGhlIHJlcXVpcmVtZW50IGlz IGFuIElEIHNwYWNlIGluIHdoaWNoIHRoZSBJRHMNCj4gPj4gYmVsb25nIHRvIGEgdW5pZm9ybSBk aXN0cmlidXRpb24uIFRlY2huaWNhbGx5IHNwZWFraW5nLCBpZiB5b3UgaGF2ZQ0KPiB0d28NCj4g Pj4gbGlua3MsIGEgb25lLWJpdCBmbG93IElEIGlzIHN1ZmZpY2llbnQsIGFzIGxvbmcgYXMgdGhl IHZhbHVlcyAwIGFuZA0KPiAxDQo+ID4+IGFyZQ0KPiA+PiBlcXVhbGx5IGxpa2VseSB0byBhcHBl YXIuDQo+ID4gW0x1Y3ldIFRoaXMgaXMgbm90IHJlcXVpcmVtZW50IGZvciB0aGUgSUQgc3BhY2Uu IEl0IGlzIHRvIHNheSB0aGF0DQo+IHVzaW5nIDUgdHVwbGUgb3IgMyB0dXBsZSB0byBkZWZpbmUg YSBmbG93IHJlc3VsdHMgYSB2ZXJ5IGxhcmdlIGZsb3cgSUQNCj4gc3BhY2UuIFRoaXMgZmxvdyBk ZWZpbml0aW9uIGlzIHR5cGljYWxseSB1c2VkIGluIGhhc2hpbmcgYmFzZWQgbG9hZA0KPiBiYWxh bmNlIHRvZGF5LiBUaGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggaG93IG1hbnkgbGlua3MuIFdl IHdpbGwNCj4gcmVmaW5lIHRoZSB0ZXh0IHRvIG1ha2UgaXQgY2xlYXIuDQo+ID4NCj4gPj4gVGhl cmVmb3JlLCB0aGUgcHJhY3RpY2FsIGlzc3VlIGlzIG5vdCB0aGUgc2l6ZSBvZiB0aGUgSUQgc3Bh Y2UgYnV0DQo+IHRoZQ0KPiA+PiBxdWFsaXR5IG9mIHRoZSBoYXNoIGZ1bmN0aW9uIHVzZWQgdG8g Z2VuZXJhdGUgdGhlIElEIG9mIGVhY2ggZmxvdy4NCj4gPj4gSG93ZXZlciwgd2hhdGV2ZXIgdGhl IGluaXRpYWwgSUQgc3BhY2UsIHRoZSBmaW5hbCBoYXNoIGhhcyB0byBiZQ0KPiBkb3duDQo+ID4+ IHRvIDAuLk4gaWYgeW91IGhhdmUgTisxIGFsdGVybmF0aXZlIHBhdGhzLg0KPiA+IFtMdWN5XSBU aGUgZHJhZnQgZG9lcyBub3QgYWRkcmVzcyB1c2luZyBoYXNoaW5nIHRvIGdlbmVyYXRlIHRoZSBm bG93DQo+IElEIGF0IGFsbC4gV2UgYXJlIGFjcm9zcyBlYWNoIG90aGVyIGhlcmUuIFlvdSBtYXkg cmVmZXIgc29tZSBkaWZmZXJlbnQNCj4gYXBwbGljYXRpb25zLg0KPiA+DQo+ID4gUmVnYXJkcywN Cj4gPiBMdWN5DQo+ID4+IEkgdGhpbmsgdGhlIHJlYXNvbiB0aGF0IHlvdXIgbW9kZWwgbmVlZHMg YSBsYXJnZXIgSUQgc3BhY2UgaXMgdG8NCj4gPj4gcmVkdWNlIHRoZSBwcm9iYWJpbGl0eSBvZiB0 d28gZmxvd3MgY29sbGlkaW5nIGJ5IGNoYW5jZSBpbiB0aGUgSUQNCj4gc3BhY2UuDQo+ID4+IFRo YXQgd291bGQgZGVmZWF0IHlvdXIgd2lzaCB0byBzZXBhcmF0ZSBvdXQgbGFyZ2UgZmxvd3MuDQo+ ID4+DQo+ID4+PiBUaGUgYWR2YW50YWdlcyBvZiBoYXNoaW5nIGJhc2VkIGxvYWQNCj4gPj4+IGRp c3RyaWJ1dGlvbiBhcmUgdGhlIHByZXNlcnZhdGlvbiBvZiB0aGUgcGFja2V0IHNlcXVlbmNlIGlu IGEgZmxvdw0KPiA+Pj4gYW5kIHRoZSByZWFsIHRpbWUgZGlzdHJpYnV0aW9uIHdpdGggdGhlIHN0 YXRlbGVzcyBvZiBpbmRpdmlkdWFsDQo+ID4+PiBmbG93cy4gSWYgdGhlIHRyYWZmaWMgZmxvd3Mg cmFuZG9tbHkgc3ByZWFkIGluIHRoZSBmbG93DQo+ID4+PiBpZGVudGlmaWNhdGlvbiBzcGFjZSwg dGhlIGZsb3cgcmF0ZXMgYXJlIG11Y2ggc21hbGxlciBjb21wYXJlZCB0bw0KPiB0aGUNCj4gPj4+ IGxpbmsgY2FwYWNpdHksDQo+ID4+IFRoYXQgc291bmRzIGxpa2UgbWFnaWMuIEkgZG9uJ3QgdGhp bmsgeW91IG1lYW4gdGhhdCBhdCBhbGwuDQo+ID4+DQo+ID4+PiBhbmQgdGhlIHJhdGUgZGlmZmVy ZW5jZXMgYXJlIG5vdCBkcmFtYXRpYywNCj4gPj4gRG8geW91IG1lYW4gdGhhdCB0aGUgdG90YWwg dHJhZmZpYyByYXRlIGlzIG1vcmUgZmFpcmx5IGRpc3RyaWJ1dGVkDQo+ID4+IGFjcm9zcyB0aGUg bGlua3M/IEluIGFueSBjYXNlLCAiZHJhbWF0aWMiIGlzbid0IGFuIGVuZ2luZWVyaW5nIHRlcm0u DQo+ID4+DQo+ID4+PiB0aGUgaGFzaGluZw0KPiA+Pj4gYWxnb3JpdGhtIHdvcmtzIHZlcnkgd2Vs bCBpbiBnZW5lcmFsLg0KPiA+PiBIb3cgY2FuIHlvdSBzYXkgdGhhdCB3aXRob3V0IHNwZWNpZnlp bmcgYSBwYXJ0aWN1bGFyIGFsZ29yaXRobT8gQWxzbywNCj4gPj4gInZlcnkgd2VsbCBpbiBnZW5l cmFsIiBpc24ndCBhbiBlbmdpbmVlcmluZyB0ZXJtIGVpdGhlci4NCj4gPj4NCj4gPj4+IFRoZXJl IG1heSBiZSBzb21lIGZhbHNlIHBvc2l0aXZlcyBkdWUgdG8gbXVsdGlwbGUgb3RoZXIgZmxvd3MN Cj4gPj4+IG1hc3F1ZXJhZGluZyBhcyBhIGxhcmdlIGZsb3c7IHRoZSBhbW91bnQgb2YgZmFsc2Ug cG9zaXRpdmVzIGlzDQo+ID4+PiByZWR1Y2VkIGJ5IHBhcmFsbGVsIGhhc2hpbmcgdXNpbmcgZGlm ZmVyZW50IGhhc2ggZnVuY3Rpb25zDQo+ID4+IFRvIGdpdmUgeW91IHNvbWUgZGF0YSwgd2l0aCBh IDIwIGJpdCBJRCBzcGFjZSwgdGhlIEZOVjFhLTMyIGhhc2gNCj4gPj4gYWxnb3JpdGhtIGdpdmVz IGF0IG1vc3QgNSUgY29sbGlzaW9ucywgYmFzZWQgb24gSVB2NiBoZWFkZXJzIGluIHJlYWwNCj4g Pj4gcGFja2V0IHRyYWNlcy4NCj4gPj4gW2h0dHBzOi8vcmVzZWFyY2hzcGFjZS5hdWNrbGFuZC5h Yy5uei9oYW5kbGUvMjI5Mi8xMzI0MF0NCj4gPj4NCj4gPj4gSSB3b25kZXIgd2hldGhlciB0aGUg b3ZlcmhlYWQgb2YgcnVubmluZyBzZXZlcmFsIGhhc2hlcyBpbiBwYXJhbGxlbA0KPiA+PiBpcyBq dXN0aWZpZWQgYnkgdGhpcyBjb2xsaXNpb24gcmF0ZT8NCj4gPj4NCj4gPj4gUmVnYXJkcw0KPiA+ PiAgICBCcmlhbiBDYXJwZW50ZXINCj4gPg0K From ramk@Brocade.com Tue Jan 15 10:21:31 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FEC11E80A6 for ; Tue, 15 Jan 2013 10:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep-myx2dBDBJ for ; Tue, 15 Jan 2013 10:21:29 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE3A21F86C3 for ; Tue, 15 Jan 2013 10:21:28 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r0FILBDB010843; Tue, 15 Jan 2013 10:21:16 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 19wc5tr03x-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 10:21:16 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 10:21:05 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 15 Jan 2013 10:17:51 -0800 From: ramki Krishnan To: Brian E Carpenter Date: Tue, 15 Jan 2013 10:17:43 -0800 Thread-Topic: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: Ac3y+BfS1ZRfI6mxREG+xGRMeEUd+QASh0Tg Message-ID: References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> In-Reply-To: <50F50F7A.1070001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1E214HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_05:2013-01-15, 2013-01-15, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301150152 Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:21:31 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1E214HQ1EXCH01corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCg0KDQpBIHBvdGVudGlhbCBsb25nLWxpdmVkIGxhcmdlIGZsb3cgaXMgZGVj bGFyZWQgaWYgaXQgZXhjZWVkcyBhIHByZS1wcm9ncmFtbWVkIHRocmVzaG9sZCBpbiAqYWxsIHRo ZSBtYXRjaGluZyBoYXNoIHRhYmxlIGVudHJpZXMqLg0KDQoNCg0KVGhyb3VnaCB0aGUgdXNlIG9m IG11bHRpcGxlIGhhc2hlcywgdGhlIGJlbmVmaXQgb2YgYXZvaWRpbmcgZmFsc2UgcG9zaXRpdmVz IGlzIGEgbXVjaCBtb3JlIHRoYW4gYSBzbWFsbCBmcmFjdGlvbiwgc2VlIGFuIGFwcHJveGltYXRl IHNhbXBsZSBwcm9iYWJpbGlzdGljIGNhbGN1bGF0aW9uIGJlbG93Lg0KDQoNCg0KTGV0IHVzIGFz c3VtZSB0aGUgbnVtYmVyIG9mIGhhc2ggc3RhZ2VzIGlzIG0gKDQpLiBMZXQgdXMgYXNzdW1lIHRo ZSBwcm9iYWJpbGl0eSBvZiBhIHNob3J0LWxpdmVkIGZsb3cgbWF0Y2hpbmcgYSBzaW5nbGUgaGFz aCB0YWJsZSBlbnRyeSBpcyAuMjUuIEZvciBhIHNob3J0LWxpdmVkIGZsb3cgdG8gYmUgZGVjbGFy ZWQgYSBsb25nLWxpdmVkIGxhcmdlIGZsb3csIGl0IG5lZWRzIHRvIG1hdGNoIHRoZSBzYW1lIGhh c2ggdGFibGUgZW50cmllcyBhcyB0aGUgbG9uZy1saXZlZCBsYXJnZSBmbG93LiBUaGUgYXBwcm94 aW1hdGUgcHJvYmFiaWxpdHkgb2YgdGhpcyBldmVudCBpcyAoLjI1KV5tID0gKC4yNSleNCA9IC4w MDMNCg0KDQoNClRoYW5rcywNCg0KcmFta2kNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTUsIDIwMTMgMTI6MTMgQU0NClRvOiBy YW1raSBLcmlzaG5hbg0KQ2M6IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQt YmFsYW5jaW5nQHRvb2xzLmlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb T1BTQVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2Fk LWJhbGFuY2luZy0wMi50eHQNCg0KDQoNClJhbSwNCg0KDQoNCkkgdW5kZXJzdGFuZCBldmVyeXRo aW5nIHlvdSBzYXkgYmVsb3cuIEJ1dCB5b3UgYXJlbid0IGNvbW1lbnRpbmcgb24gbXkgbWFpbiBw b2ludDogd2h5IGlzIGl0IHdvcnRoIHRoZSAqZXh0cmEqIGNvc3Qgb2YgcnVubmluZyBzZXZlcmFs IGhhc2hlcyBpbiBwYXJhbGxlbCB0byBleGNsdWRlIGEgKnNtYWxsKiBmcmFjdGlvbiBvZiBtaXMt aWRlbnRpZmllZCBsYXJnZSBmbG93cz8NCg0KVG8gbWUsIHRoYXQgaXMgbm90IGEgdXNlZnVsIGVu Z2luZWVyaW5nIHRyYWRlLW9mZi4NCg0KDQoNClJlZ2FyZHMNCg0KICAgQnJpYW4NCg0KDQoNCk9u IDE0LzAxLzIwMTMgMTc6NDgsIHJhbWtpIEtyaXNobmFuIHdyb3RlOg0KDQo+IEhpIEJyaWFuLA0K DQo+DQoNCj4NCg0KPg0KDQo+Pj4gSSB0aGluayBkaWRuJ3QgZXhwbGFpbiBteSBwb2ludCBzdWZm aWNpZW50bHkuIEkgdW5kZXJzdGFuZCB3aHkgeW91IHN1Z2dlc3QgdXNpbmcgc2V2ZXJhbCBoYXNo ZXMuIEJ1dCB0aGlzIGlzIHN0YXRpc3RpY2FsIGxvYWQgYmFsYW5jaW5nIHdlIGFyZSB0YWxraW5n ID4+YWJvdXQuIElmIGEgZmV3ICUgb2YgdGhlIHRpbWUsIHlvdSBtaXN0YWtlbmx5IHRyZWF0IHNl dmVyYWwgbWVkaXVtIGZsb3dzIGFzIG9uZSBsYXJnZSBmbG93LCBhbmQgdGhlcmVmb3JlIHJlYmFs YW5jZSB0aGVtIGFzIGEgc2luZ2xlIHVuaXQsIHNvIHdoYXQ/ID4+WW91IHdpbGwgc3RpbGwgYmFs YW5jZSB0aGUgdHJhZmZpYyByZWFzb25hYmx5IHdlbGwuDQoNCj4NCg0KPg0KDQo+DQoNCj4gRWFj aCBvZiB0aGUgZmxvd3MgaXMgZXZlbnR1YWxseSBsZWFybnQvcHJvZ3JhbW1lZCBpbiBhIGZsb3cg dGFibGUNCg0KPiAoaGFyZHdhcmUgdGFibGUgcmVzb3VyY2Ugd2hlcmUgdGhlIGZsb3cgaXMgZmlu YWxseSBjb21taXR0ZWQpOyB0aGVyZQ0KDQo+IGlzIG5ldmVyIGEgY2FzZSBvZiBidW5kbGluZyBt dWx0aXBsZSBmbG93cy4gTW9yZSBkZXRhaWxzIGJlbG93DQoNCj4NCg0KPg0KDQo+DQoNCj4gMSkg ICAgU2NhbGFibGUgZGV0ZWN0aW9uIG9mIGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3MNCg0KPg0KDQo+ IGEuICAgIFRoZSBnb2FsIGlzIHRvIGtlZXAgdGhlIHNpemUgb2YgdGhlIGZsb3cgdGFibGUgKGhh cmR3YXJlIHRhYmxlIHJlc291cmNlIHdoZXJlIHRoZSBsb25nLWxpdmVkIGxhcmdlIGZsb3cgaXMg ZmluYWxseSBjb21taXR0ZWQpIGJvdW5kZWQgYW5kIHRoZSBwcm9jZXNzaW5nIHJlcXVpcmVtZW50 cyAoQ1BVIHV0aWxpemF0aW9uKSBmb3IgZmxvdyBsZWFybmluZyBib3VuZGVkLg0KDQo+DQoNCj4g Yi4gICAgRm9yIHNhdGlzZnlpbmcgdGhlIGFib3ZlIGdvYWwsIHNldmVyYWwgaGFzaGVzIGhlbHBz Lg0KDQo+DQoNCj4NCg0KPg0KDQo+IDIpICAgIFNjYWxhYmxlIGxvYWQtYmFsYW5jaW5nIG9mIGxv bmctbGl2ZWQgbGFyZ2UgZmxvd3MNCg0KPg0KDQo+IGEuICAgIFRoZSBnb2FsIGlzIHRvIGhhdmUg YSBzY2FsYWJsZSBsb2FkIGJhbGFuY2luZyBzb2x1dGlvbiB3aGljaCBwcm9kdWNlcyBtZWFuaW5n ZnVsIHJlc3VsdHMgd2hpbGUga2VlcGluZyB0aGUgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMgKENQ VSB1dGlsaXphdGlvbikgZm9yIGxvYWQtYmFsYW5jaW5nIGJvdW5kZWQuDQoNCj4NCg0KPiBiLiAg ICBGb3Igc2F0aXNmeWluZyB0aGUgYWJvdmUgZ29hbCwgaXQgaXMgbm90IHdvcnRod2hpbGUgdG8g bG9hZC1iYWxhbmNlIG1lZGl1bS9zbWFsbCBmbG93cy4NCg0KPg0KDQo+DQoNCj4NCg0KPiBUaGFu a3MsDQoNCj4NCg0KPiByYW0NCg0KPg0KDQo+DQoNCj4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tXQ0KDQo+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAxMywgMjAxMyAxMjow NiBBTQ0KDQo+IFRvOiByYW1raSBLcmlzaG5hbg0KDQo+IENjOiBkcmFmdC1rcmlzaG5hbi1vcHNh d2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt a3Jpc2huYW4tb3BzYXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmc+ Ow0KDQo+IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0KDQo+IFN1Ympl Y3Q6IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9uOg0KDQo+IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1s YXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAyLnR4dA0KDQo+DQoNCj4NCg0KPg0KDQo+IFJhbSwN Cg0KPg0KDQo+DQoNCj4NCg0KPiBPbiAxMy8wMS8yMDEzIDA1OjE0LCByYW1raSBLcmlzaG5hbiB3 cm90ZToNCg0KPg0KDQo+PiBIaSBCcmlhbiwNCg0KPg0KDQo+DQoNCj4+IFRoYW5rcyBhIGxvdCBm b3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgYW5zd2VycyB0byBzb21lIG9mIHlvdXIgY29t bWVudHMuIFdlIHdpbGwgcmVzcG9uZCB0byB5b3VyIG90aGVyIGNvbW1lbnRzIHNob3J0bHkuDQoN Cj4NCg0KPg0KDQo+Pj4gVGhlcmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBt dWx0aXBsZSBvdGhlciBmbG93cw0KDQo+DQoNCj4+PiBtYXNxdWVyYWRpbmcgYXMgYSBsYXJnZSBm bG93OyB0aGUgYW1vdW50IG9mIGZhbHNlIHBvc2l0aXZlcyBpcw0KDQo+DQoNCj4+PiByZWR1Y2Vk IGJ5IHBhcmFsbGVsIGhhc2hpbmcgdXNpbmcgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb25zDQoNCj4N Cg0KPg0KDQo+PiBCcmlhbjoNCg0KPg0KDQo+DQoNCj4+PiBUbyBnaXZlIHlvdSBzb21lIGRhdGEs IHdpdGggYSAyMCBiaXQgSUQgc3BhY2UsIHRoZSBGTlYxYS0zMiBoYXNoIGFsZ29yaXRobSBnaXZl cyBhdCBtb3N0IDUlIGNvbGxpc2lvbnMsIGJhc2VkIG9uIElQdjYgaGVhZGVycyBpbiByZWFsIHBh Y2tldCB0cmFjZXMuICBbaHR0cHM6Ly9yZXNlYXJjaHNwYWNlLmF1Y2tsYW5kLmFjLm56L2hhbmRs ZS8yMjkyLzEzMjQwXS4gSSB3b25kZXIgd2hldGhlciB0aGUgb3ZlcmhlYWQgb2YgcnVubmluZyBz ZXZlcmFsIGhhc2hlcyBpbiBwYXJhbGxlbCBpcyBqdXN0aWZpZWQgYnkgdGhpcyBjb2xsaXNpb24g cmF0ZT8NCg0KPg0KDQo+DQoNCj4+IFJhbToNCg0KPg0KDQo+DQoNCj4+IFRoZSBuZWVkIGZvciBt dWx0aXBsZSBoYXNoZXMgaXMgc3BlY2lmaWMgdG8gdGhlIHN1Z2dlc3RlZCBhbGdvcml0aG0gb24g YXV0b21hdGljIGhhcmR3YXJlIGlkZW50aWZpY2F0aW9uIC0gdGhpcyBhbGdvcml0aG0gaXMgc2lt aWxhciB0byBhIGJsb29tIGZpbHRlciB3aGljaCB1c2VzIG11bHRpcGxlIGhhc2ggZnVuY3Rpb25z Lg0KDQo+DQoNCj4NCg0KPg0KDQo+IEkgdGhpbmsgZGlkbid0IGV4cGxhaW4gbXkgcG9pbnQgc3Vm ZmljaWVudGx5LiBJIHVuZGVyc3RhbmQgd2h5IHlvdSBzdWdnZXN0IHVzaW5nIHNldmVyYWwgaGFz aGVzLiBCdXQgdGhpcyBpcyBzdGF0aXN0aWNhbCBsb2FkIGJhbGFuY2luZyB3ZSBhcmUgdGFsa2lu ZyBhYm91dC4gSWYgYSBmZXcgJSBvZiB0aGUgdGltZSwgeW91IG1pc3Rha2VubHkgdHJlYXQgc2V2 ZXJhbCBtZWRpdW0gZmxvd3MgYXMgb25lIGxhcmdlIGZsb3csIGFuZCB0aGVyZWZvcmUgcmViYWxh bmNlIHRoZW0gYXMgYSBzaW5nbGUgdW5pdCwgc28gd2hhdD8gWW91IHdpbGwgc3RpbGwgYmFsYW5j ZSB0aGUgdHJhZmZpYyByZWFzb25hYmx5IHdlbGwuDQoNCj4NCg0KPg0KDQo+DQoNCj4gICAgIEJy aWFuDQoNCj4NCg0KPg0KDQo+DQoNCj4+ICJPbiBwYWNrZXQgYXJyaXZhbCwgYSBuZXcgZmxvdyBp cyBsb29rZWQgdXAgaW4gcGFyYWxsZWwgaW4gYWxsIHRoZSBoYXNoIHRhYmxlcyBhbmQgdGhlIGNv cnJlc3BvbmRpbmcgY291bnRlciBpcyBpbmNyZW1lbnRlZC4gSWYgdGhlIGNvdW50ZXIgZXhjZWVk cyBhIHByb2dyYW1tZWQgdGhyZXNob2xkIGluIGEgZ2l2ZW4gdGltZSBpbnRlcnZhbCBpbiBhbGwg dGhlIGhhc2ggdGFibGUgZW50cmllcywgYSBjYW5kaWRhdGUgbGFyZ2UgZmxvdyBpcyBsZWFybnQg YW5kIHByb2dyYW1tZWQgaW4gYSBoYXJkd2FyZSB0YWJsZSByZXNvdXJjZSBsaWtlIFRDQU0uDQoN Cj4NCg0KPg0KDQo+DQoNCj4+IEZvciBhIHNob3J0LWxpdmVkIGZsb3cgdG8gbWFzcXVlcmFkZSBh cyBhIGxvbmctbGl2ZWQgbGl2ZWQgZmxvdywgaXQgbmVlZHMgdG8gbWF0Y2ggYWxsIHRoZSBoYXNo IHRhYmxlIGVudHJpZXMgd2hpY2ggaXMgYSBqb2ludCBwcm9iYWJpbGl0eSBldmVudCAtIHRodXMs IHRoZSBhbW91bnQgb2YgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBzaG9ydC1saXZlZCBmbG93cyBp cyByZWR1Y2VkLg0KDQo+DQoNCj4NCg0KPg0KDQo+PiBUaGFua3MsDQoNCj4NCg0KPg0KDQo+PiBy YW0NCg0KPg0KDQo+DQoNCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4NCg0KPj4g RnJvbTogb3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyUzY21haWx0bzpvcHNhd2ctYm91bmNl c0BpZXRmLm9yZz4+DQoNCj4+IFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQoN Cj4NCg0KPj4gQmVoYWxmIE9mIEJyaWFuIEUgQ2FycGVudGVyDQoNCj4NCg0KPj4gU2VudDogU2F0 dXJkYXksIEphbnVhcnkgMTIsIDIwMTMgODo0MCBBTQ0KDQo+DQoNCj4+IFRvOg0KDQo+PiBkcmFm dC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9y ZzxtYWlsdG88bWFpbHRvOmRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFs YW5jaW5nQHRvb2xzLmlldGYub3JnJTNjbWFpbHRvPg0KDQo+PiA6ZHJhZnQta3Jpc2huYW4tb3Bz YXdnLWxhcmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmc+DQoNCj4NCg0KPj4g Q2M6IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmclM2NtYWlsdG86b3BzYXdnQGlldGYub3JnPj4NCg0KPg0KDQo+PiBTdWJqZWN0OiBS ZTogW09QU0FXR10gSS1EIEFjdGlvbjoNCg0KPg0KDQo+PiBkcmFmdC1rcmlzaG5hbi1vcHNhd2ct bGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZy0wMi50eHQNCg0KPg0KDQo+DQoNCj4+IEhpLA0KDQo+ DQoNCj4NCg0KPj4gTXkgY29tbWVudHMgYXJlIG9uIHRoZSBkaXNjdXNzaW9uIG9mIGZsb3cgSURz IGFuZCBoYXNoaW5nLiBJJ20gbm90IGNvbW1lbnRpbmcgYXQgYWxsIG9uIHRoZSBvdmVyYWxsIHBy b3Bvc2FsLCBiZWNhdXNlIEkgY2FuJ3QganVkZ2Ugd2hldGhlciB0aGUgcHJvYmxlbSBpcyByZWFs IG9yIHRoZSBzb2x1dGlvbiBpcyBwcmFjdGljYWwuDQoNCj4NCg0KPg0KDQo+Pj4gQSBsYXJnZSBz cGFjZSBvZiB0aGUgZmxvdyBpZGVudGlmaWNhdGlvbnMsIGkuZS4gZmluZXINCg0KPg0KDQo+DQoN Cj4+PiBncmFudWxhcml0eSBvZiB0aGUgZmxvd3MsIGNvbmR1Y3RzIG1vcmUgcmFuZG9tIGluIHNw cmVhZGluZyB0aGUNCg0KPj4+IGZsb3dzDQoNCj4NCg0KPj4+IG92ZXIgYSBzZXQgb2YgY29tcG9u ZW50IGxpbmtzLg0KDQo+DQoNCj4NCg0KPj4gVGhhdCBpc24ndCBhY2N1cmF0ZS4gVGhlIHJlcXVp cmVtZW50IGlzIGFuIElEIHNwYWNlIGluIHdoaWNoIHRoZSBJRHMgYmVsb25nIHRvIGEgdW5pZm9y bSBkaXN0cmlidXRpb24uIFRlY2huaWNhbGx5IHNwZWFraW5nLCBpZiB5b3UgaGF2ZSB0d28gbGlu a3MsIGEgb25lLWJpdCBmbG93IElEIGlzIHN1ZmZpY2llbnQsIGFzIGxvbmcgYXMgdGhlIHZhbHVl cyAwIGFuZCAxIGFyZSBlcXVhbGx5IGxpa2VseSB0byBhcHBlYXIuDQoNCj4NCg0KPj4gVGhlcmVm b3JlLCB0aGUgcHJhY3RpY2FsIGlzc3VlIGlzIG5vdCB0aGUgc2l6ZSBvZiB0aGUgSUQgc3BhY2Ug YnV0IHRoZSBxdWFsaXR5IG9mIHRoZSBoYXNoIGZ1bmN0aW9uIHVzZWQgdG8gZ2VuZXJhdGUgdGhl IElEIG9mIGVhY2ggZmxvdy4NCg0KPg0KDQo+PiBIb3dldmVyLCB3aGF0ZXZlciB0aGUgaW5pdGlh bCBJRCBzcGFjZSwgdGhlIGZpbmFsIGhhc2ggaGFzIHRvIGJlIGRvd24gdG8gMC4uTiBpZiB5b3Ug aGF2ZSBOKzEgYWx0ZXJuYXRpdmUgcGF0aHMuDQoNCj4NCg0KPj4gSSB0aGluayB0aGUgcmVhc29u IHRoYXQgeW91ciBtb2RlbCBuZWVkcyBhIGxhcmdlciBJRCBzcGFjZSBpcyB0byByZWR1Y2UgdGhl IHByb2JhYmlsaXR5IG9mIHR3byBmbG93cyBjb2xsaWRpbmcgYnkgY2hhbmNlIGluIHRoZSBJRCBz cGFjZS4NCg0KPg0KDQo+PiBUaGF0IHdvdWxkIGRlZmVhdCB5b3VyIHdpc2ggdG8gc2VwYXJhdGUg b3V0IGxhcmdlIGZsb3dzLg0KDQo+DQoNCj4NCg0KPj4+IFRoZSBhZHZhbnRhZ2VzIG9mIGhhc2hp bmcgYmFzZWQgbG9hZA0KDQo+DQoNCj4+PiBkaXN0cmlidXRpb24gYXJlIHRoZSBwcmVzZXJ2YXRp b24gb2YgdGhlIHBhY2tldCBzZXF1ZW5jZSBpbiBhIGZsb3cNCg0KPg0KDQo+Pj4gYW5kIHRoZSBy ZWFsIHRpbWUgZGlzdHJpYnV0aW9uIHdpdGggdGhlIHN0YXRlbGVzcyBvZiBpbmRpdmlkdWFsDQoN Cj4NCg0KPj4+IGZsb3dzLiBJZiB0aGUgdHJhZmZpYyBmbG93cyByYW5kb21seSBzcHJlYWQgaW4g dGhlIGZsb3cNCg0KPg0KDQo+Pj4gaWRlbnRpZmljYXRpb24gc3BhY2UsIHRoZSBmbG93IHJhdGVz IGFyZSBtdWNoIHNtYWxsZXIgY29tcGFyZWQgdG8NCg0KPj4+IHRoZQ0KDQo+DQoNCj4+PiBsaW5r IGNhcGFjaXR5LA0KDQo+DQoNCj4NCg0KPj4gVGhhdCBzb3VuZHMgbGlrZSBtYWdpYy4gSSBkb24n dCB0aGluayB5b3UgbWVhbiB0aGF0IGF0IGFsbC4NCg0KPg0KDQo+DQoNCj4+PiBhbmQgdGhlIHJh dGUgZGlmZmVyZW5jZXMgYXJlIG5vdCBkcmFtYXRpYywNCg0KPg0KDQo+DQoNCj4+IERvIHlvdSBt ZWFuIHRoYXQgdGhlIHRvdGFsIHRyYWZmaWMgcmF0ZSBpcyBtb3JlIGZhaXJseSBkaXN0cmlidXRl ZCBhY3Jvc3MgdGhlIGxpbmtzPyBJbiBhbnkgY2FzZSwgImRyYW1hdGljIiBpc24ndCBhbiBlbmdp bmVlcmluZyB0ZXJtLg0KDQo+DQoNCj4NCg0KPg0KDQo+Pj4gdGhlIGhhc2hpbmcNCg0KPg0KDQo+ Pj4gYWxnb3JpdGhtIHdvcmtzIHZlcnkgd2VsbCBpbiBnZW5lcmFsLg0KDQo+DQoNCj4NCg0KPj4g SG93IGNhbiB5b3Ugc2F5IHRoYXQgd2l0aG91dCBzcGVjaWZ5aW5nIGEgcGFydGljdWxhciBhbGdv cml0aG0/IEFsc28sICJ2ZXJ5IHdlbGwgaW4gZ2VuZXJhbCIgaXNuJ3QgYW4gZW5naW5lZXJpbmcg dGVybSBlaXRoZXIuDQoNCj4NCg0KPg0KDQo+Pj4gVGhlcmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9z aXRpdmVzIGR1ZSB0byBtdWx0aXBsZSBvdGhlciBmbG93cw0KDQo+DQoNCj4+PiBtYXNxdWVyYWRp bmcgYXMgYSBsYXJnZSBmbG93OyB0aGUgYW1vdW50IG9mIGZhbHNlIHBvc2l0aXZlcyBpcw0KDQo+ DQoNCj4+PiByZWR1Y2VkIGJ5IHBhcmFsbGVsIGhhc2hpbmcgdXNpbmcgZGlmZmVyZW50IGhhc2gg ZnVuY3Rpb25zDQoNCj4NCg0KPg0KDQo+PiBUbyBnaXZlIHlvdSBzb21lIGRhdGEsIHdpdGggYSAy MCBiaXQgSUQgc3BhY2UsIHRoZSBGTlYxYS0zMiBoYXNoIGFsZ29yaXRobSBnaXZlcyBhdCBtb3N0 IDUlIGNvbGxpc2lvbnMsIGJhc2VkIG9uIElQdjYgaGVhZGVycyBpbiByZWFsIHBhY2tldCB0cmFj ZXMuDQoNCj4NCg0KPj4gW2h0dHBzOi8vcmVzZWFyY2hzcGFjZS5hdWNrbGFuZC5hYy5uei9oYW5k bGUvMjI5Mi8xMzI0MF0NCg0KPg0KDQo+PiBJIHdvbmRlciB3aGV0aGVyIHRoZSBvdmVyaGVhZCBv ZiBydW5uaW5nIHNldmVyYWwgaGFzaGVzIGluIHBhcmFsbGVsIGlzIGp1c3RpZmllZCBieSB0aGlz IGNvbGxpc2lvbiByYXRlPw0KDQo+DQoNCj4NCg0KPj4gUmVnYXJkcw0KDQo+DQoNCj4NCg0KPj4g ICAgQnJpYW4gQ2FycGVudGVyDQoNCj4NCg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KPg0KDQo+DQoNCj4+IE9QU0FXRyBtYWlsaW5nIGxpc3QN Cg0KPg0KDQo+PiBPUFNBV0dAaWV0Zi5vcmc8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZzxtYWlsdG86 T1BTQVdHQGlldGYub3JnJTNjbWFpbHQ8bWFpbHRvOk9QU0FXR0BpZXRmLm9yZyUzY21haWx0bzpP UFNBV0dAaWV0Zi5vcmclM2NtYWlsdG86T1BTQVdHQGlldGYub3JnJTNjbWFpbHQ+DQoNCj4+IG86 T1BTQVdHQGlldGYub3JnPj4NCg0KPg0KDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29wc2F3Zw0K --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1E214HQ1EXCH01corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQg MiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE3MDk5Mzk4OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTYyNDI3NTM4NiA4NjgxODk5NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk Pjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRT ZWN0aW9uMT48cCBjbGFzcz1Nc29QbGFpblRleHQ+SGkgQnJpYW4sPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD5BIHBvdGVudGlhbCBsb25nLWxpdmVkIGxhcmdlIGZsb3cgaXMgZGVjbGFyZWQgaWYgaXQg ZXhjZWVkcyBhIHByZS1wcm9ncmFtbWVkIHRocmVzaG9sZCBpbiAqYWxsIHRoZSBtYXRjaGluZyBo YXNoIHRhYmxlIGVudHJpZXMqLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+VGhyb3VnaCB0aGUgdXNl IG9mIG11bHRpcGxlIGhhc2hlcywgdGhlIGJlbmVmaXQgb2YgYXZvaWRpbmcgZmFsc2UgcG9zaXRp dmVzIGlzIGEgbXVjaCBtb3JlIHRoYW4gYSBzbWFsbCBmcmFjdGlvbiwgc2VlIGFuIGFwcHJveGlt YXRlIHNhbXBsZSBwcm9iYWJpbGlzdGljIGNhbGN1bGF0aW9uIGJlbG93LjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+TGV0IHVzIGFzc3VtZSB0aGUgbnVtYmVyIG9mIGhhc2ggc3RhZ2VzIGlzIG0gKDQp LiBMZXQgdXMgYXNzdW1lIHRoZSBwcm9iYWJpbGl0eSBvZiBhIHNob3J0LWxpdmVkIGZsb3cgbWF0 Y2hpbmcgYSBzaW5nbGUgaGFzaCB0YWJsZSBlbnRyeSBpcyAuMjUuIEZvciBhIHNob3J0LWxpdmVk IGZsb3cgdG8gYmUgZGVjbGFyZWQgYSBsb25nLWxpdmVkIGxhcmdlIGZsb3csIGl0IG5lZWRzIHRv IG1hdGNoIHRoZSBzYW1lIGhhc2ggdGFibGUgZW50cmllcyBhcyB0aGUgbG9uZy1saXZlZCBsYXJn ZSBmbG93LiBUaGUgYXBwcm94aW1hdGUgcHJvYmFiaWxpdHkgb2YgdGhpcyBldmVudCBpcyAoLjI1 KV5tID0gKC4yNSleNCA9IC4wMDM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRoYW5rcyw8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+cmFta2k8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFtt YWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSA8YnI+U2VudDogVHVlc2RheSwgSmFu dWFyeSAxNSwgMjAxMyAxMjoxMyBBTTxicj5UbzogcmFta2kgS3Jpc2huYW48YnI+Q2M6IGRyYWZ0 LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nQHRvb2xzLmlldGYub3Jn OyBvcHNhd2dAaWV0Zi5vcmc8YnI+U3ViamVjdDogUmU6IFtPUFNBV0ddIEktRCBBY3Rpb246IGRy YWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAyLnR4dDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+UmFtLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+SSB1bmRlcnN0YW5k IGV2ZXJ5dGhpbmcgeW91IHNheSBiZWxvdy4gQnV0IHlvdSBhcmVuJ3QgY29tbWVudGluZyBvbiBt eSBtYWluIHBvaW50OiB3aHkgaXMgaXQgd29ydGggdGhlICpleHRyYSogY29zdCBvZiBydW5uaW5n IHNldmVyYWwgaGFzaGVzIGluIHBhcmFsbGVsIHRvIGV4Y2x1ZGUgYSAqc21hbGwqIGZyYWN0aW9u IG9mIG1pcy1pZGVudGlmaWVkIGxhcmdlIGZsb3dzPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD5UbyBtZSwgdGhhdCBpcyBub3QgYSB1c2VmdWwgZW5naW5lZXJpbmcgdHJhZGUt b2ZmLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+UmVnYXJkczxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD7CoMKgIEJyaWFuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5PbiAxNC8wMS8y MDEzIDE3OjQ4LCByYW1raSBLcmlzaG5hbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyBIaSBCcmlhbiw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgZGlkbid0IGV4cGxhaW4gbXkg cG9pbnQgc3VmZmljaWVudGx5LiBJIHVuZGVyc3RhbmQgd2h5IHlvdSBzdWdnZXN0IHVzaW5nIHNl dmVyYWwgaGFzaGVzLiBCdXQgdGhpcyBpcyBzdGF0aXN0aWNhbCBsb2FkIGJhbGFuY2luZyB3ZSBh cmUgdGFsa2luZyAmZ3Q7Jmd0O2Fib3V0LiBJZiBhIGZldyAlIG9mIHRoZSB0aW1lLCB5b3UgbWlz dGFrZW5seSB0cmVhdCBzZXZlcmFsIG1lZGl1bSBmbG93cyBhcyBvbmUgbGFyZ2UgZmxvdywgYW5k IHRoZXJlZm9yZSByZWJhbGFuY2UgdGhlbSBhcyBhIHNpbmdsZSB1bml0LCBzbyB3aGF0PyAmZ3Q7 Jmd0O1lvdSB3aWxsIHN0aWxsIGJhbGFuY2UgdGhlIHRyYWZmaWMgcmVhc29uYWJseSB3ZWxsLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IEVhY2gg b2YgdGhlIGZsb3dzIGlzIGV2ZW50dWFsbHkgbGVhcm50L3Byb2dyYW1tZWQgaW4gYSBmbG93IHRh YmxlIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IChoYXJkd2FyZSB0 YWJsZSByZXNvdXJjZSB3aGVyZSB0aGUgZmxvdyBpcyBmaW5hbGx5IGNvbW1pdHRlZCk7IHRoZXJl IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IGlzIG5ldmVyIGEgY2Fz ZSBvZiBidW5kbGluZyBtdWx0aXBsZSBmbG93cy4gTW9yZSBkZXRhaWxzIGJlbG93PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgMSnCoMKgwqAgU2Nh bGFibGUgZGV0ZWN0aW9uIG9mIGxvbmctbGl2ZWQgbGFyZ2UgZmxvd3M8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyBhLsKgwqDCoCBUaGUgZ29hbCBpcyB0byBrZWVwIHRoZSBzaXplIG9mIHRoZSBm bG93IHRhYmxlIChoYXJkd2FyZSB0YWJsZSByZXNvdXJjZSB3aGVyZSB0aGUgbG9uZy1saXZlZCBs YXJnZSBmbG93IGlzIGZpbmFsbHkgY29tbWl0dGVkKSBib3VuZGVkIGFuZCB0aGUgcHJvY2Vzc2lu ZyByZXF1aXJlbWVudHMgKENQVSB1dGlsaXphdGlvbikgZm9yIGZsb3cgbGVhcm5pbmcgYm91bmRl ZC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBiLsKgwqDCoCBGb3Igc2F0aXNmeWluZyB0aGUg YWJvdmUgZ29hbCwgc2V2ZXJhbCBoYXNoZXMgaGVscHMuPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgMinCoMKgwqAgU2NhbGFibGUgbG9hZC1iYWxh bmNpbmcgb2YgbG9uZy1saXZlZCBsYXJnZSBmbG93czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IGEuwqDCoMKgIFRoZSBnb2FsIGlzIHRvIGhhdmUgYSBzY2FsYWJsZSBsb2FkIGJhbGFuY2luZyBz b2x1dGlvbiB3aGljaCBwcm9kdWNlcyBtZWFuaW5nZnVsIHJlc3VsdHMgd2hpbGUga2VlcGluZyB0 aGUgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMgKENQVSB1dGlsaXphdGlvbikgZm9yIGxvYWQtYmFs YW5jaW5nIGJvdW5kZWQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgYi7CoMKgwqAgRm9yIHNh dGlzZnlpbmcgdGhlIGFib3ZlIGdvYWwsIGl0IGlzIG5vdCB3b3J0aHdoaWxlIHRvIGxvYWQtYmFs YW5jZSBtZWRpdW0vc21hbGwgZmxvd3MuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgVGhhbmtzLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHJh bTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgWzxhIGhyZWY9Im1haWx0bzpicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQt ZGVjb3JhdGlvbjpub25lJz5tYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPC9zcGFu PjwvYT5dPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgU2VudDogU3Vu ZGF5LCBKYW51YXJ5IDEzLCAyMDEzIDEyOjA2IEFNPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgVG86IHJhbWtpIEtyaXNobmFuPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1rcmlzaG5hbi1vcHNh d2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9 J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPmRyYWZ0LWtyaXNobmFuLW9w c2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT47 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxhIGhyZWY9Im1haWx0 bzpvcHNhd2dAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lJz5vcHNhd2dAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9u OiA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBkcmFmdC1rcmlzaG5h bi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZy0wMi50eHQ8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBSYW0sPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgT24gMTMvMDEvMjAxMyAwNTox NCwgcmFta2kgS3Jpc2huYW4gd3JvdGU6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEhp IEJyaWFuLDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBs ZWFzZSBmaW5kIGFuc3dlcnMgdG8gc29tZSBvZiB5b3VyIGNvbW1lbnRzLiBXZSB3aWxsIHJlc3Bv bmQgdG8geW91ciBvdGhlciBjb21tZW50cyBzaG9ydGx5LjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgVGhl cmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBtdWx0aXBsZSBvdGhlciBmbG93 czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgbWFzcXVlcmFkaW5nIGFzIGEgbGFy Z2UgZmxvdzsgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3NpdGl2ZXMgaXM8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyZndDsmZ3Q7IHJlZHVjZWQgYnkgcGFyYWxsZWwgaGFzaGluZyB1c2luZyBkaWZm ZXJlbnQgaGFzaCBmdW5jdGlvbnM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgQnJpYW46PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7 Jmd0OyBUbyBnaXZlIHlvdSBzb21lIGRhdGEsIHdpdGggYSAyMCBiaXQgSUQgc3BhY2UsIHRoZSBG TlYxYS0zMiBoYXNoIGFsZ29yaXRobSBnaXZlcyBhdCBtb3N0IDUlIGNvbGxpc2lvbnMsIGJhc2Vk IG9uIElQdjYgaGVhZGVycyBpbiByZWFsIHBhY2tldCB0cmFjZXMuIMKgW2h0dHBzOi8vcmVzZWFy Y2hzcGFjZS5hdWNrbGFuZC5hYy5uei9oYW5kbGUvMjI5Mi8xMzI0MF0uIEkgd29uZGVyIHdoZXRo ZXIgdGhlIG92ZXJoZWFkIG9mIHJ1bm5pbmcgc2V2ZXJhbCBoYXNoZXMgaW4gcGFyYWxsZWwgaXMg anVzdGlmaWVkIGJ5IHRoaXMgY29sbGlzaW9uIHJhdGU/PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFJhbTo8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyZndDsgVGhlIG5lZWQgZm9yIG11bHRpcGxlIGhhc2hlcyBpcyBzcGVjaWZpYyB0byB0 aGUgc3VnZ2VzdGVkIGFsZ29yaXRobSBvbiBhdXRvbWF0aWMgaGFyZHdhcmUgaWRlbnRpZmljYXRp b24gLSB0aGlzIGFsZ29yaXRobSBpcyBzaW1pbGFyIHRvIGEgYmxvb20gZmlsdGVyIHdoaWNoIHVz ZXMgbXVsdGlwbGUgaGFzaCBmdW5jdGlvbnMuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgSSB0aGluayBkaWRuJ3QgZXhwbGFpbiBteSBwb2ludCBz dWZmaWNpZW50bHkuIEkgdW5kZXJzdGFuZCB3aHkgeW91IHN1Z2dlc3QgdXNpbmcgc2V2ZXJhbCBo YXNoZXMuIEJ1dCB0aGlzIGlzIHN0YXRpc3RpY2FsIGxvYWQgYmFsYW5jaW5nIHdlIGFyZSB0YWxr aW5nIGFib3V0LiBJZiBhIGZldyAlIG9mIHRoZSB0aW1lLCB5b3UgbWlzdGFrZW5seSB0cmVhdCBz ZXZlcmFsIG1lZGl1bSBmbG93cyBhcyBvbmUgbGFyZ2UgZmxvdywgYW5kIHRoZXJlZm9yZSByZWJh bGFuY2UgdGhlbSBhcyBhIHNpbmdsZSB1bml0LCBzbyB3aGF0PyBZb3Ugd2lsbCBzdGlsbCBiYWxh bmNlIHRoZSB0cmFmZmljIHJlYXNvbmFibHkgd2VsbC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0O8KgwqDCoMKgIEJyaWFuPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7ICZxdW90O09uIHBhY2tl dCBhcnJpdmFsLCBhIG5ldyBmbG93IGlzIGxvb2tlZCB1cCBpbiBwYXJhbGxlbCBpbiBhbGwgdGhl IGhhc2ggdGFibGVzIGFuZCB0aGUgY29ycmVzcG9uZGluZyBjb3VudGVyIGlzIGluY3JlbWVudGVk LiBJZiB0aGUgY291bnRlciBleGNlZWRzIGEgcHJvZ3JhbW1lZCB0aHJlc2hvbGQgaW4gYSBnaXZl biB0aW1lIGludGVydmFsIGluIGFsbCB0aGUgaGFzaCB0YWJsZSBlbnRyaWVzLCBhIGNhbmRpZGF0 ZSBsYXJnZSBmbG93IGlzIGxlYXJudCBhbmQgcHJvZ3JhbW1lZCBpbiBhIGhhcmR3YXJlIHRhYmxl IHJlc291cmNlIGxpa2UgVENBTS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgRm9yIGEgc2hvcnQtbGl2ZWQgZmxvdyB0byBtYXNxdWVyYWRl IGFzIGEgbG9uZy1saXZlZCBsaXZlZCBmbG93LCBpdCBuZWVkcyB0byBtYXRjaCBhbGwgdGhlIGhh c2ggdGFibGUgZW50cmllcyB3aGljaCBpcyBhIGpvaW50IHByb2JhYmlsaXR5IGV2ZW50IC0gdGh1 cywgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3NpdGl2ZXMgZHVlIHRvIHNob3J0LWxpdmVkIGZsb3dz IGlzIHJlZHVjZWQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsmZ3Q7IFRoYW5rcyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgcmFtPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IEZy b206IDxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyUzY21haWx0bzpvcHNh d2ctYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUnPm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnJmx0O21haWx0bzpvcHNhd2ct Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgWzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUn Pm1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50ZXI8bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgU2VudDogU2F0dXJkYXksIEphbnVhcnkgMTIsIDIwMTMgODo0 MCBBTTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBUbzogPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1rcmlzaG5h bi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFuY2luZ0B0b29scy5pZXRmLm9yZyUzY21haWx0 byI+PHNwYW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPmRy YWZ0LWtyaXNobmFuLW9wc2F3Zy1sYXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nQHRvb2xzLmlldGYu b3JnJmx0O21haWx0bzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsmZ3Q7IDpkcmFmdC1rcmlzaG5hbi1vcHNhd2ctbGFyZ2UtZmxvdy1sb2FkLWJhbGFu Y2luZ0B0b29scy5pZXRmLm9yZyZndDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgQ2M6 IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmclM2NtYWlsdG86b3BzYXdnQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSc+b3Bz YXdnQGlldGYub3JnJmx0O21haWx0bzpvcHNhd2dAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgU3ViamVjdDogUmU6IFtPUFNBV0ddIEktRCBBY3Rp b246PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1s YXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAyLnR4dDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBIaSw8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyZndDsgTXkgY29tbWVudHMgYXJlIG9uIHRoZSBkaXNjdXNzaW9uIG9mIGZsb3cgSURzIGFu ZCBoYXNoaW5nLiBJJ20gbm90IGNvbW1lbnRpbmcgYXQgYWxsIG9uIHRoZSBvdmVyYWxsIHByb3Bv c2FsLCBiZWNhdXNlIEkgY2FuJ3QganVkZ2Ugd2hldGhlciB0aGUgcHJvYmxlbSBpcyByZWFsIG9y IHRoZSBzb2x1dGlvbiBpcyBwcmFjdGljYWwuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0OyBBIGxhcmdlIHNw YWNlIG9mIHRoZSBmbG93IGlkZW50aWZpY2F0aW9ucywgaS5lLiBmaW5lcjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyZndDsgZ3JhbnVsYXJpdHkgb2YgdGhlIGZsb3dzLCBjb25kdWN0cyBtb3JlIHJhbmRvbSBpbiBz cHJlYWRpbmcgdGhlIDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyZndDsgZmxvd3M8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IG92ZXIgYSBzZXQg b2YgY29tcG9uZW50IGxpbmtzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBUaGF0IGlzbid0IGFjY3VyYXRlLiBU aGUgcmVxdWlyZW1lbnQgaXMgYW4gSUQgc3BhY2UgaW4gd2hpY2ggdGhlIElEcyBiZWxvbmcgdG8g YSB1bmlmb3JtIGRpc3RyaWJ1dGlvbi4gVGVjaG5pY2FsbHkgc3BlYWtpbmcsIGlmIHlvdSBoYXZl IHR3byBsaW5rcywgYSBvbmUtYml0IGZsb3cgSUQgaXMgc3VmZmljaWVudCwgYXMgbG9uZyBhcyB0 aGUgdmFsdWVzIDAgYW5kIDEgYXJlIGVxdWFsbHkgbGlrZWx5IHRvIGFwcGVhci48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyZndDsgVGhlcmVmb3JlLCB0aGUgcHJhY3RpY2FsIGlzc3VlIGlzIG5v dCB0aGUgc2l6ZSBvZiB0aGUgSUQgc3BhY2UgYnV0IHRoZSBxdWFsaXR5IG9mIHRoZSBoYXNoIGZ1 bmN0aW9uIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIElEIG9mIGVhY2ggZmxvdy48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyZndDsgSG93ZXZlciwgd2hhdGV2ZXIgdGhlIGluaXRpYWwgSUQgc3BhY2Us IHRoZSBmaW5hbCBoYXNoIGhhcyB0byBiZSBkb3duIHRvIDAuLk4gaWYgeW91IGhhdmUgTisxIGFs dGVybmF0aXZlIHBhdGhzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHRoaW5rIHRo ZSByZWFzb24gdGhhdCB5b3VyIG1vZGVsIG5lZWRzIGEgbGFyZ2VyIElEIHNwYWNlIGlzIHRvIHJl ZHVjZSB0aGUgcHJvYmFiaWxpdHkgb2YgdHdvIGZsb3dzIGNvbGxpZGluZyBieSBjaGFuY2UgaW4g dGhlIElEIHNwYWNlLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBUaGF0IHdvdWxkIGRl ZmVhdCB5b3VyIHdpc2ggdG8gc2VwYXJhdGUgb3V0IGxhcmdlIGZsb3dzLjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyZndDsgVGhlIGFkdmFudGFnZXMgb2YgaGFzaGluZyBiYXNlZCBsb2FkPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsmZ3Q7Jmd0OyBkaXN0cmlidXRpb24gYXJlIHRoZSBwcmVzZXJ2YXRpb24gb2Yg dGhlIHBhY2tldCBzZXF1ZW5jZSBpbiBhIGZsb3c8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZn dDsmZ3Q7IGFuZCB0aGUgcmVhbCB0aW1lIGRpc3RyaWJ1dGlvbiB3aXRoIHRoZSBzdGF0ZWxlc3Mg b2YgaW5kaXZpZHVhbDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgZmxvd3MuIElm IHRoZSB0cmFmZmljIGZsb3dzIHJhbmRvbWx5IHNwcmVhZCBpbiB0aGUgZmxvdzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgaWRlbnRpZmljYXRpb24gc3BhY2UsIHRoZSBmbG93IHJh dGVzIGFyZSBtdWNoIHNtYWxsZXIgY29tcGFyZWQgdG8gPG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0OyB0aGU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZn dDsmZ3Q7IGxpbmsgY2FwYWNpdHksPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IFRoYXQgc291bmRzIGxpa2UgbWFn aWMuIEkgZG9uJ3QgdGhpbmsgeW91IG1lYW4gdGhhdCBhdCBhbGwuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7Jmd0 OyBhbmQgdGhlIHJhdGUgZGlmZmVyZW5jZXMgYXJlIG5vdCBkcmFtYXRpYyw8bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZn dDsgRG8geW91IG1lYW4gdGhhdCB0aGUgdG90YWwgdHJhZmZpYyByYXRlIGlzIG1vcmUgZmFpcmx5 IGRpc3RyaWJ1dGVkIGFjcm9zcyB0aGUgbGlua3M/IEluIGFueSBjYXNlLCAmcXVvdDtkcmFtYXRp YyZxdW90OyBpc24ndCBhbiBlbmdpbmVlcmluZyB0ZXJtLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgdGhlIGhhc2hpbmc8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IGFsZ29yaXRobSB3b3JrcyB2ZXJ5IHdlbGwgaW4g Z2VuZXJhbC48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgSG93IGNhbiB5b3Ugc2F5IHRoYXQgd2l0aG91dCBzcGVj aWZ5aW5nIGEgcGFydGljdWxhciBhbGdvcml0aG0/IEFsc28sICZxdW90O3Zlcnkgd2VsbCBpbiBn ZW5lcmFsJnF1b3Q7IGlzbid0IGFuIGVuZ2luZWVyaW5nIHRlcm0gZWl0aGVyLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 Jmd0OyZndDsgVGhlcmUgbWF5IGJlIHNvbWUgZmFsc2UgcG9zaXRpdmVzIGR1ZSB0byBtdWx0aXBs ZSBvdGhlciBmbG93czxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyZndDsgbWFzcXVlcmFk aW5nIGFzIGEgbGFyZ2UgZmxvdzsgdGhlIGFtb3VudCBvZiBmYWxzZSBwb3NpdGl2ZXMgaXM8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsmZ3Q7IHJlZHVjZWQgYnkgcGFyYWxsZWwgaGFzaGlu ZyB1c2luZyBkaWZmZXJlbnQgaGFzaCBmdW5jdGlvbnM8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgVG8gZ2l2ZSB5 b3Ugc29tZSBkYXRhLCB3aXRoIGEgMjAgYml0IElEIHNwYWNlLCB0aGUgRk5WMWEtMzIgaGFzaCBh bGdvcml0aG0gZ2l2ZXMgYXQgbW9zdCA1JSBjb2xsaXNpb25zLCBiYXNlZCBvbiBJUHY2IGhlYWRl cnMgaW4gcmVhbCBwYWNrZXQgdHJhY2VzLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBb aHR0cHM6Ly9yZXNlYXJjaHNwYWNlLmF1Y2tsYW5kLmFjLm56L2hhbmRsZS8yMjkyLzEzMjQwXTxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBJIHdvbmRlciB3aGV0aGVyIHRoZSBvdmVyaGVh ZCBvZiBydW5uaW5nIHNldmVyYWwgaGFzaGVzIGluIHBhcmFsbGVsIGlzIGp1c3RpZmllZCBieSB0 aGlzIGNvbGxpc2lvbiByYXRlPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBSZWdhcmRzPG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7 wqDCoMKgIEJyaWFuIENhcnBlbnRlcjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0 OyBPUFNBV0cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmclM2NtYWlsdG86T1BTQVdHQGlldGYub3JnJTNjbWFp bHRvOk9QU0FXR0BpZXRmLm9yZyUzY21haWx0Ij48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSc+T1BTQVdHQGlldGYub3JnJmx0O21haWx0bzpPUFNBV0dA aWV0Zi5vcmcmbHQ7bWFpbHRvOk9QU0FXR0BpZXRmLm9yZyUzY21haWx0PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyZndDsgbzpPUFNBV0dAaWV0Zi5v cmcmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+PHNwYW4gc3R5bGU9J2NvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb3BzYXdnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FD1E214HQ1EXCH01corp_-- From brian.e.carpenter@gmail.com Tue Jan 15 23:55:29 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD3021F8718 for ; Tue, 15 Jan 2013 23:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.591 X-Spam-Level: X-Spam-Status: No, score=-101.591 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jjgoCY9-6Hq for ; Tue, 15 Jan 2013 23:55:28 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE821F8715 for ; Tue, 15 Jan 2013 23:55:27 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hq4so3146575wib.13 for ; Tue, 15 Jan 2013 23:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ni0xXxr7DZlJ1hBUbACf4MiM2v2nG0EvpNm/3cpXsqc=; b=rfIslnpZie5lXjUYfddFA4iyMy3OzML/wBphRj1rzwcab4iPL8XEpDq3RynnpqfiqU h6LMraxygLINiJbAQIgjaBP0hm3gteBgr1YX5LtpzZExxcGLK/RDBbYa4s4EO1uS1JgR 2Zd5lbVIPXFzW2j9n1Yl11P+YAoj/57Ek6P8MTz+EbuTImlY6VS0b4iTz7eO5p/ZYyNG NRDXyzbLTfGP/p3hqor1WHu8rUYanxXjCiz6gmzIiaoc+iKvEQxoFUGcQnnssxLjIIBF SGDp/QNgBXBPjArzh0ujre78j50bZ/WwGuKwgq2SU20JokL5hGrnzW3MvXqa+r5ITCQR nEqA== X-Received: by 10.180.79.194 with SMTP id l2mr334163wix.22.1358322927273; Tue, 15 Jan 2013 23:55:27 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-225.as13285.net. [2.101.188.225]) by mx.google.com with ESMTPS id p3sm7065688wic.8.2013.01.15.23.55.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 23:55:26 -0800 (PST) Message-ID: <50F65CF0.2060909@gmail.com> Date: Wed, 16 Jan 2013 07:55:28 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ramki Krishnan References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:55:29 -0000 Again, I am not challenging your logic. I am challenging your statistics. "Let us assume the probability of a short-lived flow matching a single hash table entry is .25" That would be a very poor hash function. As I said, FNV gave me a worst-case result close 0.02 (5%) with real data. Regards Brian On 15/01/2013 18:17, ramki Krishnan wrote: > Hi Brian, > > > > A potential long-lived large flow is declared if it exceeds a pre-programmed threshold in *all the matching hash table entries*. > > > > Through the use of multiple hashes, the benefit of avoiding false positives is a much more than a small fraction, see an approximate sample probabilistic calculation below. > > > > Let us assume the number of hash stages is m (4). Let us assume the probability of a short-lived flow matching a single hash table entry is .25. For a short-lived flow to be declared a long-lived large flow, it needs to match the same hash table entries as the long-lived large flow. The approximate probability of this event is (.25)^m = (.25)^4 = .003 > > > > Thanks, > > ramki > > > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, January 15, 2013 12:13 AM > To: ramki Krishnan > Cc: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org; opsawg@ietf.org > Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > > > Ram, > > > > I understand everything you say below. But you aren't commenting on my main point: why is it worth the *extra* cost of running several hashes in parallel to exclude a *small* fraction of mis-identified large flows? > > To me, that is not a useful engineering trade-off. > > > > Regards > > Brian > > > > On 14/01/2013 17:48, ramki Krishnan wrote: > >> Hi Brian, > > > > >>>> I think didn't explain my point sufficiently. I understand why you suggest using several hashes. But this is statistical load balancing we are talking >>about. If a few % of the time, you mistakenly treat several medium flows as one large flow, and therefore rebalance them as a single unit, so what? >>You will still balance the traffic reasonably well. > > > > >> Each of the flows is eventually learnt/programmed in a flow table > >> (hardware table resource where the flow is finally committed); there > >> is never a case of bundling multiple flows. More details below > > > > >> 1) Scalable detection of long-lived large flows > > >> a. The goal is to keep the size of the flow table (hardware table resource where the long-lived large flow is finally committed) bounded and the processing requirements (CPU utilization) for flow learning bounded. > > >> b. For satisfying the above goal, several hashes helps. > > > > >> 2) Scalable load-balancing of long-lived large flows > > >> a. The goal is to have a scalable load balancing solution which produces meaningful results while keeping the processing requirements (CPU utilization) for load-balancing bounded. > > >> b. For satisfying the above goal, it is not worthwhile to load-balance medium/small flows. > > > > >> Thanks, > > >> ram > > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Sunday, January 13, 2013 12:06 AM > >> To: ramki Krishnan > >> Cc: draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org; > >> opsawg@ietf.org > >> Subject: Re: [OPSAWG] I-D Action: > >> draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > > > >> Ram, > > > > >> On 13/01/2013 05:14, ramki Krishnan wrote: > > >>> Hi Brian, > > > >>> Thanks a lot for your comments. Please find answers to some of your comments. We will respond to your other comments shortly. > > > >>>> There may be some false positives due to multiple other flows > > >>>> masquerading as a large flow; the amount of false positives is > > >>>> reduced by parallel hashing using different hash functions > > > >>> Brian: > > > >>>> To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. [https://researchspace.auckland.ac.nz/handle/2292/13240]. I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > > >>> Ram: > > > >>> The need for multiple hashes is specific to the suggested algorithm on automatic hardware identification - this algorithm is similar to a bloom filter which uses multiple hash functions. > > > > >> I think didn't explain my point sufficiently. I understand why you suggest using several hashes. But this is statistical load balancing we are talking about. If a few % of the time, you mistakenly treat several medium flows as one large flow, and therefore rebalance them as a single unit, so what? You will still balance the traffic reasonably well. > > > > >> Brian > > > > >>> "On packet arrival, a new flow is looked up in parallel in all the hash tables and the corresponding counter is incremented. If the counter exceeds a programmed threshold in a given time interval in all the hash table entries, a candidate large flow is learnt and programmed in a hardware table resource like TCAM. > > > > >>> For a short-lived flow to masquerade as a long-lived lived flow, it needs to match all the hash table entries which is a joint probability event - thus, the amount of false positives due to short-lived flows is reduced. > > > > >>> Thanks, > > > >>> ram > > > >>> -----Original Message----- > > >>> From: opsawg-bounces@ietf.org> > >>> [mailto:opsawg-bounces@ietf.org] On > > >>> Behalf Of Brian E Carpenter > > >>> Sent: Saturday, January 12, 2013 8:40 AM > > >>> To: > >>> draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org > >>> :draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org> > > >>> Cc: opsawg@ietf.org> > > >>> Subject: Re: [OPSAWG] I-D Action: > > >>> draft-krishnan-opsawg-large-flow-load-balancing-02.txt > > > >>> Hi, > > > >>> My comments are on the discussion of flow IDs and hashing. I'm not commenting at all on the overall proposal, because I can't judge whether the problem is real or the solution is practical. > > > >>>> A large space of the flow identifications, i.e. finer > > > >>>> granularity of the flows, conducts more random in spreading the > >>>> flows > > >>>> over a set of component links. > > > >>> That isn't accurate. The requirement is an ID space in which the IDs belong to a uniform distribution. Technically speaking, if you have two links, a one-bit flow ID is sufficient, as long as the values 0 and 1 are equally likely to appear. > > >>> Therefore, the practical issue is not the size of the ID space but the quality of the hash function used to generate the ID of each flow. > > >>> However, whatever the initial ID space, the final hash has to be down to 0..N if you have N+1 alternative paths. > > >>> I think the reason that your model needs a larger ID space is to reduce the probability of two flows colliding by chance in the ID space. > > >>> That would defeat your wish to separate out large flows. > > > >>>> The advantages of hashing based load > > >>>> distribution are the preservation of the packet sequence in a flow > > >>>> and the real time distribution with the stateless of individual > > >>>> flows. If the traffic flows randomly spread in the flow > > >>>> identification space, the flow rates are much smaller compared to > >>>> the > > >>>> link capacity, > > > >>> That sounds like magic. I don't think you mean that at all. > > > >>>> and the rate differences are not dramatic, > > > >>> Do you mean that the total traffic rate is more fairly distributed across the links? In any case, "dramatic" isn't an engineering term. > > > > >>>> the hashing > > >>>> algorithm works very well in general. > > > >>> How can you say that without specifying a particular algorithm? Also, "very well in general" isn't an engineering term either. > > > >>>> There may be some false positives due to multiple other flows > > >>>> masquerading as a large flow; the amount of false positives is > > >>>> reduced by parallel hashing using different hash functions > > > >>> To give you some data, with a 20 bit ID space, the FNV1a-32 hash algorithm gives at most 5% collisions, based on IPv6 headers in real packet traces. > > >>> [https://researchspace.auckland.ac.nz/handle/2292/13240] > > >>> I wonder whether the overhead of running several hashes in parallel is justified by this collision rate? > > > >>> Regards > > > >>> Brian Carpenter > > >>> _______________________________________________ > > > >>> OPSAWG mailing list > > >>> OPSAWG@ietf.org > >>> o:OPSAWG@ietf.org>> > > >>> https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Wed Jan 16 00:02:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDEB21F8798 for ; Wed, 16 Jan 2013 00:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMf5uRUBHR89 for ; Wed, 16 Jan 2013 00:02:06 -0800 (PST) Received: from mail-da0-f52.google.com (mail-da0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2615E21F8792 for ; Wed, 16 Jan 2013 00:02:06 -0800 (PST) Received: by mail-da0-f52.google.com with SMTP id f10so462955dak.39 for ; Wed, 16 Jan 2013 00:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o+V7L36JoC2aQOQ8Wb86Yxx2q+Uphyl3EyTGSoIyVnM=; b=N3YgegHOJjtnDpmO0hxbjXoDTDwg9BOWyp1QmrTLmRkOpFRgC0QOFVoBxIupVj/oOC HMIgGimkz5nxilvngox8hmXgM3JUvGptM3cLe19KAklTaAAJRhM+6GJ4po1gMYJ2Gk3g j3o63mwKRfwET7NpH7RFGyWHDz4rhWQjeV5npWtoaUhiV7YB5Z6OyyHT4LqnXIQsU2U+ F1cPP/eBo3okCnaBAPmhEe4jpbB6Uis6Wgb0qdrH4osSorqbeLw2JjosmNHcELZkhMWm LKhIZYFLrT+LrvD9ZkD1U79u02xKrAys3H2sqNs9lGEe2/sJpFk3IvKhgo2/GQuq3UPH DXUQ== X-Received: by 10.68.203.198 with SMTP id ks6mr595365pbc.35.1358323325893; Wed, 16 Jan 2013 00:02:05 -0800 (PST) Received: from spandex.local (216-67-47-203-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.47.203]) by mx.google.com with ESMTPS id o5sm12512001paz.32.2013.01.16.00.02.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 00:02:05 -0800 (PST) Message-ID: <50F65E79.4090802@gmail.com> Date: Tue, 15 Jan 2013 23:02:01 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> <50F65CF0.2060909@gmail.com> In-Reply-To: <50F65CF0.2060909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 08:02:06 -0000 On 1/15/13 10:55 PM, Brian E Carpenter wrote: > "Let us assume the probability of a short-lived flow matching a > single hash table entry is .25" > That would be a very poor hash function. That would be a disturbingly bad hash function. But let me ask this: do you think the model would be workable with a better hash function? Melinda From brian.e.carpenter@gmail.com Wed Jan 16 00:17:52 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F021F84D1 for ; Wed, 16 Jan 2013 00:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg5H3L1MjF0d for ; Wed, 16 Jan 2013 00:17:51 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7236621F84BB for ; Wed, 16 Jan 2013 00:17:51 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so659530wgi.3 for ; Wed, 16 Jan 2013 00:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cQY3aA7Os8mfW86rOKVZS52TeydVF3mDLxXqy32oZJw=; b=r3lcQER9yFS690wXD+i7B5MINAK2b1koBkhvMr/M46Ih8Dmc6XNLBL0piOhbA1hu/5 AU7DfvgafsuKmjR2JF/psYglqkTOXn7nC7WQPWMep/VuujrxD2oCP+Obq2aMcYPvtXsl ngCOEKj7TAkW1msVAxKE1RoVx2RrqaRWOGTSF9YnXErylgyUKYj7K640luIrFyyN3BDl cOkNhNzlz3BrlOlc3uhbI/WZdWSwsrh1BfPUk/q3yzep6rvldmbp8lwhrtPCdtzQ3cs4 Ke6KHJqCfAOOTOIX41Pc7Qfyw+zODtbLjUQUo0B5i1eke2tfTFWMpUY4ZijMoQCe3tGr NNZA== X-Received: by 10.180.108.236 with SMTP id hn12mr8219087wib.6.1358324270491; Wed, 16 Jan 2013 00:17:50 -0800 (PST) Received: from [192.168.1.65] (host-2-101-188-225.as13285.net. [2.101.188.225]) by mx.google.com with ESMTPS id w5sm7144188wif.11.2013.01.16.00.17.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 00:17:49 -0800 (PST) Message-ID: <50F66235.1060500@gmail.com> Date: Wed, 16 Jan 2013 08:17:57 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Melinda Shore References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> <50F65CF0.2060909@gmail.com> <50F65E79.4090802@gmail.com> In-Reply-To: <50F65E79.4090802@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 08:17:52 -0000 On 16/01/2013 08:02, Melinda Shore wrote: > On 1/15/13 10:55 PM, Brian E Carpenter wrote: >> "Let us assume the probability of a short-lived flow matching a >> single hash table entry is .25" > >> That would be a very poor hash function. > > That would be a disturbingly bad hash function. But let me ask this: > do you think the model would be workable with a better hash function? The model works. I just don't see the point of running several inferior hash functions instead of one good one. Brian From ramk@Brocade.com Wed Jan 16 10:39:26 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554C321F8B7C for ; Wed, 16 Jan 2013 10:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs2DduP9JuC3 for ; Wed, 16 Jan 2013 10:39:25 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1514721F8B64 for ; Wed, 16 Jan 2013 10:39:21 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r0GIbnhp015971; Wed, 16 Jan 2013 10:39:15 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 19x1mp002y-9 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2013 10:39:14 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 16 Jan 2013 10:30:15 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 16 Jan 2013 10:25:52 -0800 From: ramki Krishnan To: Brian E Carpenter , Melinda Shore Date: Wed, 16 Jan 2013 10:25:45 -0800 Thread-Topic: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt Thread-Index: Ac3zwiCjI81EHQfqQ3afcvP1GbJwRwAOAXHw Message-ID: References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> <50F65CF0.2060909@gmail.com> <50F65E79.4090802@gmail.com> <50F66235.1060500@gmail.com> In-Reply-To: <50F66235.1060500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_06:2013-01-16, 2013-01-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1301160170 Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:39:26 -0000 SGkgQnJpYW4sDQoNCllvdSBhcmUgbWlzc2luZyB0aGUgc3Bpcml0IG9mIHRoZSBwcm9wb3NlZCBt dWx0aXBsZSBoYXNoaW5nIHNjaGVtZSBpbiB0ZXJtcyBvZiB0aGUgaGFzaCB0YWJsZSBzdG9yYWdl IHNjYWxhYmlsaXR5IGl0IGNhbiBvZmZlciAtIHRoaXMgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIHF1 YWxpdHkgb2YgdGhlIGhhc2ggZnVuY3Rpb25zLiBTY2FsYWJpbGl0eSBpcyBrZXkgLSBmb3IgZS5n LiB0aGVyZSBjb3VsZCBiZSBtaWxsaW9ucyBvZiBmbG93cyBvdXQgb2Ygd2hpY2ggb25seSBhIHNt YWxsIHBlcmNlbnRhZ2UgaXMgbG9uZy1saXZlZCBsYXJnZSBmbG93cyB3aGljaCB5b3Ugd291bGQg bGlrZSB0byBsZWFybi4NCg0KV2l0aCBhIHNpbmdsZSBoYXNoLCB5b3VyIGhhc2ggdGFibGUgc2l6 ZSB3b3VsZCBiZSBwcm9wb3J0aW9uYXRlIHRvIHRoZSB0b3RhbCBudW1iZXIgb2YgZmxvd3MgdG8g bWluaW1pemUgZmFsc2UgcG9zaXRpdmVzOyB3aXRoIG11bHRpcGxlIGhhc2hlcyB0aGlzIGNvdWxk IGJlIHJlZHVjZWQgdG8gYSBudW1iZXIgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2YgbG9u Zy1saXZlZCBsYXJnZSBmbG93cyAtIHRoZSBleGFjdCBudW1iZXIgd291bGQgZGVwZW5kIG9uIHRo ZSB1c2UgY2FzZXMgYW5kIHRyYWZmaWMgcGF0dGVybnMuDQoNCkFzIEkgbWVudGlvbmVkIGJlZm9y ZSwgdGhpcyBzY2hlbWUgaXMgc2ltaWxhciB0byBhIGJsb29tIGZpbHRlciAod2hpY2ggdXNlcyBt dWx0aXBsZSBoYXNoIGZ1bmN0aW9ucyB0byBzdWJzdGFudGlhbGx5IHJlZHVjZSB0aGUgYW1vdW50 IG9mIHN0b3JhZ2UpIC0gcGxlYXNlIHNlZSBiZWxvdw0KaHR0cDovL2VuLndpa2lwZWRpYS5vcmcv d2lraS9CbG9vbV9maWx0ZXINCg0KSSB3aWxsIGFsc28gYWRkIHNvbWUgdGhlc2UgZGV0YWlscyB0 byBhbiBBcHBlbmRpeCBzZWN0aW9uIGluIHRoZSBkcmFmdC4gSWYgbmVlZGVkLCBJIHdvdWxkIGJl IGdsYWQgdG8gaGF2ZSBhIGNvbmZlcmVuY2UgY2FsbCB0byBkaXNjdXNzIGZ1cnRoZXIgb24gdGhp cyB0b3BpYy4NCg0KVGhhbmtzLA0KcmFta2kNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAxNiwgMjAxMyAxMjoxOCBBTQ0KVG86IE1l bGluZGEgU2hvcmUNCkNjOiByYW1raSBLcmlzaG5hbjsgZHJhZnQta3Jpc2huYW4tb3BzYXdnLWxh cmdlLWZsb3ctbG9hZC1iYWxhbmNpbmdAdG9vbHMuaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtPUFNBV0ddIEktRCBBY3Rpb246IGRyYWZ0LWtyaXNobmFuLW9wc2F3Zy1s YXJnZS1mbG93LWxvYWQtYmFsYW5jaW5nLTAyLnR4dA0KDQpPbiAxNi8wMS8yMDEzIDA4OjAyLCBN ZWxpbmRhIFNob3JlIHdyb3RlOg0KPiBPbiAxLzE1LzEzIDEwOjU1IFBNLCBCcmlhbiBFIENhcnBl bnRlciB3cm90ZToNCj4+ICJMZXQgdXMgYXNzdW1lIHRoZSBwcm9iYWJpbGl0eSBvZiBhIHNob3J0 LWxpdmVkIGZsb3cgbWF0Y2hpbmcgYSANCj4+IHNpbmdsZSBoYXNoIHRhYmxlIGVudHJ5IGlzIC4y NSINCj4gDQo+PiBUaGF0IHdvdWxkIGJlIGEgdmVyeSBwb29yIGhhc2ggZnVuY3Rpb24uIA0KPiAN Cj4gVGhhdCB3b3VsZCBiZSBhIGRpc3R1cmJpbmdseSBiYWQgaGFzaCBmdW5jdGlvbi4gIEJ1dCBs ZXQgbWUgYXNrIHRoaXM6DQo+IGRvIHlvdSB0aGluayB0aGUgbW9kZWwgd291bGQgYmUgd29ya2Fi bGUgd2l0aCBhIGJldHRlciBoYXNoIGZ1bmN0aW9uPw0KDQpUaGUgbW9kZWwgd29ya3MuIEkganVz dCBkb24ndCBzZWUgdGhlIHBvaW50IG9mIHJ1bm5pbmcgc2V2ZXJhbCBpbmZlcmlvciBoYXNoIGZ1 bmN0aW9ucyBpbnN0ZWFkIG9mIG9uZSBnb29kIG9uZS4NCg0KICAgQnJpYW4NCg== From bclaise@cisco.com Fri Jan 18 08:07:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C54021F8880; Fri, 18 Jan 2013 08:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD4AcoEKbqDn; Fri, 18 Jan 2013 08:07:01 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E418421F88B5; Fri, 18 Jan 2013 08:06:59 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0IG6wnT001438; Fri, 18 Jan 2013 17:06:58 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0IG6K8H010215; Fri, 18 Jan 2013 17:06:30 +0100 (CET) Message-ID: <50F972FC.2030707@cisco.com> Date: Fri, 18 Jan 2013 17:06:20 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "draft-ietf-opsawg-oam-overview@tools.ietf.org" References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> In-Reply-To: <50F437BF.8040005@cisco.com> Content-Type: multipart/alternative; boundary="------------080205090701090609030103" Cc: opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:07:02 -0000 This is a multi-part message in MIME format. --------------080205090701090609030103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is Tom Nadeau's feedback, forwarded with permission: Regards, Benoit ============== Some general comments: 1. I did not find any discussion around use of configuration within OAM mechanisms. This is clearly something that is happening in groups like PWE3 and CCAMP. The motivation for this should be explained and documented to at least guide these efforts. 2. There is no real discussion around the security aspects of these tools. Should there be? 3. While the document provides a nice taxonomy of various OAM tools, it does not really discuss the techniques for using them. I do not expect anything in detail, but it is not obvious that many of these tools can be orchestrated to form a "toolset" that can be used to do multi-layer OAM functions for services such as carrier Ethernet over VPLS over MPLS, for example. 4. It might be useful to at least mention in the performance metrics section, a discussion around the accuracy of these tools and how it depends on scale, implementation and network configurations. My detailed comments inline starting with TOM: --Tom Expires: July 2013 Nokia Siemens Networks E. Bellagamba Ericsson Y. Weingarten January 9, 2013 An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms draft-ietf-opsawg-oam-overview-08.txt Abstract Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2013. Mizrahi, et al. Expires July 9, 2013 [Page 1] Internet-Draft Overview of OAM Mechanisms January 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 3 1.1. The Building Blocks of OAM .............................. 3 1.2. Forwarding Plane vs. Management Plane ................... 4 1.3. The OAM toolsets ........................................ 4 1.4. IETF OAM Documents ...................................... 6 1.5. Non-IETF OAM Documents ................................. 10 2. Basic Terminology ........................................... 12 2.1. Abbreviations .......................................... 12 2.2. Terminology used in OAM Standards ...................... 13 2.2.1. General Terms ..................................... 13 2.2.2. OAM Maintenance Entities .......................... 13 2.2.3. OAM Maintenance Points ............................ 14 2.2.4. Proactive and On-demand activation ................ 15 2.2.5. Connectivity Verification and Continuity Checks ... 15 2.2.6. Failures .......................................... 15 3. OAM Tools ................................................... 16 3.1. IP Ping and Traceroute ................................. 16 3.1.1. Ping .............................................. 16 3.1.2. Traceroute......................................... 16 3.2. Bidirectional Forwarding Detection (BFD) ............... 17 3.2.1. Overview .......................................... 17 3.2.2. BFD Control ....................................... 17 3.2.3. BFD Echo .......................................... 18 3.3. MPLS OAM ............................................... 18 3.4. MPLS-TP OAM ............................................ 19 3.4.1. Overview .......................................... 19 3.4.2. Generic Associated Channel ........................ 19 3.4.3. MPLS-TP OAM Toolset ............................... 20 3.4.3.1. Continuity Check and Connectivity Verification 20 Mizrahi, et al. Expires July 9, 2013 [Page 2] Internet-Draft Overview of OAM Mechanisms January 2013 3.4.3.2. Route Tracing ................................ 21 3.4.3.3. Lock Instruct ................................ 21 3.4.3.4. Lock Reporting ............................... 21 3.4.3.5. Alarm Reporting .............................. 21 3.4.3.6. Remote Defect Indication ..................... 22 3.4.3.7. Client Failure Indication .................... 22 3.4.3.8. Packet Loss Measurement (LM) ................. 22 3.4.3.9. Packet Delay Measurement (DM) ................ 22 3.5. PWE3 OAM ............................................... 23 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) ................................................... 23 3.5.2. PWE3 OAM using G-ACh .............................. 24 3.6. OWAMP and TWAMP......................................... 24 3.6.1. Overview .......................................... 24 3.6.2. Control and Test Protocols ........................ 24 3.6.3. OWAMP ............................................. 25 3.6.4. TWAMP ............................................. 26 3.7. Summary of OAM Functions ............................... 26 4. Security Considerations ..................................... 27 5. IANA Considerations ......................................... 27 6. Acknowledgments ............................................. 27 7. References .................................................. 28 7.1. Normative References ................................... 28 7.2. Informative References ................................. 31 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation. This document summarizes the OAM tools and mechanisms defined in the IETF. The term OAM in this document refers to Operations, Administration and Maintenance [OAM-Def], focusing on the forwarding plane of OAM. Hence, management aspects are outside the scope of this document. TOM: This is a curious sentence to me since to me, OAM is management, or a subset of it. Also, if you look at the referenced documents, there are many indirect references to MIBs, Netconf, etc... making this sentence further confusing. It might be helpful to explain more clearly that the authors here intended to not cover those things explicitly rather than grouping them arbitrarily under the definition of "management aspects" Further, to clarify, it might be useful to expand on what "forwarding plane" is here just to be clear. That is, is this "in band" or "out-of band" or both? Some of the tools referred to here also are part of the control AND data planes. 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). This subsection provides a brief summary of the common tools used by OAM protocols. An OAM protocol typically supports one or more of the tools described below. Mizrahi, et al. Expires July 9, 2013 [Page 3] Internet-Draft Overview of OAM Mechanisms January 2013 o Continuity Checking (CC): Used for verifying the liveness of a connection between two MPs. o Connectivity Verification (CV): Allows an MP to check whether it is connected to a peer MP, and to verify that messages from the peer MP are received through the expected path. o Path Discovery / Fault Localization: An MP uses this mechanism to trace the route to a peer MP, i.e., to identify the nodes along the path to the peer MP. When a connection fails, this mechanism also allows the MP to detect the location of the failure. TOM: The definition calls this "path discovery" but then talks about tracing routes. A better way of describing this in the paragraph would be that there I a use of path tracing in order to discover (or re-discover) paths that have been changed, created or destroyed. o Performance Monitoring: Consists of 3 main functions o Loss Measurement (LM) - monitors the packet loss rate of a connection. o Delay Measurement (DM) - monitors the delay and delay variation between MPs. o Throughput measurement - monitors the throughput of a connection. TOM: Along with the discussion above around path trace/discovery, it is imperative that paths be discovered (one way or another) in order to successfully d performance monitoring on those paths. 1.2. Forwarding Plane vs. Management Plane While the OAM tools may, and quite often do, work in conjunction with a control-plane or management plane, they are usually defined to be independent of the control-plane. The OAM tools communicate with the management plane to raise alarms, and often the on-demand tools may be activated by the management, e.g. to locate and localize problems. The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this document, which will concentrate on presenting the forwarding-plane tools that are used for OAM. TOM: What about the data plane? For example, the GACH OAM type is such an example. VCCV also operates within the data plane after its configuration capabilities have been signaled. It should also be mentioned that it is imperative that when required, OAM tools are capable of testing the actual data plane in as much accuracy as possible, but that they all should note how accurate. Not all OAM tools are created equal. 1.3. The OAM toolsets This memo provides an overview of the different sets of OAM mechanisms defined by the IETF. It is intended for those with little or no familiarity with the described mechanisms. The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). While OAM mechanisms that are applicable to other technologies exist, they Mizrahi, et al. Expires July 9, 2013 [Page 4] Internet-Draft Overview of OAM Mechanisms January 2013 are beyond the scope of this memo. This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. The IETF has defined OAM protocols and mechanisms in several different fronts: o IP Ping and Traceroute: Ping is a very simple and common application for failure diagnosis TOM: I am not sure the term "common" is necessary. that uses ICMP Echo requests, as defined in [ICMPv4], and [ICMPv6]. Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to trace the path between an IP source and an IP destination, i.e., to identify the nodes along the path. o BFD: Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a framework for a lightweight generic OAM mechanism. The intention is to define a base mechanism that can be used with various encapsulation types, network environments, and in various medium types. o MPLS OAM: MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- Ping], is an OAM mechanism for point to point MPLS LSPs. It includes two main functions: Ping and Traceroute. o MPLS-TP OAM: MPLS-TP OAM is defined in a set of RFCs. The OAM requirements for MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM]. Each of the tools in the OAM toolset is defined in its own RFC, as specified in Section 1.4. o PWE3 OAM: The PWE3 OAM architecture defines control channels that support the use of existing IETF OAM tools to be used for a pseudowire (PW). The control channels that are defined in [VCCV] and [PW-G- ACH] may be used in conjunction with ICMP Ping, LSP Ping, and BFD to perform CC and CV functionality. In addition the channels support use of any of the MPLS-TP based OAM tools for completing their respective OAM functionality for a PW. o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. Mizrahi, et al. Expires July 9, 2013 [Page 5] Internet-Draft Overview of OAM Mechanisms January 2013 This document summarizes the OAM mechanisms defined by the IETF. We first present a comparison of the terminology used in various OAM standards, and then summarize the OAM functions that each OAM standard provides. 1.4. IETF OAM Documents Table 1 summarizes the IETF OAM related RFCs discussed in this document. The table includes a "Type" column, specifying the nature of each of the listed documents: o Tool: documents that define an OAM tool or mechanism. o Prof.: documents that define a profile or a variant for an OAM tool that is defined in other documents. o Inf.: documents that define an infrastructure that is used by OAM tools. o Misc.: other OAM related documents, e.g., OAM requirement and framework documents. +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 | |Traceroute | [ICMPv4] | | | | +--------------------------------------+-----+----------+ | | Internet Control Message Protocol |Tool | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | | Version 6 (IPv6) Specification | | | | | [ICMPv6] | | | | +--------------------------------------+-----+----------+ | | A Primer On Internet and TCP/IP |Tool | RFC 2151 | | | Tools and Utilities [TCPIP-Tools] | | | | +--------------------------------------+-----+----------+ | | FYI on a Network Management Tool |Tool | RFC 1147 | | | Catalog: Tools for Monitoring and | | | | | Debugging TCP/IP Internets and | | | | | Interconnected Devices [NetTools] | | | | +--------------------------------------+-----+----------+ | | Extended ICMP to Support Multi-Part |Tool | RFC 4884 | Mizrahi, et al. Expires July 9, 2013 [Page 6] Internet-Draft Overview of OAM Mechanisms January 2013 | | Messages [ICMP-MP] | | | | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching [ICMP-Ext] | | | | +--------------------------------------+-----+----------+ | | Extending ICMP for Interface and |Tool | RFC 5837 | | | Next-Hop Identification [ICMP-Int] | | | +-----------+--------------------------------------+-----+----------+ |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 | | | [BFD] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5881 | | | (BFD) for IPv4 and IPv6 (Single Hop) | | | | | [BFD-IP] | | | | +--------------------------------------+-----+----------+ | | Generic Application of Bidirectional |Misc.| RFC 5882 | | | Forwarding Detection [BFD-Gen] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5883 | | | (BFD) for Multihop Paths [BFD-Multi] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5884 | | | for MPLS Label Switched Paths (LSPs) | | | | | [BFD-LSP] | | | | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | +-----------+--------------------------------------+-----+----------+ |MPLS OAM | Operations and Management (OAM) |Misc.| RFC 4377 | | | Requirements for Multi-Protocol Label| | | | | Switched (MPLS) Networks [MPLS-OAM] | | | | +--------------------------------------+-----+----------+ | | A Framework for Multi-Protocol |Misc.| RFC 4378 | | | Label Switching (MPLS) Operations | | | | | and Management (OAM) [MPLS-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Detecting Multi-Protocol Label |Tool | RFC 4379 | | | Switched (MPLS) Data Plane Failures | | | | | [LSP-Ping] | | | Mizrahi, et al. Expires July 9, 2013 [Page 7] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Operations and Management (OAM) |Misc.| RFC 4687 | | | Requirements for Point-to-Multipoint | | | | | MPLS Networks [MPLS-P2MP] | | | +-----------+--------------------------------------+-----+----------+ |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 | |OAM | [MPLS-TP-OAM] | | | | +--------------------------------------+-----+----------+ | | MPLS Generic Associated Channel |Inf. | RFC 5586 | | | [G-ACh] | | | | +--------------------------------------+-----+----------+ | | MPLS-TP OAM Framework |Misc.| RFC 6371 | | | [TP-OAM-FW] | | | | +--------------------------------------+-----+----------+ | | Proactive Connectivity Verification, |Tool | RFC 6428 | | | Continuity Check, and Remote Defect | | | | | Indication for the MPLS Transport | | | | | Profile [TP-CC-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS On-Demand Connectivity |Tool | RFC 6426 | | | Verification and Route Tracing | | | | | [OnDemand-CV] | | | | +--------------------------------------+-----+----------+ | | MPLS Fault Management Operations, |Tool | RFC 6427 | | | Administration, and Maintenance (OAM)| | | | | [TP-Fault] | | | | +--------------------------------------+-----+----------+ | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 | | | and Loopback Functions [Lock-Loop] | | | | +--------------------------------------+-----+----------+ | | Packet Loss and Delay Measurement for|Tool | RFC 6374 | | | MPLS Networks [MPLS-LM-DM] | | | | +--------------------------------------+-----+----------+ | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 | | | Profile for MPLS-Based Transport | | | | | Networks [TP-LM-DM] | | | +-----------+--------------------------------------+-----+----------+ |PWE3 OAM | Pseudowire Virtual Circuit |Inf. | RFC 5085 | | | Connectivity Verification (VCCV): | | | | | A Control Channel for Pseudowires | | | | | [VCCV] | | | Mizrahi, et al. Expires July 9, 2013 [Page 8] Internet-Draft Overview of OAM Mechanisms January 2013 | +--------------------------------------+-----+----------+ | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | | | for the Pseudowire Virtual Circuit | | | | | Connectivity Verification (VCCV) | | | | | [BFD-VCCV] | | | | +--------------------------------------+-----+----------+ | | Using the Generic Associated Channel |Inf. | RFC 6423 | | | Label for Pseudowire in the MPLS | | | | | Transport Profile (MPLS-TP) | | | | | [PW-G-ACh] | | | | +--------------------------------------+-----+----------+ | | Pseudowire (PW) Operations, |Misc.| RFC 6310 | | | Administration, and Maintenance (OAM)| | | | | Message Mapping [PW-Map] | | | +-----------+--------------------------------------+-----+----------+ |OWAMP and | A One-way Active Measurement Protocol|Tool | RFC 4656 | |TWAMP | [OWAMP] | | | | +--------------------------------------+-----+----------+ | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 | | | [TWAMP] | | | | +--------------------------------------+-----+----------+ | | Framework for IP Performance Metrics |Misc.| RFC 2330 | | | [IPPM-FW] | | | | +--------------------------------------+-----+----------+ | | IPPM Metrics for Measuring |Misc.| RFC 2678 | | | Connectivity [IPPM-Con] | | | | +--------------------------------------+-----+----------+ | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 | | | [IPPM-1DM] | | | | +--------------------------------------+-----+----------+ | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 | | | [IPPM-1LM] | | | | +--------------------------------------+-----+----------+ | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 | | | [IPPM-2DM] | | | +-----------+--------------------------------------+-----+----------+ Table 1 Summary of IETF OAM Related RFCs Mizrahi, et al. Expires July 9, 2013 [Page 9] Internet-Draft Overview of OAM Mechanisms January 2013 1.5. Non-IETF OAM Documents In addition to the OAM mechanisms defined by the IETF, the IEEE and ITU-T have also defined various OAM mechanisms that focus on Ethernet, and various other transport network environments. These various mechanisms, defined by the three standard organizations, are often tightly coupled, and have had a mutual effect on each other. The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to some extent linked to IETF OAM mechanisms listed above and are mentioned here only as reference material: o OAM mechanisms for Ethernet based networks have been defined by both the ITU-T in [ITU-T-Y1731], and by the IEEE in [IEEE802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet links [IEEE802.3ah]. o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. Table 2 summarizes the OAM standards mentioned in this document. This document focuses on IETF OAM standards, but these non-IETF standards are referenced where relevant. +-----------+--------------------------------------+---------------+ | | Title |Standard/Draft | +-----------+--------------------------------------+---------------+ |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | | +--------------------------------------+---------------+ | | Assignment of the 'OAM Alert Label' | RFC 3429 | | | for Multiprotocol Label Switching | | | | Architecture (MPLS) Operation and | | | | Maintenance (OAM) Functions | | | | [OAM-Label] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T Y.1711. | | +-----------+--------------------------------------+---------------+ |ITU-T | Operations, administration and |ITU-T G.8113.2 | |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | Mizrahi, et al. Expires July 9, 2013 [Page 10] Internet-Draft Overview of OAM Mechanisms January 2013 | | networks using the tools defined for | | | | MPLS [ITU-G8113.2] | | | | | | | | Note: this document describes the | | | | OAM toolset defined by the IETF for | | | | MPLS-TP, whereas ITU-T G.8113.1 | | | | describes the OAM toolset defined | | | | by the ITU-T. | | | +--------------------------------------+---------------+ | | Operations, Administration and |ITU-T G.8113.1 | | | Maintenance mechanism for MPLS-TP in | | | | Packet Transport Network (PTN) | | | +--------------------------------------+---------------+ | | Allocation of a Generic Associated | RFC 6671 | | | Channel Type for ITU-T MPLS Transport| | | | Profile Operation, Maintenance, and | | | | Administration (MPLS-TP OAM) | | | | [ITU-T-CT] | | | | | | | | Note: although this is an IETF | | | | document, it is listed as one of the| | | | non-IETF OAM standards, since it | | | | was defined as a complementary part | | | | of ITU-T G.8113.1. | | +-----------+--------------------------------------+---------------+ |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y1731] | |Ethernet | Ethernet-based Networks | | |OAM | | | +-----------+--------------------------------------+---------------+ |IEEE | Connectivity Fault Management | IEEE 802.1ag | |CFM | [IEEE802.1ag] | | | | | | | | Note: CFM was originally published | | | | as IEEE 802.1ag, but is now | | | | incorporated in the 802.1Q standard.| | +-----------+--------------------------------------+---------------+ |IEEE | Media Access Control Parameters, | IEEE 802.3ah | |802.3 | Physical Layers, and Management | | |link level | Parameters for Subscriber Access | | |OAM | Networks [IEEE802.3ah] | | | | | | Mizrahi, et al. Expires July 9, 2013 [Page 11] Internet-Draft Overview of OAM Mechanisms January 2013 | | Note: link level OAM was originally | | | | defined in IEEE 802.3ah, and is now | | | | incorporated in the 802.3 standard. | | +-----------+--------------------------------------+---------------+ Table 2 Non-IETF OAM Standards Mentioned in this Document 2. Basic Terminology 2.1. Abbreviations ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC Continuity Check CV Connectivity Verification DM Delay Measurement FEC Forwarding Equivalence Class GAL Generic Associated Label ICMP Internet Control Message Protocol LDP Label Distribution Protocol LM Loss Measurement LSP Label Switched Path ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MP Maintenance Point MPLS Multiprotocol Label Switching Mizrahi, et al. Expires July 9, 2013 [Page 12] Internet-Draft Overview of OAM Mechanisms January 2013 MPLS-TP MPLS Transport Profile MTU Maximum Transmission Unit OAM Operations, Administration, and Maintenance PW Pseudowire PWE3 Pseudowire Emulation Edge-to-Edge RDI Remote Defect Indication TTL Time To Live VCCV Virtual Circuit Connectivity Verification TOM: Why is this section not at the top of this document, as is customary for RFCs? 2.2. Terminology used in OAM Standards 2.2.1. General Terms A wide variety of terms is used in various OAM standards. Each of the OAM standards listed in the reference section includes a section that defines terms relevant to that tool. A thesaurus of terminology for MPLS-TP terms is presented in [TP-Term], and provides a good summary of some of the OAM related terminology. This section presents a comparison of the terms used in various OAM standards, without fully quoting the definition of each term. For a formal definition of each term, refer to the references at the end of this document. 2.2.2. OAM Maintenance Entities OAM tools are designed to monitor and manage a Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply. The following related terms are also quoted from [TP-OAM-FW]: o MEP: The two points that define a maintenance entity. o MEG: The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (MEG). Mizrahi, et al. Expires July 9, 2013 [Page 13] Internet-Draft Overview of OAM Mechanisms January 2013 o MIP: In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). A pair of MEPs engaged in an ME are connected by a communication link, which may be one of several types of connection, e.g. a single physical connection, a set of physical connections, or a virtual link such as an MPLS LSP. The term Maintenance Entity (ME) is used in ITU-T Recommendations (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM- FW]). Various terms are used to refer to an ME. For example, BFD does not explicitly use a term that is equivalent to ME, but rather uses the term "session", referring to the relationship between two nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this context. MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG allows the monitoring of a compound set of MEs, for example when monitoring a p2mp MEG that is considered to be the set of MEs between the root and each individual destination MEP. 2.2.3. OAM Maintenance Points A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it. A MIP in MPLS-TP identifies OAM packets destined to it by the value of the TTL field in the OAM packet. The term Maintenance Point is a general term for MEPs and MIPs. The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol either in the direction facing the network, or in the direction facing the bridge. A Down MP is an MP that receives OAM packets from, and transmits them to the direction of the network. An Up MP receives OAM packets from, and transmits them to the direction of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs). This placement is important for localization of a connection failure. Mizrahi, et al. Expires July 9, 2013 [Page 14] Internet-Draft Overview of OAM Mechanisms January 2013 2.2.4. Proactive and On-demand activation The different OAM tools may be used in one of two basic types of activation: o Proactive activation - indicates that the tool is activated on a continual basis periodically, where messages are sent between the two MEPs, and errors are detected when a certain number of expected messages are not received. o On-demand activation - indicates that the tool is activated "manually" to detect a specific anomaly. In this activation a small number of OAM messages are sent by a MEP and the reply message is received. 2.2.5. Connectivity Verification and Continuity Checks Two distinct classes of failure management functions are used in OAM protocols, connectivity verification and continuity checks. The distinction between these terms is defined in [MPLS-TP-OAM], and is used similarly in this document. Continuity checks are used to verify the liveness of a connection or a path between two MPs, and are typically sent proactively, though they can be invoked on-demand as well. A connectivity verification function allows an MP to check whether it is connected to a peer MP or not. This function also allows the MP to verify that messages from the peer MP are received through the correct path, thereby verifying not only that the two MPs are connected, but also that they are connected through the expected path. This allows detection of unexpected topology changes. A connectivity verification (CV) protocol typically uses a CV message, followed by a CV reply that is sent back to the originator. A CV function can be applied proactively or on-demand. Connectivity verification and continuity checks are considered complementary mechanisms, and are often used in conjunction with each other. 2.2.6. Failures The terms Failure, Fault, and Defect are used interchangeably in the standards, referring to a malfunction that can be detected by a connectivity or a continuity check. In some standards, such as [IEEE802.1ag], there is no distinction between these terms, while in Mizrahi, et al. Expires July 9, 2013 [Page 15] Internet-Draft Overview of OAM Mechanisms January 2013 other standards each of these terms refers to a different type of malfunction. The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which distinguishes between these terms in [ITU-T-G.806]; The term Fault refers to an inability to perform a required action, e.g., an unsuccessful attempt to deliver a packet. The term Defect refers to an interruption in the normal operation, such as a consecutive period of time where no packets are delivered successfully. The term Failure refers to the termination of the required function. While a Defect typically refers to a limited period of time, a failure refers to a long period of time. 3. OAM Tools 3.1. IP Ping and Traceroute 3.1.1. Ping Ping is a common network diagnosis application for IP networks that uses ICMP. The ICMP Echo request/reply exchange is a connectivity verification function for the Internet Protocol. The originator transmits an ICMP Echo request packet, and the receiver replies with an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 3.1.2. Traceroute Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover the path between an IP source and an IP destination. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending three packets (the number of packets is configurable in most Traceroute implementations), each with an IP Time-To-Live (TTL) value of one to the destination. These packets expire as soon as they reach the first router in the path. That router responds by sending three ICMP Time Exceeded Messages to the Traceroute application. Traceroute now sends another three UDP packets, each with the TTL value of 2. These messages cause the second router to return ICMP messages. This process continues, with ever increasing values for the TTL field, until the packets actually reach the destination. Because no application listens to port 33434 at the destination, the destination returns ICMP Destination Unreachable Messages indicating an unreachable port. This event indicates to the Traceroute application that it is finished. The Traceroute program displays the round-trip delay associated with each of the attempts. Mizrahi, et al. Expires July 9, 2013 [Page 16] Internet-Draft Overview of OAM Mechanisms January 2013 Note that IP routing may be asymmetric. While Traceroute reveals the path between a source and destination, it may not reveal the reverse path. A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These extensions augment the ICMP Destination Unreachable message, and can be used by Traceroute applications. 3.2. Bidirectional Forwarding Detection (BFD) 3.2.1. Overview While multiple OAM mechanisms have been defined for various protocols in the protocol stack, Bidirectional Forwarding Detection [BFD], defined by the IETF BFD working group, is a generic OAM mechanism that can be deployed over various encapsulating protocols, and in various medium types. The IETF has defined variants of the protocol for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3 [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- CV]. BFD includes two main OAM functions, using two types of BFD packets: BFD Control packets, and BFD Echo packets. 3.2.2. BFD Control BFD supports a bidirectional continuity check, using BFD control packets, that are exchanged within a BFD session. BFD sessions operate in one of two modes: o Asynchronous mode (i.e. proactive): in this mode BFD control packets are sent periodically. When the receiver detects that no BFD control packet have been received during a predetermined period of time, a failure is detected. o Demand mode: in this mode, BFD control packets are sent on-demand. Upon need, a system initiates a series of BFD control packets to verify the liveness of the session. BFD control packets are sent independently in each direction. Each of the end-points of the monitored path maintains its own session identification, called a Discriminator, both of which are included in the BFD Control Packets that are exchanged between the end-points. At the time of session establishment, the Discriminators are exchanged between the two-end points. In addition, the transmission (and reception) rate is negotiated between the two end- Mizrahi, et al. Expires July 9, 2013 [Page 17] Internet-Draft Overview of OAM Mechanisms January 2013 points, based on information included in the control packets. These transmission rates may be renegotiated during the session. During normal operation of the session, i.e. no failures are detected, the BFD session is in the Up state. If no BFD Control packets are received during a fixed period of time, called the TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD interval) Detection Time, the session is declared to be Down. The detection time is a function of the negotiated transmission time, and a parameter called Detect Mult. Detect Mult determines the number of missing BFD Control packets that cause the session to be declared as Down. This parameter is included in the BFD Control packet. 3.2.3. BFD Echo A BFD echo packet is sent to a peer system, and is looped back to the originator. The echo function can be used proactively, or on-demand. The BFD echo function has been defined in BFD for IPv4 and IPv6 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for MPLS-TP. 3.3. MPLS OAM The IETF MPLS working group has defined OAM for MPLS LSPs. The requirements and framework of this effort are defined in [MPLS-OAM- FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism defined, in this context, is LSP Ping [LSP-Ping]. LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: o "Ping" mode: In this mode LSP ping is used for end-to-end connectivity verification between two LERs. o "Traceroute" mode: This mode is used for hop-by-hop fault isolation. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity verification) with functionality to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. The traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. Mizrahi, et al. Expires July 9, 2013 [Page 18] Internet-Draft Overview of OAM Mechanisms January 2013 It should be noted that LSP Ping supports unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. The usage of TLVs is typically not easy to perform in hardware, and is thus typically handled by the control plane. LSP Ping supports both asynchronous, as well as, on-demand activation. 3.4. MPLS-TP OAM 3.4.1. Overview The MPLS working group is currently working on defining the OAM toolset that fulfills the requirements for MPLS-TP OAM. The full set of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and include both general requirements for the behavior of the OAM mechanisms and a set of operations that should be supported by the OAM toolset. The set of mechanisms required are further elaborated in [TP-OAM-FW], which describes the general architecture of the OAM system as well as giving overviews of the functionality of the OAM toolset. Some of the basic requirements for the OAM toolset for MPLS-TP are: o MPLS-TP OAM must be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset should rely on the IP routing and forwarding capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. o OAM packets and the user traffic are required to be congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane ones. Inherent in this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. 3.4.2. Generic Associated Channel In order to address the requirement for in-band transmission of MPLS- TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based Mizrahi, et al. Expires July 9, 2013 [Page 19] Internet-Draft Overview of OAM Mechanisms January 2013 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, to address the needs of LSPs as differentiated from PW, the following concepts were defined for [G-ACh]: o An Associated Channel Header (ACH), that uses a format similar to the PW Control Word, is a 4-byte header that is prepended to OAM packets. o A Generic Associated Label (GAL). The GAL is a reserved MPLS label value (13) that indicates that the packet is an ACH packet and the payload follows immediately after the label stack. 3.4.3. MPLS-TP OAM Toolset To address the functionality that is required of the OAM toolset, the MPLS WG conducted an analysis of the existing IETF and ITU-T OAM mechanisms and their ability to fulfill the required functionality. The conclusions of this analysis are documented in [OAM-Analys]. The MPLS working group currently plans to use a mixture of OAM mechanisms that are based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]. Some of the main building blocks of this solution are based on: o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for proactive continuity check and connectivity verification. o LSP Ping as defined in [LSP-Ping] for on-demand connectivity verification. o New protocol packets, using G-ACH, to address different functionality. o Performance measurement protocols that are based on the functionality that is described in [ITU-T-Y1731]. The following sub-sections describe the OAM tools defined for MPLS-TP as described in [TP-OAM-FW]. 3.4.3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification are presented in Section 2.2.5. of this document. As presented there, these tools may be used either proactively or on-demand. When using these tools proactively, they are generally used in tandem. For MPLS-TP there are two distinct tools, the proactive tool is defined in [TP-CC-CV] while the on-demand tool is defined in Mizrahi, et al. Expires July 9, 2013 [Page 20] Internet-Draft Overview of OAM Mechanisms January 2013 [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function should allow the MEPs to monitor the liveness and connectivity of a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. [TP-OAM-FW] highlights, when performing Connectivity Verification, the need for the CC-V messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The proactive tool [TP-CC-CV] is based on extensions to BFD (see Section 3.2. ) with the additional limitation that the transmission and receiving rates are based on configuration by the operator. The on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see Section 3.3. ) for the required behavior of MPLS-TP. 3.4.3.2. Route Tracing [MPLS-TP-OAM] defines that there is a need for functionality that would allow a path end-point to identify the intermediate and end- points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a return path exists. The tool for this is based on the LSP Ping (see Section 3.3. ) functionality and is described in [OnDemand-CV]. 3.4.3.3. Lock Instruct The Lock Instruct function [Lock-Loop] is used to notify a transport path end-point of an administrative need to disable the transport path. This functionality will generally be used in conjunction with some intrusive OAM function, e.g. Performance measurement, Diagnostic testing, to minimize the side-effect on user data traffic. 3.4.3.4. Lock Reporting Lock Reporting is a function used by an end-point of a path to report to its far-end end-point that a lock condition has been affected on the path. 3.4.3.5. Alarm Reporting Alarm Reporting is a function used by an intermediate point of a path, that becomes aware of a fault on the path, to report to the end-points of the path. [TP-OAM-FW] states that this may occur as a result of a defect condition discovered at a server sub-layer. This generates an Alarm Indication Signal (AIS) that continues until the Mizrahi, et al. Expires July 9, 2013 [Page 21] Internet-Draft Overview of OAM Mechanisms January 2013 fault is cleared. The consequent action of this function is detailed in [TP-OAM-FW]. 3.4.3.6. Remote Defect Indication Remote Defect Indication (RDI) is used proactively by a path end- point to report to its peer end-point that a defect is detected on a bidirectional connection between them. [MPLS-TP-OAM] points out that this function may be applied to a unidirectional LSP only if there a return path exists. [TP-OAM-FW] points out that this function is associated with the proactive CC-V function. 3.4.3.7. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow the propagation information from one edge of the network to the other. The information concerns a defect to a client, in the case that the client does not support alarm notification. 3.4.3.8. Packet Loss Measurement (LM) Packet Loss Measurement is a function used to verify the quality of the service. This function indicates the ratio of packets that are not delivered out of all packets that are transmitted by the path source. There are two possible ways of determining this measurement: o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes. TOM: Not just packet sizes. Things like implementation (as I mentioned above with the comment about the accuracy or truthfulness of the data plane processing of OAM packets). Doing very accurate RTT as a simple example, with just IP Pings, is a tricky thing to make work. Also, it is important to mention that the scale in terms of number of packets, number of tests, etc... can and will impact these parameters too. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 3.4.3.9. Packet Delay Measurement (DM) Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: Mizrahi, et al. Expires July 9, 2013 [Page 22] Internet-Draft Overview of OAM Mechanisms January 2013 o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. Similarly to the packet loss measurement this could be performed in either of the two ways outlined above. 3.5. PWE3 OAM 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW-ACH]), and allows transmitting the OAM packets in-band with PW data (using CC Type 1: In-band VCCV). VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. TOM: Might be helpful to note that the static mode was created specifically to handle the MPLS-TP cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul, etc... find this functionality useful too. Mizrahi, et al. Expires July 9, 2013 [Page 23] Internet-Draft Overview of OAM Mechanisms January 2013 3.5.2. PWE3 OAM using G-ACh As mentioned above, VCCV enables OAM for PWs by using a control channel for OAM packets. When PWs are used in MPLS-TP networks, rather than the control channels defined in VCCV, the G-ACh can be used as an alternative control channel. The usage of the G-ACh for PWs is defined in [PW-G-ACh]. 3.6. OWAMP and TWAMP 3.6.1. Overview The IPPM working group in the IETF defines common criteria and metrics for measuring performance of IP traffic ([IPPM-FW]). Some of the key RFCs published by this working group have defined metrics for measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), and packet loss [IPPM-1LM]. Alternative protocols for performance measurement are defined, for example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet OAM [ITU-T-Y1731]. The IPPM working group has defined not only metrics for performance measurement, but also protocols that define how the measurement is carried out. The One-way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] define a method and protocol for measuring delay and packet loss in IP networks. OWAMP [OWAMP] enables measurement of one-way characteristics of IP networks, such as one-way packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP [TWAMP] is a similar protocol that enables measurement of two- way (round trip) characteristics. TWAMP does not require accurate time of day, and, furthermore, allows the use of a simple session reflector, making it an attractive alternative to OWAMP. OWAMP and TWAMP use two separate protocols: a Control plane protocol, and a Test plane protocol. 3.6.2. Control and Test Protocols OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain Mizrahi, et al. Expires July 9, 2013 [Page 24] Internet-Draft Overview of OAM Mechanisms January 2013 sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 3.6.3. OWAMP OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- Receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. Mizrahi, et al. Expires July 9, 2013 [Page 25] Internet-Draft Overview of OAM Mechanisms January 2013 3.6.4. TWAMP TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. 3.7. Summary of OAM Functions Table 3 summarizes the OAM functions that are supported in each of the categories that were analyzed in this section. +-----------+-------+--------+--------+-----------+-------+--------+ | Standard |Continu|Connecti|Path |Defect |Perform|Other | | |ity |vity |Discover|Indications|ance |Function| | |Check |Verifica|y | |Monitor|s | | | |tion | | |ing | | +-----------+-------+--------+--------+-----------+-------+--------+ |IP Ping | |Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |IP | | |Tracerou| | | | |Traceroute | | |te | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |BFD |BFD |BFD | | | | | | |Control|Echo | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS OAM | |"Ping" |"Tracero| | | | |(LSP Ping) | |mode |ute" | | | | | | | |mode | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM |-Diagnos| |OAM | |active |Tracing | Reporting |-DM | tic Tes| | | |or on- | |-Client | | t | | | |demand | | Failure | |-Lock | | | | | | Indication| | | | | | | |-Remote | | | Mizrahi, et al. Expires July 9, 2013 [Page 26] Internet-Draft Overview of OAM Mechanisms January 2013 | | | | | Defect | | | | | | | | Indication| | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |PWE3 OAM |BFD |-BFD |LSP-Ping| | | | | | |-ICMP | | | | | | | | Ping | | | | | | | |-LSP- | | | | | | | | Ping | | | | | + --------- + ----- + ------ + ------ + --------- + ----- + ------ + |OWAMP and | | | | |-Delay | | |TWAMP | | | | | measur| | | | | | | | ement | | | | | | | |-Packet| | | | | | | | loss | | | | | | | | measur| | | | | | | | ement | | +-----------+-------+--------+--------+-----------+-------+--------+ Table 3 Summary of OAM Functions 4. Security Considerations This memo presents an overview of existing OAM mechanisms, and proposes no new OAM mechanisms. Therefore, this document introduces no security considerations. However, the OAM mechanism reviewed in this document can and do present security issues. The reader is encouraged to review the Security Considerations section of each document reference by this memo. 5. IANA Considerations There are no new IANA considerations implied by this document. 6. Acknowledgments The authors gratefully acknowledge Sasha Vainshtein, Carlos Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other members of the OPSAWG mailing list for their helpful comments. This document was prepared using 2-Word-v2.0.template.dot. Mizrahi, et al. Expires July 9, 2013 [Page 27] Internet-Draft Overview of OAM Mechanisms January 2013 7. References 7.1. Normative References [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., Matsushima, S., "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006. [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002. [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM in MPLS Transport Networks", RFC 5860, May 2010. [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006. Mizrahi, et al. Expires July 9, 2013 [Page 28] Internet-Draft Overview of OAM Mechanisms January 2013 [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, JR., "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997. [NetTools] Stine, R., "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1147, April 1990. [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework for IP Performance Metrics", RFC 2330, May 1998. [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and Zekauskas, M., "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and Babiarz, J., "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008. [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. Mizrahi, et al. Expires July 9, 2013 [Page 29] Internet-Draft Overview of OAM Mechanisms January 2013 [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [BFD-Gen] Katz, D., Ward, D., "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, June 2010. [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010. [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC 6371, September 2011. [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile", RFC 6428, November 2011. [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011. [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011. [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011. Mizrahi, et al. Expires July 9, 2013 [Page 30] Internet-Draft Overview of OAM Mechanisms January 2013 [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., Dai, X., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011. [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM)", RFC 6671, November 2012. [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011. [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. 7.2. Informative References [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, D., Mansfield, S., "Guidelines for the use of the OAM acronym in the IETF ", RFC 6291, June 2011. [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool Set for MPLS based Transport Networks", RFC 6669, July 2012. [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", work-in-progress, draft-ietf-mpls- tp-rosetta-stone, July 2012. [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012. [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and Mechanisms for Ethernet-based Networks", July 2011. [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance mechanism for MPLS networks", February 2004. Mizrahi, et al. Expires July 9, 2013 [Page 31] Internet-Draft Overview of OAM Mechanisms January 2013 [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - Local and metropolitan area networks - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", clause 57, December 2008. [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", January 2009. [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, administration and maintenance mechanisms for MPLS-TP networks using the tools defined for MPLS", November 2012. [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)", November 2012. Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com Elisa Bellagamba Ericsson 6 Farogatan St. Stockholm, 164 40 Sweden Mizrahi, et al. Expires July 9, 2013 [Page 32] Internet-Draft Overview of OAM Mechanisms January 2013 Phone: +46 761440785 Email: elisa.bellagamba@ericsson.com Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel Email: wyaacov@gmail.com > draft-ietf-opsawg-oam-overview authors, > > Here is my feedback on this document. > > 1. > Is this document in line with > http://tools.ietf.org/html/draft-ietf-trill-oam-req-04? > * For example, the following definitions could be reused. > Fault: The term Fault refers to an inability to perform a required > action, e.g., an unsuccessful attempt to deliver a packet. > > Defect: The term Defect refers to an interruption in the normal > operation, such that over a period of time no packets are delivered > successfully. > > Failure: The term Failure refers to the termination of the required > function over a longer period of time. Persistence of a defect for a > period of time is interpreted as a failure. > > * For example, on the basic abstract > Abstract > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. > > Abstract (draft-ietf-trill-oam-req-04) > > OAM (Operations, Administration and Maintenance) is a general term > used to identify functions and toolsets to troubleshoot and monitor > networks. This document presents, OAM Requirements applicable to > TRILL. > > So, as an example: does OAM include function? > I advice to review draft-ietf-trill-oam-req-04 > > 2. > draft-ietf-trill-oam is not mentioned, while the abstract mentions: > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. > Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references. > Ok, I see later on: > This document focuses on IETF > documents that have been published as RFCs, while other ongoing OAM- > related work is outside the scope. > Ok, fine then: we don't need a reference to all the drafts. > However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned. > > > 3. > Section 1 > The term OAM in this document refers to Operations, Administration > and Maintenance [OAM-Def ], focusing on the forwarding plane of OAM. > What does it mean "focusing on the forwarding plane of OAM"? > Do you take a subset of the definition for this document? > Btw, I don't see a definition in the terminology section. > In section 2.2.3 > A Maintenance Point (MP) is a functional entity that is defined at a > node in the network, and either initiates or reacts to OAM messages. > Which plane is MP? > > 4. > Section 1, Introduction > "Hence, management aspects are outside the scope of this document." > I don't understand which management aspects we speak about here. > 5. > Clarifying question regarding 1.2 > If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, > control plane, or management plane? > Note that I found later on in the draft: > OWAMP and TWAMP use two separate protocols: a Control plane protocol, > and a Test plane protocol. > Interestingly enough, after reading the document, I reviewed > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and > saw the same feedback from Stewart Bryant: > > Provide a clear view of OAM functionality and its relationship > to various "planes" of networking (data plane, control plane, > management plane). In particular, the importance of > fate-sharing of OAM and user traffic flows in packet networks > should be explained. > > 6. > I see a multiplication of "plane" terms in the IETF document, and in this document in particular. > I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane. > Way too many. > Please be consistent > 7. > Table 1 summarizes the IETF OAM related RFCs discussed in this > document. > > Table 2 summarizes the OAM standards mentioned in this document. > > You need to change the Table 2 description. Do you want to say something along the lines of: > Table 2 summarizes the OAM standards specified by other Standard Development Organization > (SDO) than the IETF, along with IETF references where applicable. > > > 8. > Section 2.2.1 > For a formal definition of each term, refer to the references at the end of > this document. > Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references. > You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms, > just read first all references!" > > 9. > You specify some terms and some OAM categories, > 2.2.2 . OAM Maintenance Entities ..........................13 > 2.2.3 . OAM Maintenance Points ............................14 > 2.2.4 . Proactive and On-demand activation ................15 > 2.2.5 . Connectivity Verification and Continuity Checks ...15 > 2.2.6 . Failures ..........................................15 > ... but you don't use them in the section 3 > > Just_one_example with section 3.2.2 > - > o Demand mode: in this mode, BFD control packets are sent on-demand. > Upon need, a system initiates a series of BFD control packets to > verify the liveness of the session > Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5 > - OLD: > Each of the end-points of the monitored path maintains its own > session identification > NEW: > Each of the MEP maintains its own session identification > OR NEW (actually I don't know) > Each of the MP maintains its own session identification > - OLD > A BFD echo packet is sent to a peer system > Peer system = MEP, MP, or something else? > - etc... > > 10. > This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience". > When we did RFC 6632, which is the companion document, we hadhttp://tools.ietf.org/html/rfc6632#section-1.1 > > The target audience of the document is, on the one hand, IETF working > groups, which aim to select appropriate standard management protocols > and data models to address their needs concerning network management. > On the other hand, the document can be used as an overview and > guideline by non-IETF Standards Development Organizations (SDOs) > planning to use IETF management technologies and data models for the > realization of management applications. The document can also be > used to initiate a discussion between the bodies with the goal to > gather new requirements and to detect possible gaps. Finally, this > document is directed to all interested parties that seek to get an > overview of the current set of the IETF network management protocols > such as network administrators or newcomers to the IETF. > > You should have something similar. > > > 11. > Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense > Alternative protocols for performance measurement are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM ], [TP-LM-DM ]), and in Ethernet > OAM [ITU-T-Y1731 ]. > > > My conclusions: this document still needs some work > > Regards, Benoit > >> The IESG has received a request from the Operations and Management Area >> Working Group WG (opsawg) to consider the following document: >> - 'An Overview of Operations, Administration, and Maintenance (OAM) >> Mechanisms' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be >> sent toiesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> Operations, Administration, and Maintenance (OAM) is a general term >> that refers to a toolset that can be used for fault detection and >> isolation, and for performance measurement. OAM mechanisms have been >> defined for various layers in the protocol stack, and are used with a >> variety of protocols. >> >> This document presents an overview of the OAM mechanisms that have >> been defined and are currently being defined by the IETF. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> > --------------080205090701090609030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here is Tom Nadeau's feedback, forwarded with permission:

Regards, Benoit

==============

Some general comments:

  1. I did not find any discussion around use of configuration within OAM mechanisms. This is clearly something that is happening in groups like PWE3 and CCAMP. The motivation for this should be explained and documented to at least guide these efforts.
2. There is no real discussion around the security aspects of these tools. Should there be?

3. While the document provides a nice taxonomy of various OAM tools, it does not really discuss the techniques for using them. I do not expect anything in detail, but it is not obvious that many of these tools can be orchestrated to form a "toolset" that can be used to do multi-layer OAM functions for services such as carrier Ethernet over VPLS over MPLS, for example.

4. It might be useful to at least mention in the performance metrics section, a discussion around the accuracy of these tools and how it depends on scale, implementation and network configurations.


My detailed comments inline starting with TOM:

--Tom






Expires: July 2013                                Nokia Siemens Networks
                                                           E. Bellagamba
                                                                Ericsson
                                                           Y. Weingarten

                                                         January 9, 2013

                              An Overview of
        Operations, Administration, and Maintenance (OAM) Mechanisms
                   draft-ietf-opsawg-oam-overview-08.txt


Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 9, 2013.



Mizrahi, et al.         Expires July 9, 2013                  [Page 1]
Internet-Draft       Overview of OAM Mechanisms           January 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents


   1. Introduction ................................................. 3
      1.1. The Building Blocks of OAM .............................. 3
      1.2. Forwarding Plane vs. Management Plane ................... 4
      1.3. The OAM toolsets ........................................ 4
      1.4. IETF OAM Documents ...................................... 6
      1.5. Non-IETF OAM Documents ................................. 10
   2. Basic Terminology ........................................... 12
      2.1. Abbreviations .......................................... 12
      2.2. Terminology used in OAM Standards ...................... 13
         2.2.1. General Terms ..................................... 13
         2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
         2.2.4. Proactive and On-demand activation ................ 15
         2.2.5. Connectivity Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
   3. OAM Tools ................................................... 16
      3.1. IP Ping and Traceroute ................................. 16
         3.1.1. Ping .............................................. 16
         3.1.2. Traceroute......................................... 16
      3.2. Bidirectional Forwarding Detection (BFD) ............... 17
         3.2.1. Overview .......................................... 17
         3.2.2. BFD Control ....................................... 17
         3.2.3. BFD Echo .......................................... 18
      3.3. MPLS OAM ............................................... 18
      3.4. MPLS-TP OAM ............................................ 19
         3.4.1. Overview .......................................... 19
         3.4.2. Generic Associated Channel ........................ 19
         3.4.3. MPLS-TP OAM Toolset ............................... 20
            3.4.3.1. Continuity Check and Connectivity Verification 20


Mizrahi, et al.         Expires July 9, 2013                  [Page 2]
Internet-Draft       Overview of OAM Mechanisms           January 2013


            3.4.3.2. Route Tracing ................................ 21
            3.4.3.3. Lock Instruct ................................ 21
            3.4.3.4. Lock Reporting ............................... 21
            3.4.3.5. Alarm Reporting .............................. 21
            3.4.3.6. Remote Defect Indication ..................... 22
            3.4.3.7. Client Failure Indication .................... 22
            3.4.3.8. Packet Loss Measurement (LM) ................. 22
            3.4.3.9. Packet Delay Measurement (DM) ................ 22
      3.5. PWE3 OAM ............................................... 23
         3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification
         (VCCV) ................................................... 23
         3.5.2. PWE3 OAM using G-ACh .............................. 24
      3.6. OWAMP and TWAMP......................................... 24
         3.6.1. Overview .......................................... 24
         3.6.2. Control and Test Protocols ........................ 24
         3.6.3. OWAMP ............................................. 25
         3.6.4. TWAMP ............................................. 26
      3.7. Summary of OAM Functions ............................... 26
   4. Security Considerations ..................................... 27
   5. IANA Considerations ......................................... 27
   6. Acknowledgments ............................................. 27
   7. References .................................................. 28
      7.1. Normative References ................................... 28
      7.2. Informative References ................................. 31

1. Introduction

   OAM is a general term that refers to a toolset for detecting,
   isolating and reporting connection failures and performance
   degradation.

   This document summarizes the OAM tools and mechanisms defined in the
   IETF.

   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
   Hence, management aspects are outside the scope of this document.

TOM: This is a curious sentence to me since to me, OAM is management, or a subset of it.   Also, if you look at the referenced documents, there are many indirect references to MIBs, Netconf, etc… making this sentence further confusing. It might be helpful to explain more clearly that the authors here intended to not cover those things explicitly rather than grouping them arbitrarily under the definition of "management aspects"  Further, to clarify, it might be useful to expand on what "forwarding plane" is here just to be clear.   That is, is this "in band" or "out-of band" or both? Some of the tools referred to here also are part of the control AND data planes. 

1.1. The Building Blocks of OAM

   An OAM protocol is run in the context of a Maintenance Domain,
   consisting of two or more nodes that run the OAM protocol, referred
   to as Maintenance Points (MP).

   This subsection provides a brief summary of the common tools used by
   OAM protocols. An OAM protocol typically supports one or more of the
   tools described below.


Mizrahi, et al.         Expires July 9, 2013                  [Page 3]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   o Continuity Checking (CC):
      Used for verifying the liveness of a connection between two MPs.

   o Connectivity Verification (CV):
      Allows an MP to check whether it is connected to a peer MP, and to
      verify that messages from the peer MP are received through the
      expected path.

   o Path Discovery / Fault Localization:
      An MP uses this mechanism to trace the route to a peer MP, i.e.,
      to identify the nodes along the path to the peer MP. When a
      connection fails, this mechanism also allows the MP to detect the
      location of the failure.

TOM: The definition calls this "path discovery" but then talks about tracing routes. A better way of describing this in the paragraph would be that there I a use of path tracing in order to discover (or re-discover) paths that have been changed, created or destroyed.  


   o Performance Monitoring:
      Consists of 3 main functions

        o Loss Measurement (LM) - monitors the packet loss rate of a
          connection.

        o Delay Measurement (DM) - monitors the delay and delay
          variation between MPs.

        o Throughput measurement - monitors the throughput of a
          connection.

TOM: Along with the discussion above around path trace/discovery, it is imperative that paths be discovered (one way or another) in order to successfully d performance monitoring on those paths.

1.2. Forwarding Plane vs. Management Plane

   While the OAM tools may, and quite often do, work in conjunction with
   a control-plane or management plane, they are usually defined to be
   independent of the control-plane.  The OAM tools communicate with the
   management plane to raise alarms, and often the on-demand tools may
   be activated by the management, e.g. to locate and localize problems.

   The considerations of the control-plane maintenance tools or the
   functionality of the management-plane are out of scope for this
   document, which will concentrate on presenting the forwarding-plane
   tools that are used for OAM.

TOM: What about the data plane? For example, the GACH OAM type is such an example. VCCV also operates within the data plane after its configuration capabilities have been signaled.  It should also be mentioned that it is imperative that when required, OAM tools are capable of testing the actual data plane in as much accuracy as possible, but that they all should note how accurate.   Not all OAM tools are created equal.


1.3. The OAM toolsets

   This memo provides an overview of the different sets of OAM
   mechanisms defined by the IETF. It is intended for those with little
   or no familiarity with the described mechanisms. The set of OAM
   mechanisms described in this memo are applicable to IP unicast, MPLS,
   pseudowires, and MPLS for the transport environment (MPLS-TP). While
   OAM mechanisms that are applicable to other technologies exist, they


Mizrahi, et al.         Expires July 9, 2013                  [Page 4]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   are beyond the scope of this memo. This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.

   The IETF has defined OAM protocols and mechanisms in several
   different fronts:

   o IP Ping and Traceroute:
      Ping is a very simple and common application for failure diagnosis

TOM: I am not sure the term "common" is necessary.

      that uses ICMP Echo requests, as defined in [ICMPv4], and
      [ICMPv6].
      Traceroute ([TCPIP-Tools], [NetTools]) is an application that
      allows users to trace the path between an IP source and an IP
      destination, i.e., to identify the nodes along the path.

   o BFD:
      Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a
      framework for a lightweight generic OAM mechanism.  The intention
      is to define a base mechanism that can be used with various
      encapsulation types, network environments, and in various medium
      types.

   o MPLS OAM:
      MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP-
      Ping], is an OAM mechanism for point to point MPLS LSPs. It
      includes two main functions: Ping and Traceroute.

   o MPLS-TP OAM:
      MPLS-TP OAM is defined in a set of RFCs. The OAM requirements for
      MPLS Transport Profile (MPLS-TP) are defined in [MPLS-TP-OAM].
      Each of the tools in the OAM toolset is defined in its own RFC, as
      specified in Section 1.4.

   o PWE3 OAM:
      The PWE3 OAM architecture defines control channels that support
      the use of existing IETF OAM tools to be used for a pseudowire
      (PW).  The control channels that are defined in [VCCV] and [PW-G-
      ACH] may be used in conjunction with ICMP Ping, LSP Ping, and BFD
      to perform CC and CV functionality.  In addition the channels
      support use of any of the MPLS-TP based OAM tools for completing
      their respective OAM functionality for a PW.

   o OWAMP and TWAMP:
      The One Way Active Measurement Protocol (OWAMP) and the Two Way
      Active Measurement Protocols (TWAMP) are two protocols defined in
      the IP Performance Metrics (IPPM) working group in the IETF. These
      protocols allow delay and packet loss measurement in IP networks.


Mizrahi, et al.         Expires July 9, 2013                  [Page 5]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   This document summarizes the OAM mechanisms defined by the IETF. We
   first present a comparison of the terminology used in various OAM
   standards, and then summarize the OAM functions that each OAM
   standard provides.

1.4. IETF OAM Documents

   Table 1 summarizes the IETF OAM related RFCs discussed in this
   document.

   The table includes a "Type" column, specifying the nature of each of
   the listed documents:

   o Tool: documents that define an OAM tool or mechanism.

   o Prof.: documents that define a profile or a variant for an OAM
      tool that is defined in other documents.

   o Inf.: documents that define an infrastructure that is used by OAM
      tools.

   o Misc.: other OAM related documents, e.g., OAM requirement and
      framework documents.

   +-----------+--------------------------------------+-----+----------+
   |           | Title                                |Type | RFC      |
   +-----------+--------------------------------------+-----+----------+
   |IP Ping and| Internet Control Message Protocol    |Tool | RFC 792  |
   |Traceroute | [ICMPv4]                             |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Internet Control Message Protocol    |Tool | RFC 4443 |
   |           | (ICMPv6) for the Internet Protocol   |     |          |
   |           | Version 6 (IPv6) Specification       |     |          |
   |           | [ICMPv6]                             |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Primer On Internet and TCP/IP      |Tool | RFC 2151 |
   |           | Tools and Utilities [TCPIP-Tools]    |     |          |
   |           +--------------------------------------+-----+----------+
   |           | FYI on a Network Management Tool     |Tool | RFC 1147 |
   |           | Catalog: Tools for Monitoring and    |     |          |
   |           | Debugging TCP/IP Internets and       |     |          |
   |           | Interconnected Devices [NetTools]    |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Extended ICMP to Support Multi-Part  |Tool | RFC 4884 |


Mizrahi, et al.         Expires July 9, 2013                  [Page 6]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           | Messages [ICMP-MP]                   |     |          |
   |           +--------------------------------------+-----+----------+
   |           | ICMP Extensions for Multiprotocol    |Tool | RFC 4950 |
   |           | Label Switching [ICMP-Ext]           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Extending ICMP for Interface and     |Tool | RFC 5837 |
   |           | Next-Hop Identification [ICMP-Int]   |     |          |
   +-----------+--------------------------------------+-----+----------+
   |BFD        | Bidirectional Forwarding Detection   |Tool | RFC 5880 |
   |           | [BFD]                                |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5881 |
   |           | (BFD) for IPv4 and IPv6 (Single Hop) |     |          |
   |           | [BFD-IP]                             |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Generic Application of Bidirectional |Misc.| RFC 5882 |
   |           | Forwarding Detection [BFD-Gen]       |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5883 |
   |           | (BFD) for Multihop Paths [BFD-Multi] |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5884 |
   |           | for MPLS Label Switched Paths (LSPs) |     |          |
   |           | [BFD-LSP]                            |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |     |          |
   |           | Connectivity Verification (VCCV)     |     |          |
   |           | [BFD-VCCV]                           |     |          |
   +-----------+--------------------------------------+-----+----------+
   |MPLS OAM   | Operations and Management (OAM)      |Misc.| RFC 4377 |
   |           | Requirements for Multi-Protocol Label|     |          |
   |           | Switched (MPLS) Networks [MPLS-OAM]  |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Framework for Multi-Protocol       |Misc.| RFC 4378 |
   |           | Label Switching (MPLS) Operations    |     |          |
   |           | and Management (OAM) [MPLS-OAM-FW]   |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Detecting Multi-Protocol Label       |Tool | RFC 4379 |
   |           | Switched (MPLS) Data Plane Failures  |     |          |
   |           | [LSP-Ping]                           |     |          |


Mizrahi, et al.         Expires July 9, 2013                  [Page 7]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           +--------------------------------------+-----+----------+
   |           | Operations and Management (OAM)      |Misc.| RFC 4687 |
   |           | Requirements for Point-to-Multipoint |     |          |
   |           | MPLS Networks [MPLS-P2MP]            |     |          |
   +-----------+--------------------------------------+-----+----------+
   |MPLS-TP    | Requirements for OAM in MPLS-TP      |Misc.| RFC 5860 |
   |OAM        | [MPLS-TP-OAM]                        |     |          |
   |           +--------------------------------------+-----+----------+
   |           | MPLS Generic Associated Channel      |Inf. | RFC 5586 |
   |           | [G-ACh]                              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | MPLS-TP OAM Framework                |Misc.| RFC 6371 |
   |           | [TP-OAM-FW]                          |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Proactive Connectivity Verification, |Tool | RFC 6428 |
   |           | Continuity Check, and Remote Defect  |     |          |
   |           | Indication for the MPLS Transport    |     |          |
   |           | Profile [TP-CC-CV]                   |     |          |
   |           +--------------------------------------+-----+----------+
   |           | MPLS On-Demand Connectivity          |Tool | RFC 6426 |
   |           | Verification and Route Tracing       |     |          |
   |           | [OnDemand-CV]                        |     |          |
   |           +--------------------------------------+-----+----------+
   |           | MPLS Fault Management Operations,    |Tool | RFC 6427 |
   |           | Administration, and Maintenance (OAM)|     |          |
   |           | [TP-Fault]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 |
   |           | and Loopback Functions [Lock-Loop]   |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Packet Loss and Delay Measurement for|Tool | RFC 6374 |
   |           | MPLS Networks [MPLS-LM-DM]           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Packet Loss and Delay Measurement  |Prof.| RFC 6375 |
   |           | Profile for MPLS-Based Transport     |     |          |
   |           | Networks [TP-LM-DM]                  |     |          |
   +-----------+--------------------------------------+-----+----------+
   |PWE3 OAM   | Pseudowire Virtual Circuit           |Inf. | RFC 5085 |
   |           | Connectivity Verification (VCCV):    |     |          |
   |           | A Control Channel for Pseudowires    |     |          |
   |           | [VCCV]                               |     |          |


Mizrahi, et al.         Expires July 9, 2013                  [Page 8]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |     |          |
   |           | Connectivity Verification (VCCV)     |     |          |
   |           | [BFD-VCCV]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Using the Generic Associated Channel |Inf. | RFC 6423 |
   |           | Label for Pseudowire in the MPLS     |     |          |
   |           | Transport Profile (MPLS-TP)          |     |          |
   |           | [PW-G-ACh]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Pseudowire (PW) Operations,          |Misc.| RFC 6310 |
   |           | Administration, and Maintenance (OAM)|     |          |
   |           | Message Mapping [PW-Map]             |     |          |
   +-----------+--------------------------------------+-----+----------+
   |OWAMP and  | A One-way Active Measurement Protocol|Tool | RFC 4656 |
   |TWAMP      | [OWAMP]                              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Two-Way Active Measurement Protocol|Tool | RFC 5357 |
   |           | [TWAMP]                              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Framework for IP Performance Metrics |Misc.| RFC 2330 |
   |           | [IPPM-FW]                            |     |          |
   |           +--------------------------------------+-----+----------+
   |           | IPPM Metrics for Measuring           |Misc.| RFC 2678 |
   |           | Connectivity [IPPM-Con]              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A One-way Delay Metric for IPPM      |Misc.| RFC 2679 |
   |           | [IPPM-1DM]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 |
   |           | [IPPM-1LM]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Round-trip Delay Metric for IPPM   |Misc.| RFC 2681 |
   |           | [IPPM-2DM]                           |     |          |
   +-----------+--------------------------------------+-----+----------+
                 Table 1 Summary of IETF OAM Related RFCs







Mizrahi, et al.         Expires July 9, 2013                  [Page 9]
Internet-Draft       Overview of OAM Mechanisms           January 2013


1.5. Non-IETF OAM Documents

   In addition to the OAM mechanisms defined by the IETF, the IEEE and
   ITU-T have also defined various OAM mechanisms that focus on
   Ethernet, and various other transport network environments. These
   various mechanisms, defined by the three standard organizations, are
   often tightly coupled, and have had a mutual effect on each other.
   The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs,
   [ITU-T-Y1711] and [LSP-Ping]. The following OAM standards by the IEEE
   and ITU-T are to some extent linked to IETF OAM mechanisms listed
   above and are mentioned here only as reference material:

   o OAM mechanisms for Ethernet based networks have been defined by
      both the ITU-T in [ITU-T-Y1731], and by the IEEE in [IEEE802.1ag].
      The IEEE 802.3 standard defines OAM for one-hop Ethernet links
      [IEEE802.3ah].

   o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and
      MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].

   Table 2 summarizes the OAM standards mentioned in this document. This
   document focuses on IETF OAM standards, but these non-IETF standards
   are referenced where relevant.

   +-----------+--------------------------------------+---------------+
   |           | Title                                |Standard/Draft |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operation & Maintenance mechanism    | ITU-T Y.1711  |
   |MPLS OAM   | for MPLS networks [ITU-T-Y1711]      |               |
   |           +--------------------------------------+---------------+
   |           | Assignment of the 'OAM Alert Label'  | RFC 3429      |
   |           | for Multiprotocol Label Switching    |               |
   |           | Architecture (MPLS) Operation and    |               |
   |           | Maintenance (OAM) Functions          |               |
   |           | [OAM-Label]                          |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T Y.1711.                    |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operations, administration and       |ITU-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP   |               |


Mizrahi, et al.         Expires July 9, 2013                 [Page 10]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           | networks using the tools defined for |               |
   |           | MPLS [ITU-G8113.2]                   |               |
   |           |                                      |               |
   |           |  Note: this document describes the   |               |
   |           |  OAM toolset defined by the IETF for |               |
   |           |  MPLS-TP, whereas ITU-T G.8113.1     |               |
   |           |  describes the OAM toolset defined   |               |
   |           |  by the ITU-T.                       |               |
   |           +--------------------------------------+---------------+
   |           | Operations, Administration and       |ITU-T G.8113.1 |
   |           | Maintenance mechanism for MPLS-TP in |               |
   |           | Packet Transport Network (PTN)       |               |
   |           +--------------------------------------+---------------+
   |           | Allocation of a Generic Associated   | RFC 6671      |
   |           | Channel Type for ITU-T MPLS Transport|               |
   |           | Profile Operation, Maintenance, and  |               |
   |           | Administration (MPLS-TP OAM)         |               |
   |           | [ITU-T-CT]                           |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T G.8113.1.                  |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | OAM Functions and Mechanisms for     |[ITU-T-Y1731]  |
   |Ethernet   | Ethernet-based Networks              |               |
   |OAM        |                                      |               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Connectivity Fault Management        | IEEE 802.1ag  |
   |CFM        | [IEEE802.1ag]                        |               |
   |           |                                      |               |
   |           |  Note: CFM was originally published  |               |
   |           |  as IEEE 802.1ag, but is now         |               |
   |           |  incorporated in the 802.1Q standard.|               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Media Access Control Parameters,     | IEEE 802.3ah  |
   |802.3      | Physical Layers, and Management      |               |
   |link level | Parameters for Subscriber Access     |               |
   |OAM        | Networks [IEEE802.3ah]               |               |
   |           |                                      |               |


Mizrahi, et al.         Expires July 9, 2013                 [Page 11]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           |  Note: link level OAM was originally |               |
   |           |  defined in IEEE 802.3ah, and is now |               |
   |           |  incorporated in the 802.3 standard. |               |
   +-----------+--------------------------------------+---------------+
         Table 2 Non-IETF OAM Standards Mentioned in this Document

2. Basic Terminology

2.1. Abbreviations

   ACH    Associated Channel Header

   AIS    Alarm Indication Signal

   BFD    Bidirectional Forwarding Detection

   CC     Continuity Check

   CV     Connectivity Verification

   DM     Delay Measurement

   FEC    Forwarding Equivalence Class

   GAL    Generic Associated Label

   ICMP   Internet Control Message Protocol

   LDP    Label Distribution Protocol

   LM     Loss Measurement

   LSP    Label Switched Path

   ME     Maintenance Entity

   MEG    Maintenance Entity Group

   MEP    MEG End Point

   MIP    MEG Intermediate Point

   MP     Maintenance Point

   MPLS   Multiprotocol Label Switching



Mizrahi, et al.         Expires July 9, 2013                 [Page 12]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   MPLS-TP MPLS Transport Profile

   MTU    Maximum Transmission Unit

   OAM    Operations, Administration, and Maintenance

   PW     Pseudowire

   PWE3   Pseudowire Emulation Edge-to-Edge

   RDI    Remote Defect Indication

   TTL    Time To Live

   VCCV   Virtual Circuit Connectivity Verification


TOM: Why is this section not at the top of this document, as is customary for RFCs?  


2.2. Terminology used in OAM Standards

2.2.1. General Terms

   A wide variety of terms is used in various OAM standards. Each of the
   OAM standards listed in the reference section includes a section that
   defines terms relevant to that tool. A thesaurus of terminology for
   MPLS-TP terms is presented in [TP-Term], and provides a good summary
   of some of the OAM related terminology.

   This section presents a comparison of the terms used in various OAM
   standards, without fully quoting the definition of each term. For a
   formal definition of each term, refer to the references at the end of
   this document.

2.2.2. OAM Maintenance Entities

   OAM tools are designed to monitor and manage a Maintenance Entity
   (ME).  An ME, as defined in [TP-OAM-FW], defines a relationship
   between two points of a transport path to which maintenance and
   monitoring operations apply.

   The following related terms are also quoted from [TP-OAM-FW]:

   o MEP: The two points that define a maintenance entity.

   o MEG: The collection of one or more MEs that belongs to the same
      transport path and that are maintained and monitored as a group
      are known as a Maintenance Entity Group (MEG).




Mizrahi, et al.         Expires July 9, 2013                 [Page 13]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   o MIP: In between MEPs, there are zero or more intermediate points,
      called Maintenance Entity Group Intermediate Points (MIPs).

   A pair of MEPs engaged in an ME are connected by a communication
   link, which may be one of several types of connection, e.g. a single
   physical connection, a set of physical connections, or a virtual link
   such as an MPLS LSP.

   The term Maintenance Entity (ME) is used in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology ([TP-OAM-
   FW]). Various terms are used to refer to an ME. For example, BFD does
   not explicitly use a term that is equivalent to ME, but rather uses
   the term "session", referring to the relationship between two nodes
   using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology
   simply uses the term "LSP" in this context.

   MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG)
   in [TP-OAM-FW], similar to the terms defined by ITU-T.  A MEG allows
   the monitoring of a compound set of MEs, for example when monitoring
   a p2mp MEG that is considered to be the set of MEs between the root
   and each individual destination MEP.

2.2.3. OAM Maintenance Points

   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
   A Maintenance End Point (MEP) is one of the end points of an ME, and
   can initiate OAM messages and respond to them. A Maintenance
   Intermediate Point (MIP) is an intermediate point between two MEPs,
   that does not generally initiate OAM frames (one exception to this is
   the use of AIS notifications), but is able to respond to OAM frames
   that are destined to it. A MIP in MPLS-TP identifies OAM packets
   destined to it by the value of the TTL field in the OAM packet. The
   term Maintenance Point is a general term for MEPs and MIPs.

   The 802.1ag defines a finer distinction between Up MPs and Down MPs.
   An MP is a bridge interface, that is monitored by an OAM protocol
   either in the direction facing the network, or in the direction
   facing the bridge. A Down MP is an MP that receives OAM packets from,
   and transmits them to the direction of the network. An Up MP receives
   OAM packets from, and transmits them to the direction of the bridging
   entity.

   MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of
   the MP - either at the ingress, egress, or forwarding function of the
   node (Down / Up MPs).  This placement is important for localization
   of a connection failure.


Mizrahi, et al.         Expires July 9, 2013                 [Page 14]
Internet-Draft       Overview of OAM Mechanisms           January 2013


2.2.4. Proactive and On-demand activation

   The different OAM tools may be used in one of two basic types of
   activation:

   o Proactive activation - indicates that the tool is activated on a
      continual basis periodically, where messages are sent between the
      two MEPs, and errors are detected when a certain number of
      expected messages are not received.

   o On-demand activation - indicates that the tool is activated
      "manually" to detect a specific anomaly.  In this activation a
      small number of OAM messages are sent by a MEP and the reply
      message is received.

2.2.5. Connectivity Verification and Continuity Checks

   Two distinct classes of failure management functions are used in OAM
   protocols, connectivity verification and continuity checks. The
   distinction between these terms is defined in [MPLS-TP-OAM], and is
   used similarly in this document.

   Continuity checks are used to verify the liveness of a connection or
   a path between two MPs, and are typically sent proactively, though
   they can be invoked on-demand as well.

   A connectivity verification function allows an MP to check whether it
   is connected to a peer MP or not. This function also allows the MP to
   verify that messages from the peer MP are received through the
   correct path, thereby verifying not only that the two MPs are
   connected, but also that they are connected through the expected
   path. This allows detection of unexpected topology changes. A
   connectivity verification (CV) protocol typically uses a CV message,
   followed by a CV reply that is sent back to the originator. A CV
   function can be applied proactively or on-demand.

   Connectivity verification and continuity checks are considered
   complementary mechanisms, and are often used in conjunction with each
   other.

2.2.6. Failures

   The terms Failure, Fault, and Defect are used interchangeably in the
   standards, referring to a malfunction that can be detected by a
   connectivity or a continuity check. In some standards, such as
   [IEEE802.1ag], there is no distinction between these terms, while in



Mizrahi, et al.         Expires July 9, 2013                 [Page 15]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   other standards each of these terms refers to a different type of
   malfunction.

   The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which
   distinguishes between these terms in [ITU-T-G.806]; The term Fault
   refers to an inability to perform a required action, e.g., an
   unsuccessful attempt to deliver a packet. The term Defect refers to
   an interruption in the normal operation, such as a consecutive period
   of time where no packets are delivered successfully. The term Failure
   refers to the termination of the required function. While a Defect
   typically refers to a limited period of time, a failure refers to a
   long period of time.

3. OAM Tools

3.1. IP Ping and Traceroute

3.1.1. Ping

   Ping is a common network diagnosis application for IP networks that
   uses ICMP. The ICMP Echo request/reply exchange is a connectivity
   verification function for the Internet Protocol. The originator
   transmits an ICMP Echo request packet, and the receiver replies with
   an Echo reply. ICMP ping is defined in two variants, [ICMPv4] is used
   for IPv4, and [ICMPv6] is used for IPv6.

3.1.2. Traceroute

   Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
   users to discover the path between an IP source and an IP
   destination. Traceroute sends a sequence of UDP packets to UDP port
   33434 at the destination. By default, Traceroute begins by sending
   three packets (the number of packets is configurable in most
   Traceroute implementations), each with an IP Time-To-Live (TTL) value
   of one to the destination. These packets expire as soon as they reach
   the first router in the path. That router responds by sending three
   ICMP Time Exceeded Messages to the Traceroute application. Traceroute
   now sends another three UDP packets, each with the TTL value of 2.
   These messages cause the second router to return ICMP messages. This
   process continues, with ever increasing values for the TTL field,
   until the packets actually reach the destination. Because no
   application listens to port 33434 at the destination, the destination
   returns ICMP Destination Unreachable Messages indicating an
   unreachable port. This event indicates to the Traceroute application
   that it is finished.  The Traceroute program displays the round-trip
   delay associated with each of the attempts.



Mizrahi, et al.         Expires July 9, 2013                 [Page 16]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   Note that IP routing may be asymmetric. While Traceroute reveals the
   path between a source and destination, it may not reveal the reverse
   path.

   A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been
   defined in the context of Traceroute. These extensions augment the
   ICMP Destination Unreachable message, and can be used by Traceroute
   applications.

3.2. Bidirectional Forwarding Detection (BFD)

3.2.1. Overview

   While multiple OAM mechanisms have been defined for various protocols
   in the protocol stack, Bidirectional Forwarding Detection [BFD],
   defined by the IETF BFD working group, is a generic OAM mechanism
   that can be deployed over various encapsulating protocols, and in
   various medium types. The IETF has defined variants of the protocol
   for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3
   [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC-
   CV].

   BFD includes two main OAM functions, using two types of BFD packets:
   BFD Control packets, and BFD Echo packets.

3.2.2. BFD Control

   BFD supports a bidirectional continuity check, using BFD control
   packets, that are exchanged within a BFD session. BFD sessions
   operate in one of two modes:

   o Asynchronous mode (i.e. proactive): in this mode BFD control
      packets are sent periodically. When the receiver detects that no
      BFD control packet have been received during a predetermined
      period of time, a failure is detected.

   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session. BFD control packets are sent
      independently in each direction.

   Each of the end-points of the monitored path maintains its own
   session identification, called a Discriminator, both of which are
   included in the BFD Control Packets that are exchanged between the
   end-points.  At the time of session establishment, the Discriminators
   are exchanged between the two-end points.  In addition, the
   transmission (and reception) rate is negotiated between the two end-


Mizrahi, et al.         Expires July 9, 2013                 [Page 17]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   points, based on information included in the control packets.  These
   transmission rates may be renegotiated during the session.

   During normal operation of the session, i.e. no failures are
   detected, the BFD session is in the Up state.  If no BFD Control
   packets are received during a fixed period of time, called the

TOM: Fixed, pre-configured or negotiated period of time (i.e.: BFD interval)

   Detection Time, the session is declared to be Down. The detection
   time is a function of the negotiated transmission time, and a
   parameter called Detect Mult. Detect Mult determines the number of
   missing BFD Control packets that cause the session to be declared as
   Down. This parameter is included in the BFD Control packet.

3.2.3. BFD Echo

   A BFD echo packet is sent to a peer system, and is looped back to the
   originator. The echo function can be used proactively, or on-demand.

   The BFD echo function has been defined in BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for
   MPLS-TP.

3.3. MPLS OAM

   The IETF MPLS working group has defined OAM for MPLS LSPs. The
   requirements and framework of this effort are defined in [MPLS-OAM-
   FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism
   defined, in this context, is LSP Ping [LSP-Ping].

   LSP Ping is based on ICMP Ping and just like its predecessor may be
   used in one of two modes:

   o "Ping" mode: In this mode LSP ping is used for end-to-end
      connectivity verification between two LERs.

   o "Traceroute" mode: This mode is used for hop-by-hop fault
      isolation.

   LSP Ping extends the basic ICMP Ping operation (of data-plane
   connectivity verification) with functionality to verify data-plane
   vs. control-plane consistency for a Forwarding Equivalence Class
   (FEC) and also Maximum Transmission Unit (MTU) problems. The
   traceroute functionality may be used to isolate and localize the MPLS
   faults, using the Time-to-live (TTL) indicator to incrementally
   identify the sub-path of the LSP that is successfully traversed
   before the faulty link or node.




Mizrahi, et al.         Expires July 9, 2013                 [Page 18]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   It should be noted that LSP Ping supports unique identification of
   the LSP within an addressing domain. The identification is checked
   using the full FEC identification. LSP Ping is easily extensible to
   include additional information needed to support new functionality,
   by use of Type-Length-Value (TLV) constructs. The usage of TLVs is
   typically not easy to perform in hardware, and is thus typically
   handled by the control plane.

   LSP Ping supports both asynchronous, as well as, on-demand
   activation.

3.4. MPLS-TP OAM

3.4.1. Overview

   The MPLS working group is currently working on defining the OAM
   toolset that fulfills the requirements for MPLS-TP OAM. The full set
   of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and
   include both general requirements for the behavior of the OAM
   mechanisms and a set of operations that should be supported by the
   OAM toolset.  The set of mechanisms required are further elaborated
   in [TP-OAM-FW], which describes the general architecture of the OAM
   system as well as giving overviews of the functionality of the OAM
   toolset.

   Some of the basic requirements for the OAM toolset for MPLS-TP are:

   o MPLS-TP OAM must be able to support both an IP based and non-IP
      based environment. If the network is IP based, i.e. IP routing and
      forwarding are available, then the MPLS-TP OAM toolset should rely
      on the IP routing and forwarding capabilities. On the other hand,
      in environments where IP functionality is not available, the OAM
      tools must still be able to operate without dependence on IP
      forwarding and routing.

   o OAM packets and the user traffic are required to be congruent
      (i.e. OAM packets are transmitted in-band) and there is a need to
      differentiate OAM packets from user-plane ones. Inherent in this
      requirement is the principle that MPLS-TP OAM be independent of
      any existing control-plane, although it should not preclude use of
      the control-plane functionality.

3.4.2. Generic Associated Channel

   In order to address the requirement for in-band transmission of MPLS-
   TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
   defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based


Mizrahi, et al.         Expires July 9, 2013                 [Page 19]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   on the same concepts as the PWE3 ACH and VCCV mechanisms.  However,
   to address the needs of LSPs as differentiated from PW, the following
   concepts were defined for [G-ACh]:

   o An Associated Channel Header (ACH), that uses a format similar to
      the PW Control Word, is a 4-byte header that is prepended to OAM
      packets.

   o A Generic Associated Label (GAL). The GAL is a reserved MPLS label
      value (13) that indicates that the packet is an ACH packet and the
      payload follows immediately after the label stack.

3.4.3. MPLS-TP OAM Toolset

   To address the functionality that is required of the OAM toolset, the
   MPLS WG conducted an analysis of the existing IETF and ITU-T OAM
   mechanisms and their ability to fulfill the required functionality.
   The conclusions of this analysis are documented in [OAM-Analys]. The
   MPLS working group currently plans to use a mixture of OAM mechanisms
   that are based on various existing standards, and adapt them to the
   requirements of [MPLS-TP-OAM]. Some of the main building blocks of
   this solution are based on:

   o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
      proactive continuity check and connectivity verification.

   o LSP Ping as defined in [LSP-Ping] for on-demand connectivity
      verification.

   o New protocol packets, using G-ACH, to address different
      functionality.

   o Performance measurement protocols that are based on the
      functionality that is described in [ITU-T-Y1731].

   The following sub-sections describe the OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

3.4.3.1. Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification are presented in
   Section 2.2.5. of this document.  As presented there, these tools may
   be used either proactively or on-demand.  When using these tools
   proactively, they are generally used in tandem.

   For MPLS-TP there are two distinct tools, the proactive tool is
   defined in [TP-CC-CV] while the on-demand tool is defined in


Mizrahi, et al.         Expires July 9, 2013                 [Page 20]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function
   should allow the MEPs to monitor the liveness and connectivity of a
   transport path. In on-demand mode, this function should support
   monitoring between the MEPs and, in addition, between a MEP and MIP.
   [TP-OAM-FW] highlights,  when performing Connectivity Verification,
   the need for the CC-V messages to include unique identification of
   the MEG that is being monitored and the MEP that originated the
   message.

   The proactive tool [TP-CC-CV] is based on extensions to BFD (see
   Section 3.2. ) with the additional limitation that the transmission
   and receiving rates are based on configuration by the operator.  The
   on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see
   Section 3.3. ) for the required behavior of MPLS-TP.

3.4.3.2. Route Tracing

   [MPLS-TP-OAM] defines that there is a need for functionality that
   would allow a path end-point to identify the intermediate and end-
   points of the path. This function would be used in on-demand mode.
   Normally, this path will be used for bidirectional PW, LSP, and
   sections, however, unidirectional paths may be supported only if a
   return path exists.  The tool for this is based on the LSP Ping (see
   Section 3.3. ) functionality and is described in [OnDemand-CV].

3.4.3.3. Lock Instruct

   The Lock Instruct function [Lock-Loop] is used to notify a transport
   path end-point of an administrative need to disable the transport
   path.  This functionality will generally be used in conjunction with
   some intrusive OAM function, e.g. Performance measurement, Diagnostic
   testing, to minimize the side-effect on user data traffic.

3.4.3.4. Lock Reporting

   Lock Reporting is a function used by an end-point of a path to report
   to its far-end end-point that a lock condition has been affected on
   the path.

3.4.3.5. Alarm Reporting

   Alarm Reporting is a function used by an intermediate point of a
   path, that becomes aware of a fault on the path, to report to the
   end-points of the path. [TP-OAM-FW] states that this may occur as a
   result of a defect condition discovered at a server sub-layer. This
   generates an Alarm Indication Signal (AIS) that continues until the



Mizrahi, et al.         Expires July 9, 2013                 [Page 21]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   fault is cleared. The consequent action of this function is detailed
   in [TP-OAM-FW].

3.4.3.6. Remote Defect Indication

   Remote Defect Indication (RDI) is used proactively by a path end-
   point to report to its peer end-point that a defect is detected on a
   bidirectional connection between them. [MPLS-TP-OAM] points out that
   this function may be applied to a unidirectional LSP only if there a
   return path exists.  [TP-OAM-FW] points out that this function is
   associated with the proactive CC-V function.

3.4.3.7. Client Failure Indication

   Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow
   the propagation information from one edge of the network to the
   other. The information concerns a defect to a client, in the case
   that the client does not support alarm notification.

3.4.3.8. Packet Loss Measurement (LM)

   Packet Loss Measurement is a function used to verify the quality of
   the service. This function indicates the ratio of packets that are
   not delivered out of all packets that are transmitted by the path
   source.

   There are two possible ways of determining this measurement:

   o Using OAM packets, it is possible to compute the statistics based
      on a series of OAM packets. This, however, has the disadvantage of
      being artificial, and may not be representative since part of the
      packet loss may be dependent upon packet sizes.

TOM: Not just packet sizes. Things like implementation (as I mentioned above with the comment about the accuracy or truthfulness of the data plane processing of OAM packets).  Doing very accurate RTT as a simple example, with just IP Pings, is a tricky thing to make work.  Also, it is important to mention that the scale in terms of number of packets, number of tests, etc… can and will impact these parameters too.


   o Sending delimiting messages for the start and end of a measurement
      period during which the source and sink of the path count the
      packets transmitted and received. After the end delimiter, the
      ratio would be calculated by the path OAM entity.

3.4.3.9. Packet Delay Measurement (DM)

   Packet Delay Measurement is a function that is used to measure one-
   way or two-way delay of a packet transmission between a pair of the
   end-points of a path (PW, LSP, or Section). Where:






Mizrahi, et al.         Expires July 9, 2013                 [Page 22]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   o One-way packet delay is the time elapsed from the start of
      transmission of the first bit of the packet by a source node until
      the reception of the last bit of that packet by the destination
      node.

   o Two-way packet delay is the time elapsed from the start of
      transmission of the first bit of the packet by a source node until
      the reception of the last bit of the loop-backed packet by the
      same source node, when the loopback is performed at the packet's
      destination node.

   Similarly to the packet loss measurement this could be performed in
   either of the two ways outlined above.

3.5. PWE3 OAM

3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV)

   VCCV, as defined in [VCCV], provides a means for end-to-end fault
   detection and diagnostics tools to be extended for PWs (regardless of
   the underlying tunneling technology). The VCCV switching function
   provides a control channel associated with each PW (based on the PW
   Associated Channel Header (ACH) which is defined in [PW-ACH]), and
   allows transmitting the OAM packets in-band with PW data (using CC
   Type 1: In-band VCCV).

   VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP
   Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being
   sent over the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of
   encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP header) and provides support to
   signal the AC status. The use of the VCCV control channel provides
   the context, based on the MPLS-PW label, required to bind and
   bootstrap the BFD session to a particular pseudo wire (FEC),
   eliminating the need to exchange Discriminator values.

   VCCV consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC label, and (2) switching
   component to cause the PW payload to be treated as a control packet.

   VCCV is not directly dependent upon the presence of a control plane.
   The VCCV capability negotiation may be performed as part of the PW
   signaling when LDP is used. In case of manual configuration of the
   PW, it is the responsibility of the operator to set consistent
   options at both ends.

TOM: Might be helpful to note that the static mode was created specifically to handle the MPLS-TP cases where no control plane was a requirement. However, new use cases such as pure mobile backhaul, etc… find this functionality useful too.





Mizrahi, et al.         Expires July 9, 2013                 [Page 23]
Internet-Draft       Overview of OAM Mechanisms           January 2013


3.5.2. PWE3 OAM using G-ACh

   As mentioned above, VCCV enables OAM for PWs by using a control
   channel for OAM packets. When PWs are used in MPLS-TP networks,
   rather than the control channels defined in VCCV, the G-ACh can be
   used as an alternative control channel. The usage of the G-ACh for
   PWs is defined in [PW-G-ACh].

3.6. OWAMP and TWAMP

3.6.1. Overview

   The IPPM working group in the IETF defines common criteria and
   metrics for measuring performance of IP traffic ([IPPM-FW]). Some of
   the key RFCs published by this working group have defined metrics for
   measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   and packet loss [IPPM-1LM].

   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].

   The IPPM working group has defined not only metrics for performance
   measurement, but also protocols that define how the measurement is
   carried out. The One-way Active Measurement Protocol [OWAMP] and the
   Two-Way Active Measurement Protocol [TWAMP] define a method and
   protocol for measuring delay and packet loss in IP networks.

   OWAMP [OWAMP] enables measurement of one-way characteristics of IP
   networks, such as one-way packet loss and one-way delay.  For its
   proper operation OWAMP requires accurate time of day setting at its
   end points.

   TWAMP [TWAMP] is a similar protocol that enables measurement of two-
   way (round trip) characteristics.  TWAMP does not require accurate
   time of day, and, furthermore, allows the use of a simple session
   reflector, making it an attractive alternative to OWAMP.

   OWAMP and TWAMP use two separate protocols: a Control plane protocol,
   and a Test plane protocol.

3.6.2. Control and Test Protocols

   OWAMP and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of the control protocols is to
   initiate, start, and stop test sessions, and for OWAMP to fetch
   results.  The test protocols introduce test packets (which contain


Mizrahi, et al.         Expires July 9, 2013                 [Page 24]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   sequence numbers and timestamps) along the IP path under test
   according to a schedule, and record statistics of packet arrival.
   Multiple sessions may be simultaneously defined, each with a session
   identifier, and defining the number of packets to be sent, the amount
   of padding to be added (and thus the packet size), the start time,
   and the send schedule (which can be either a constant time between
   test packets or exponentially distributed pseudo-random). Statistics
   recorded conform to the relevant IPPM RFCs.

   OWAMP and TWAMP test traffic is designed with security in mind.  Test
   packets are hard to detect because they are simply UDP streams
   between negotiated port numbers, with potentially nothing static in
   the packets.  OWAMP and TWAMP also include optional authentication
   and encryption for both control and test packets.

3.6.3. OWAMP

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and Fetch-Client.  The Session-
   Sender originates test traffic that is received by the Session-
   Receiver.  The Server configures and manages the session, as well as
   returning the results.  The Control-Client initiates requests for
   test sessions, triggers their start, and may trigger their
   termination.  The Fetch-Client requests the results of a completed
   session.  Multiple roles may be combined in a single host - for
   example, one host may play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing the roles of Server and
   Session-Receiver.

   In a typical OWAMP session the Control-Client establishes a TCP
   connection to port 861 of the Server, which responds with a server
   greeting message indicating supported security/integrity modes. The
   Control-Client responds with the chosen communications mode and the
   Server accepts the modes.  The Control-Client then requests and fully
   describes a test session to which the Server responds with its
   acceptance and supporting information.  More than one test session
   may be requested with additional messages.  The Control-Client then
   starts a test session and the Server acknowledges.  The Session-
   Sender then sends test packets with pseudorandom padding to the
   Session-Receiver until the session is complete or until the Control-
   client stops the session.  Once finished, the Fetch-Client sends a
   fetch request to the server, which responds with an acknowledgement
   and immediately thereafter the result data.






Mizrahi, et al.         Expires July 9, 2013                 [Page 25]
Internet-Draft       Overview of OAM Mechanisms           January 2013


3.6.4. TWAMP

   TWAMP defines the following logical roles: session-sender, session-
   reflector, server, and control-client.  These are similar to the
   OWAMP roles, except that the Session-Reflector does not collect any
   packet information, and there is no need for a Fetch-Client.

   In a typical TWAMP session the Control-Client establishes a TCP
   connection to port 862 of the Server, and mode is negotiated as in
   OWAMP.  The Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them with insertion of
   timestamps.

3.7. Summary of OAM Functions

   Table 3 summarizes the OAM functions that are supported in each of
   the categories that were analyzed in this section.

   +-----------+-------+--------+--------+-----------+-------+--------+
   | Standard  |Continu|Connecti|Path    |Defect     |Perform|Other   |
   |           |ity    |vity    |Discover|Indications|ance   |Function|
   |           |Check  |Verifica|y       |           |Monitor|s       |
   |           |       |tion    |        |           |ing    |        |
   +-----------+-------+--------+--------+-----------+-------+--------+
   |IP Ping    |       |Echo    |        |           |       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |IP         |       |        |Tracerou|           |       |        |
   |Traceroute |       |        |te      |           |       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |BFD        |BFD    |BFD     |        |           |       |        |
   |           |Control|Echo    |        |           |       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |MPLS OAM   |       |"Ping"  |"Tracero|           |       |        |
   |(LSP Ping) |       |mode    |ute"    |           |       |        |
   |           |       |        |mode    |           |       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |MPLS-TP    |CC     |CV/pro- |Route   |-Alarm     |-LM    |-Diagnos|
   |OAM        |       |active  |Tracing | Reporting |-DM    | tic Tes|
   |           |       |or on-  |        |-Client    |       | t      |
   |           |       |demand  |        | Failure   |       |-Lock   |
   |           |       |        |        | Indication|       |        |
   |           |       |        |        |-Remote    |       |        |



Mizrahi, et al.         Expires July 9, 2013                 [Page 26]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   |           |       |        |        | Defect    |       |        |
   |           |       |        |        | Indication|       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |PWE3 OAM   |BFD    |-BFD    |LSP-Ping|           |       |        |
   |           |       |-ICMP   |        |           |       |        |
   |           |       | Ping   |        |           |       |        |
   |           |       |-LSP-   |        |           |       |        |
   |           |       | Ping   |        |           |       |        |
   + --------- + ----- + ------ + ------ + --------- + ----- + ------ +
   |OWAMP and  |       |        |        |           |-Delay |        |
   |TWAMP      |       |        |        |           | measur|        |
   |           |       |        |        |           | ement |        |
   |           |       |        |        |           |-Packet|        |
   |           |       |        |        |           | loss  |        |
   |           |       |        |        |           | measur|        |
   |           |       |        |        |           | ement |        |
   +-----------+-------+--------+--------+-----------+-------+--------+
                     Table 3 Summary of OAM Functions

4. Security Considerations

   This memo presents an overview of existing OAM mechanisms, and
   proposes no new OAM mechanisms. Therefore, this document introduces
   no security considerations. However, the OAM mechanism reviewed in
   this document can and do present security issues. The reader is
   encouraged to review the Security Considerations section of each
   document reference by this memo.

5. IANA Considerations

   There are no new IANA considerations implied by this document.

6. Acknowledgments

   The authors gratefully acknowledge Sasha Vainshtein, Carlos
   Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other
   members of the OPSAWG mailing list for their helpful comments.

   This document was prepared using 2-Word-v2.0.template.dot.







Mizrahi, et al.         Expires July 9, 2013                 [Page 27]
Internet-Draft       Overview of OAM Mechanisms           January 2013


7. References

7.1. Normative References

   [LSP-Ping]    Kompella, K., Swallow, G., "Detecting Multi-Protocol
                 Label Switched (MPLS) Data Plane Failures", RFC 4379,
                 February 2006.

   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
                 Matsushima, S., "Operations and Management (OAM)
                 Requirements for Multi-Protocol Label Switched (MPLS)
                 Networks", RFC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol
                 Label Switching (MPLS) Operations and Management
                 (OAM)", RFC 4378, February 2006.

   [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' for
                 Multiprotocol Label Switching Architecture (MPLS)
                 Operation and Maintenance (OAM) Functions", RFC 3429,
                 November 2002.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for
                 OAM in MPLS Transport Networks", RFC 5860, May 2010.

   [G-ACh]       Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic
                 Associated Channel", RFC 5586, June 2009.

   [VCCV]        Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV): A Control Channel
                 for Pseudowires", RFC 5085, December 2007.

   [PW-ACH]      Bryant, S., Swallow, G., Martini, L., McPherson, D.,
                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                 for Use over an MPLS PSN", RFC 4385, February 2006.

   [ICMPv4]      Postel, J., "Internet Control Message Protocol", STD 5,
                 RFC 792, September 1981.

   [ICMPv6]      Conta, A., Deering, S., and M. Gupta, "Internet Control
                 Message Protocol (ICMPv6) for the Internet Protocol
                 Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., Nadeau, T.,
                 "Operations and Management (OAM) Requirements for
                 Point-to-Multipoint MPLS Networks", RFC 4687,
                 September 2006.


Mizrahi, et al.         Expires July 9, 2013                 [Page 28]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP
                 Extensions for Multiprotocol Label Switching", RFC
                 4950, August 2007.

   [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., Pignataro, C.,
                 "Extended ICMP to Support Multi-Part Messages", RFC
                 4884, April 2007.

   [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,
                 JR., "Extending ICMP for Interface and Next-Hop
                 Identification", RFC 5837, April 2010.

   [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and
                 TCP/IP Tools and Utilities", RFC 2151, June 1997.

   [NetTools]    Stine, R., "FYI on a Network Management Tool Catalog:
                 Tools for Monitoring and Debugging TCP/IP Internets
                 and Interconnected Devices", RFC 1147, April 1990.

   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                 "Framework for IP Performance Metrics", RFC 2330, May
                 1998.

   [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring
                 Connectivity", RFC 2678, September 1999.

   [IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
                 Delay Metric for IPPM", RFC 2679, September 1999.

   [IPPM-1LM]    Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
                 Packet Loss Metric for IPPM", RFC 2680, September
                 1999.

   [IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip
                 Delay Metric for IPPM", RFC 2681, September 1999.

   [OWAMP]       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
                 Zekauskas, M., "A One-way Active Measurement Protocol
                 (OWAMP)", RFC 4656, September 2006.

   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
                 Babiarz, J., "A Two-Way Active Measurement Protocol
                 (TWAMP)", RFC 5357, October 2008.

   [BFD]         Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD)", RFC 5880, June 2010.



Mizrahi, et al.         Expires July 9, 2013                 [Page 29]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   [BFD-IP]      Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
                 2010.

   [BFD-Gen]     Katz, D., Ward, D., "Generic Application of
                 Bidirectional Forwarding Detection (BFD)", RFC 5882,
                 June 2010.

   [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for Multihop Paths", RFC 5883, June 2010.

   [BFD-LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,
                 G., "Bidirectional Forwarding Detection (BFD) for MPLS
                 Label Switched Paths (LSPs)", RFC 5884, June 2010.

   [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional Forwarding
                 Detection (BFD) for the Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV)", RFC 5885, June
                 2010.

   [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Administration and
                 Maintenance Framework for MPLS-based Transport
                 Networks ", RFC 6371, September 2011.

   [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., "Proactive
                 Connectivity Verification, Continuity Check and Remote
                 Defect indication for MPLS Transport Profile", RFC
                 6428, November 2011.

   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS
                 On-Demand Connectivity Verification and Route
                 Tracing", RFC 6426, November 2011.

   [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and Delay
                 Measurement for MPLS Networks", RFC 6374, September
                 2011.

   [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and Delay
                 Measurement Profile for MPLS-Based Transport
                 Networks", RFC 6375, September 2011.

   [TP-Fault]    Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
                 "MPLS Fault Management Operations, Administration, and
                 Maintenance (OAM)", RFC 6427, November 2011.





Mizrahi, et al.         Expires July 9, 2013                 [Page 30]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux,
                 M., Dai, X., "MPLS Transport Profile Lock Instruct and
                 Loopback Functions", RFC 6435, November 2011.

   [ITU-T-CT]    Betts, M., "Allocation of a Generic Associated Channel
                 Type for ITU-T MPLS Transport Profile Operation,
                 Maintenance, and Administration (MPLS-TP OAM)", RFC
                 6671, November 2012.

   [PW-Map]      M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.
                 Nadeau, "Pseudowire (PW) Operations, Administration,
                 and Maintenance (OAM) Message Mapping", RFC 6310, July
                 2011.

   [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F., "Using the
                 Generic Associated Channel Label for Pseudowire in the
                 MPLS Transport Profile (MPLS-TP)", RFC 6423, November
                 2011.

7.2. Informative References

   [OAM-Def]     Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                 D., Mansfield, S., "Guidelines for the use of the OAM
                 acronym in the IETF ", RFC 6291, June 2011.

   [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of the OAM Tool
                 Set for  MPLS based Transport Networks", RFC 6669,
                 July 2012.

   [TP-Term]     Van Helvoort, H., Andersson, L., Sprecher, N., "A
                 Thesaurus for the Terminology used in Multiprotocol
                 Label Switching Transport Profile (MPLS-TP)
                 drafts/RFCs and ITU-T's Transport Network
                 Recommendations", work-in-progress, draft-ietf-mpls-
                 tp-rosetta-stone, July 2012.

   [IEEE802.1ag] IEEE 802.1Q, "IEEE Standard for Local and metropolitan
                 area networks - Media Access Control (MAC) Bridges and
                 Virtual Bridged Local Area Networks", October 2012.

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
                 Mechanisms for Ethernet-based Networks", July 2011.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance
                 mechanism for MPLS networks", February 2004.




Mizrahi, et al.         Expires July 9, 2013                 [Page 31]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology -
                 Local and metropolitan area networks - Carrier sense
                 multiple access with collision detection (CSMA/CD)
                 access method and physical layer specifications",
                 clause 57, December 2008.

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
                 transport equipment - Description methodology and
                 generic functionality", January 2009.

   [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
                 administration and maintenance mechanisms for MPLS-TP
                 networks using the tools defined for MPLS", November
                 2012.

   [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
                 Administration and Maintenance mechanism for MPLS-TP
                 in Packet Transport Network (PTN)", November 2012.



Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692
   Israel

   Email: talmi@marvell.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel



   Elisa Bellagamba
   Ericsson
   6 Farogatan St.
   Stockholm,   164 40
   Sweden



Mizrahi, et al.         Expires July 9, 2013                 [Page 32]
Internet-Draft       Overview of OAM Mechanisms           January 2013


   Phone: +46 761440785


   Yaacov Weingarten
   34 Hagefen St.
   Karnei Shomron,   4485500
   Israel

   Email: wyaacov@gmail.com









draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract 
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL. 

So, as an example: does OAM include function? 
I advice to review draft-ietf-trill-oam-req-04

2. 
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
Ok, I see later on:	
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts. 
However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document. 

You need to change the Table 2 description. Do you want to say something along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard Development Organization 
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the end of
   this document.
Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories, 
   2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
         2.2.4. Proactive and On-demand activation ................ 15
         2.2.5. Connectivity Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system = MEP, MP, or something else?
- etc... 

10. 
This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/


No IPR declarations have been submitted directly on this I-D.


--------------080205090701090609030103-- From cpignata@cisco.com Sat Jan 19 16:44:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2305A21F8554; Sat, 19 Jan 2013 16:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAoay4H1oWlt; Sat, 19 Jan 2013 16:44:29 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B83A721F854E; Sat, 19 Jan 2013 16:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16324; q=dns/txt; s=iport; t=1358642669; x=1359852269; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ztco0YIDOwpV3VZVJ/6BWbnwb/PlJcsFg0xenwoins8=; b=EaVrLs7c2w3RruMj6Uy5qrFQuVvZ5sN2MLkWZ3KdPqpN9SUsRxvMIe8d gUhdPubQcmS26iFqQTqTjOf0DKxgPlgFXPzSKvtoH7t+eWxVHXkWjPCqa Y5DxZH1eh4aqxj483ISm0JQCR9e2lHgDEQCZMu5VOTZBLLfnNd7Inq+5F E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGs9+1CtJV2b/2dsb2JhbAA6Cr4+FnOCIAEEcgcSARwOVicEDg0BiBAMuyiGKYZZBQQBg0xhA5cojy2CdYFmAR8e X-IronPort-AV: E=Sophos;i="4.84,499,1355097600"; d="scan'208";a="165011040" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jan 2013 00:44:27 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0K0iRf0013850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 20 Jan 2013 00:44:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 18:44:27 -0600 From: "Carlos Pignataro (cpignata)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-opsawg-oam-overview-08.txt Thread-Index: AQHN9qdMecjM/63m70mmeKMEQIJ8hg== Date: Sun, 20 Jan 2013 00:44:26 +0000 Message-ID: <95067C434CE250468B77282634C96ED3228D36FF@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.54] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-oam-overview.all@tools.ietf.org" Subject: [OPSAWG] RtgDir review: draft-ietf-opsawg-oam-overview-08.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 00:44:35 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-opsawg-oam-overview-08.txt Reviewer: Carlos Pignataro Review Date: 18 January 2013 IETF LC End Date: 25 January 2013 Intended Status: Informational Summary:=20 I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. Comments: This document presents an overview of Operations, Administration, and Maint= enance (OAM) mechanisms in the IETF. This is a very useful document that us= es OAM consistently with the definition in RFC6291, and further explains th= e acronym by presenting a wider scope and a more concrete view. However, the taxonomy in which all these "mechanics" are presented is confu= sing, because they seem to intertwine the terms functions, tools, and proto= cols. These terms are used quite loosely in this document, which is counter= to its goal of providing clarity. "The beginning of wisdom is a definition= of terms", and for example, this document defines the "Continuity Check" O= AM functionality as a tool, and the ICMPv4 protocol as a tool. The overall organization of the document does not seem to help sometimes, w= ith a "Basic Terminology" section after all tools and documents are describ= ed and cited. Major Issues: The main major set of issues that I found have to do with terminology used,= which is critical for a document that attempts to bring clarity with an ov= erview of OAM mechanisms. This is described in the preceding comments. Additionally, the taxonomy in which these OAM mechanisms are presented seem= s to have gaps and gross overlaps. Section 1.3 groups "OAM toolsets" with a= network on which OAM is used (MPLS), a protocol used for OAM (BFD), a tool= (Ping and Traceroute), etc. Different protocols (e.g., both ICMPv4 and BFD= ) can be use on different networks (MPLS, IPv4, PW); they can be used in di= fferent tools for different utilities. ICMPv4 can be used in VCCV, Tracerou= te for MPLS can use ICMP or LSP Ping, BFD can be used for IP and MPLS for C= C, etc. All these different categorization vectors seem to be intertwined. This then is reflected taking Table 1, "Summary of IETF Related RFCs", as a= n example; it is not clear what is the categorization criteria. The indexes= into the table are "IP Ping and Traceroute" (these are tools -- does this = mean that there are the only OAM mechanisms for IP networks?), "BFD" (a pro= tocol which applies to IP, MPLS, Pseudowires, Tunnels, and others), "MPLS O= AM" (OAM for a particular packet switched network, some of which are BFD, b= ut are already covered in the previous meta-row), "OWAMP and TWAMP: (anothe= r protocol for IP performance metrics), and so on. A potential large amount of minor issues could compound as a major one as w= ell. Some more specific inlined comments follow. 1. Introduction =85 This document summarizes the OAM tools and mechanisms defined in the IETF. If the scope is "IETF", it should be reflected in the title. However, this = seems to contradict the whole Section 1.5, "Non-IETF OAM Documents". 1.2. Forwarding Plane vs. Management Plane This section and intended scope seems to be underspecified. In fact, the do= cument later speaks about other planes, including "user-plane", "Data plane= ", and "Test plane". Perhaps an architectural scope depiction would simplif= y this description and localize the "planes" with more precision. Minor Issues: 1. Introduction OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation. OAM, as defined in RFC6291 (see Section 3), seems to be more broadly define= d than this first paragraph. 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). Is this generic OAM terminology ... This subsection provides a brief summary of the common tools used by OAM protocols. An OAM protocol typically supports one or more of the tools described below. o Continuity Checking (CC): Are these "OAM tools" of "OAM functions" supported by "OAM protocols"? =85 o Path Discovery / Fault Localization: An MP uses this mechanism to trace the route to a peer MP, i.e., to identify the nodes along the path to the peer MP. When a connection fails, this mechanism also allows the MP to detect the location of the failure. "the path" assumes there is a single path and not potential multi-path. Som= e OAM mechanisms included in this document support multi-path tree tracing.= There are also implications of connection-less vs. connection-oriented pro= tocols and paths, which are seemingly not covered. 1.3. The OAM toolsets This memo provides an overview of the different sets of OAM mechanisms defined by the IETF. It is intended for those with little or no familiarity with the described mechanisms. Only defined by the IETF? This contradicts a subsequent section The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). "transport environments", or "Transport Profile"? While OAM mechanisms that are applicable to other technologies exist, they are beyond the scope of this memo. How where these chosen, and others left out then? This document focuses on IETF documents that have been published as RFCs, while other ongoing OAM- related work is outside the scope. IETF only (contradicting Section 1.5), and now limited to published RFCs? T= he scope could be defined before in the document, once only, and more delib= erately. The IETF has defined OAM protocols and mechanisms in several different fronts: >From the list that follows, which one is a protocol versus a mechanism, and= why are those different qualifiers mixed together in a flat list instead o= f matrixed in? o IP Ping and Traceroute: Ping is a very simple and common application for failure diagnosis that uses ICMP Echo requests, as defined in [ICMPv4], and [ICMPv6]. Five issues on this first part of this bullet: 1. Is "failure diagnostic" a new function? 2. What is defined in those two RFCs? Only ICMP and not Ping and Traceroute= . However, it is not clearly articulated. 3. It would be useful to describe where Ping with much more historical cont= ext, for example: RFC1208 ("A Glossary of Networking Terms") defines: ping: Packet internet groper. A program used to test reachability of RFC 1122 as: * Active probes such as "pinging" (i.e., using an ICMP 4. Ping for IPv4 uses ICMPv4 Echo (not Echo Request) and Echo Reply. Ping f= or IPv6 uses Echo Request *and* Echo Reply. 5. "simple" and "common" are in relationship to which baseline? In what net= work? Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to trace the path between an IP source and an IP destination, i.e., to identify the nodes along the path. There is some asymmetry of definitions where Ping is defined based on ICMP = (and not its function of reachability/CC), but traceroute is not defined ba= sed on the protocols used. Also, I have another concern on a potential over-simplification: "to trace = the path between an IP source and an IP destination", implicitly assumes th= ere is only one path. This is not the case generally, and frankly it highli= ghts the potential need of distinction in OAM for connection-less protocols= versus connection-oriented protocols (clps, cops) and implications on path= tree trace. o MPLS OAM: MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- Ping], is an OAM mechanism for point to point MPLS LSPs. It includes two main functions: Ping and Traceroute. To me, bullets like this one are quite misleading. MPLS LSP Ping is one pro= tocol and function to perform "MPLS OAM". But BFD is also used for "MPLS OA= M", and so is "ICMPv4 Echo" o OWAMP and TWAMP: The One Way Active Measurement Protocol (OWAMP) and the Two Way Active Measurement Protocols (TWAMP) are two protocols defined in the IP Performance Metrics (IPPM) working group in the IETF. These protocols allow delay and packet loss measurement in IP networks. These allow for more performance measurements (duplication, reordering, etc= ). It is not totally clear, consequently, if the enumeration is Section 1.1= is inclusive enough. 1.4. IETF OAM Documents The table includes a "Type" column, specifying the nature of each of the listed documents: =85 o Inf.: documents that define an infrastructure that is used by OAM tools. Infrastructure for OAM tools seems to not have been defined. Table 1 needs to be consistent with what is a Tool, Protocol, etc, and how = to categorize (as per comments above). For example: +-----------+--------------------------------------+-----+----------+ | | Title |Type | RFC | +-----------+--------------------------------------+-----+----------+ |IP Ping and| Internet Control Message Protocol |Tool | RFC 792 | |Traceroute | [ICMPv4] | | | | +--------------------------------------+-----+----------+ | | Internet Control Message Protocol |Tool | RFC 4443 | | | (ICMPv6) for the Internet Protocol | | | | | Version 6 (IPv6) Specification | | | | | [ICMPv6] | | | | +--------------------------------------+-----+----------+ These two RFCs do not define "Tools" (as indicated by the table). Further, = traceroute can use UDP (or any IP protocol really) and ICMP errors in addi= tion to ICMP. | +--------------------------------------+-----+----------+ | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | | | Label Switching [ICMP-Ext] | | | | +--------------------------------------+-----+----------+ Is this IP traceroute, MPLS OAM, both? Table 2 summarizes the OAM standards mentioned in this document. Table 2 seems to summarize something different. This sentence should read s= imilar to the legend of the Table. 2. Basic Terminology Basic terminology and abbreviations should have taken place before all the = previous discussion. FEC Forwarding Equivalence Class LDP Label Distribution Protocol The document says that control-plane OAM functions are out of scope. Howeve= r, some control plane functions are explained (and others are not). LSP Pin= g, for example, compares forwarding with control plane. LDP here is control= plane. 3.1.1. Ping 3.1.2. Traceroute Please note that the comments about PING and traceroute already mentioned a= pply equality to these sections. Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows users to discover the path between an IP source and an IP destination. Traceroute sends a sequence of UDP packets to UDP port 33434 at the destination. By default, Traceroute begins by sending This is describing a specific implementation of traceroute. Some stacks use= ICMP probes in traceroute. tcptraceroute uses, well, TCP SYNs as probes, b= ecause it is more friendly to detecting the final hop destination if it is = for example a web server. traceroute-nanog and others allow to specify whic= h IP protocol and which ports. Traceroute implementations), each with an IP Time-To-Live (TTL) value [and hop limit for IPv6] the first router in the path. That router responds by sending three ICMP Time Exceeded Messages to the Traceroute application. Traceroute This, as written, seems misleading. It does not "respond by sending three I= CMP time exceeded messages"=85=20 Note that IP routing may be asymmetric. While Traceroute reveals the path between a source and destination, it may not reveal the reverse path. See above, this also assumes "the one and only path". This reveals the path= for that specific flow used in the probes. A few ICMP extensions ([ICMP-Ext], [ICMP-MP], [ICMP-Int]) have been defined in the context of Traceroute. These extensions augment the ICMP Destination Unreachable message, and can be used by Traceroute applications. Some extensions, for example ICMP-Int, are not only defined in the context = of Traceroute.=20 They also augment many other ICMPs beyond dest unreach. 3.3. MPLS OAM LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: 3.4.2. Generic Associated Channel The G-ACh section is a sub-section of MPLS-TP. However, this is a generic M= PLS mechanism. 3.4.3.5. Alarm Reporting Is this a management plane function? 3.5.1. PWE3 OAM using Virtual Circuit Connectivity Verification (VCCV) VCCV, as defined in [VCCV], provides a means for end-to-end fault detection and diagnostics tools to be extended for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW-ACH]), and allows transmitting the OAM packets in-band with PW data (using CC Type 1: In-band VCCV). This describes Type 1 VCCV CC Type. However it does not describe Types 2 an= d 3=85 3.7. Summary of OAM Functions OWAMP and TWAMP also support CC and CV. 4. Security Considerations I would think that for a document chartered with providing an overview of O= AM mechanisms, a discussion of security considerations of OAM functions (ab= stracted from the protocols and tools) would be most useful, much than the = current "check every RFC we point to". Nits:=20 idnits calls out a couple nits about the References: http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-opsa= wg-oam-overview-08.txt Section 1.2: The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this :s/or/and/ ? Ping], is an OAM mechanism for point to point MPLS LSPs. It point-to-point ? An MP is a bridge interface, that is monitored by an OAM protocol :s/,// ? 3.2. Bidirectional Forwarding Detection (BFD) Has the BFD WG reviewed these sections? 3.3. MPLS OAM LSP Ping is based on ICMP Ping and just like its predecessor may be used in one of two modes: LSP Ping is not "based" on ICMP Ping. It is modeled after the ping/tracerou= te paradigm, which is quite different! o "Ping" mode: In this mode LSP ping is used for end-to-end connectivity verification between two LERs. IP Ping is not used for connectivity verification -- it is used for continu= ity check, however the text implies they are used equivalently. 3.4.3.2. Route Tracing The document seems to use interchangeably "route trace", "path trace", and = other variations. I hope these are clear and useful! Thank you, Carlos Pignataro. From internet-drafts@ietf.org Wed Jan 23 08:44:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AB021F87CC; Wed, 23 Jan 2013 08:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21+L-xhbeO2S; Wed, 23 Jan 2013 08:44:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348D121F84D9; Wed, 23 Jan 2013 08:44:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130123164423.28506.5034.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2013 08:44:23 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-automated-network-configuration-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:44:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Survey of Possibilities for the Automated Configuration = of Large IP Networks Author(s) : Tina Tsou Juergen Schoenwaelder Yang Shi Tom Taylor Guoliang Yang Filename : draft-ietf-opsawg-automated-network-configuration-05.txt Pages : 23 Date : 2013-01-23 Abstract: This memo discusses the steps required to bring a large number of devices into service in IP networks in an automated fashion. The goal of this document is to list known solutions where they exist, to point out approaches proven to be problematic, and to identify gaps that require further specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-automated-network-config= uration There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configuratio= n-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-automated-network-conf= iguration-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Thu Jan 24 08:22:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044D521F878F; Thu, 24 Jan 2013 08:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id artzbMkHtFyN; Thu, 24 Jan 2013 08:22:54 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1578721F857D; Thu, 24 Jan 2013 08:22:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEKAAEvoFCHCzI1/2dsb2JhbABEgX9twGmBAQeCHgEBAQEDEig0CwwEAgEIDQQEAQELFAUEBzIUCQgCBA4FCBqHaAEKniacAZF+YQOXGIRxijaCb4IZ X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="45753280" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Jan 2013 11:10:50 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2013 10:57:07 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 11:23:04 -0500 From: "Romascanu, Dan (Dan)" To: "ietf@ietf.org" Thread-Topic: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC Thread-Index: AQHN8DMMkdjU5d8tZk2bi1Jv4SI3NphYtB9w Date: Thu, 24 Jan 2013 16:23:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA06A4B6@AZ-FFEXMB04.global.avaya.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> In-Reply-To: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:22:55 -0000 This is a useful and well-written document and I support its publication. I= have a few comments which I would be glad if they were addressed:=20 1. I believe that the document must include reference to TRILL OAM, referen= cing draft-ietf-trill-oam-req-04 (which is close to approval) and including= a section on TRILL OAM in the table in 1.4.=20 2. The reference to Non-IETF documents in section 1.5 should mention the fa= ct that non-IETF documents deal in many cases with OAM functions below the = IP layer (layer 2, "2.5") and that operators use in some cases a multi-laye= red OAM approach function of the way their networks are architectured. 3. Section 1.5 mentions [IEEE802.1ag] under 'OAM mechanisms for Ethernet ba= sed networks'. In reality CFM as defined by IEEE 802.1ag is designed to app= ly for all bridged networks in IEEE 802, whatever the media protocol is bei= ng used.=20 4. Together with .1ag I would recommend to also include in the table and li= st of references the CFM extensions defined in 802.1Qaw - Management of dat= a-driven and data-dependent connectivity faults=20 5. I am a little concerned of this document defining - once more - in secti= ons 3.4.3.8 and 3.4.3.9 metrics and speak about measurement methods for Pac= ket Loss and Packet Delay. I would prefer to refer to IPPM RFCs for this pu= rpose 6. Section 1.1 mentions delay variation when describing the Delay Measureme= nt (DM) function, but section 3.4.3.9 'forgets' it. I believe that delay va= riation is important and needs to be covered.=20 Regards, Dan =20 > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, January 11, 2013 9:36 PM > To: IETF-Announce > Cc: opsawg@ietf.org > Subject: Last Call: (An Overview > of Operations, Administration, and Maintenance (OAM) Mechanisms) to > Informational RFC >=20 >=20 > The IESG has received a request from the Operations and Management Area > Working Group WG (opsawg) to consider the following document: > - 'An Overview of Operations, Administration, and Maintenance (OAM) > Mechanisms' > as Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset that can be used for fault detection and > isolation, and for performance measurement. OAM mechanisms have been > defined for various layers in the protocol stack, and are used with a > variety of protocols. >=20 > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 From Robert.Flaim@ic.fbi.gov Thu Jan 24 09:58:54 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1639021F87C5 for ; Thu, 24 Jan 2013 09:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmC5yvcJrxG6 for ; Thu, 24 Jan 2013 09:58:53 -0800 (PST) Received: from mail.ic.fbi.gov (mail.ic.fbi.gov [153.31.119.142]) by ietfa.amsl.com (Postfix) with ESMTP id ECBF321F8782 for ; Thu, 24 Jan 2013 09:58:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,530,1355115600"; d="scan'208,217";a="68506325" Received: from unknown (HELO fbi-hte-01.fbi.gov) ([10.90.16.54]) by dmzamxul01-private-unet.enet.cjis with ESMTP; 24 Jan 2013 12:58:51 -0500 Received: from fbi-exvme-10.FBI.GOV ([172.18.16.30]) by HQCK-UE7HT-101.fbi.gov ([172.18.16.54]) with mapi; Thu, 24 Jan 2013 12:58:47 -0500 From: "Flaim, Robert" To: "opsawg@ietf.org" Date: Thu, 24 Jan 2013 12:58:46 -0500 Thread-Topic: Deterministic Logging Thread-Index: AQHN+lx0MOibDzCGgkGXZrwVDpnvmA== Message-ID: <119FB78A70E3D343BF99B3F18C5B0A36F01558C3@fbi-exvme-10.fbi.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_119FB78A70E3D343BF99B3F18C5B0A36F01558C3fbiexvme10fbigo_" MIME-Version: 1.0 Subject: [OPSAWG] Deterministic Logging X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:58:54 -0000 --_000_119FB78A70E3D343BF99B3F18C5B0A36F01558C3fbiexvme10fbigo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris Donley's draft is significant in that is will help minimize logging for attribution purposes in cases of abuse, fraud and malfeasance. It will greatly aid the Operational Security community. Dear Opsawg, We have posted an updated version of our Deterministic CGN draft, which describes a way to significantly reduce or eliminate CGN logging while providing traceability for abuse response. We'd appreciate your feedback. We'd also like to request adoption as a WG item. Thanks, Chris -- Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs=AE 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) On 1/12/13 8:36 AM, "internet-drafts at ietf.org" wrote: > >A new version of I-D, draft-donley-behave-deterministic-cgn-05.txt >has been successfully submitted by Chris Donley and posted to the >IETF repository. > >Filename: draft-donley-behave-deterministic-cgn >Revision: 05 >Title: Deterministic Address Mapping to Reduce Logging in Carrier= Grade >NAT Deployments >Creation date: 2013-01-12 >WG ID: Individual Submission >Number of pages: 15 >URL: >http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic-cgn- >05.txt >Status: >http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn >Htmlized: >http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-05 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-donley-behave-deterministic-cgn-0= 5 > >Abstract: > In some instances, Service Providers have a legal logging requirement > to be able to map a subscriber's inside address with the address used > on the public Internet (e.g. for abuse response). Unfortunately, > many Carrier Grade NAT logging solutions require active logging of > dynamic translations. Carrier Grade NAT port assignments are often > per-connection, but could optionally use port ranges. Research > indicates that per-connection logging is not scalable in many > residential broadband services. This document suggests a way to > manage Carrier Grade NAT translations in such a way as to > significantly reduce the amount of logging required while providing > traceability for abuse response. While the authors acknowledge that > IPv6 is a preferred solution, Carrier Grade NAT is a reality in many > networks, and is needed in situations where either customer equipment > or Internet content only supports IPv4; this approach should in no > way slow the deployment of IPv6. > --_000_119FB78A70E3D343BF99B3F18C5B0A36F01558C3fbiexvme10fbigo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Chris Donley's draft is significant in that is will h=
elp minimize logging 
for attribution purposes in cases of abuse, fraud and=
 malfeasance.  
It will greatly aid the Operational Security c=
ommunity. 
Dear Opsawg,

We have posted an updated version of our Deterministic CGN=
 draft, which
describes a way to significantly reduce or eliminate CGN logging while
providing traceability for abuse response.  We'd appreciate your feedback.
We'd also like to request adoption as a WG item.

Thanks,
Chris
--=20
Chris Donley
CCIE, CISSP, SCiPM<=
a>
Director - Network Technologies
CableLabs=AE
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)







On 1/12/13 8:36 AM, "internet-drafts at ietf.org&=
quot; <internet-drafts at ietf.org>
wrote:

>
>A new version of I-D, draft-donley-behave-deterministic-cgn-05.txt
>has been successfully submitted by Chris Donley and posted to the
>IETF repository.
>
>Filename:	 draft-donley-behave-deterministic-cgn
>Revision:	 05
>Title:		 Deterministic Address Mapping to Reduce Logging in Carrier Gra=
de
>NAT Deployments
>Creation date:	 2013-01-12
>WG ID:		 Individual Submission
>Number of pages: 15
>URL:            =20
>http://www.ietf.org/inte=
rnet-drafts/draft-donley-behave-deterministic-cgn-
>05.txt
>Status:         =20
>http://datatracker.ietf.org/d=
oc/draft-donley-behave-deterministic-cgn
>Htmlized:       =20
>http://tools.ietf.org/html/draf=
t-donley-behave-deterministic-cgn-05
>Diff:           =20
>http://www.ietf.org/rfc=
diff?url2=3Ddraft-donley-behave-deterministic-cgn-05
>
>Abstract:
>   In some instances, Service Providers have a legal logging requiremen=
t
>   to be able to map a subscriber's inside address with the address use=
d
>   on the public Internet (e.g. for abuse response).  Unfortunately,
>   many Carrier Grade NAT logging solutions require active logging of
>   dynamic translations.  Carrier Grade NAT port assignments are often
>   per-connection, but could optionally use port ranges.  Research
>   indicates that per-connection logging is not scalable in many
>   residential broadband services.  This document suggests a way to
>   manage Carrier Grade NAT translations in such a way as to
>   significantly reduce the amount of logging required while providing
>   traceability for abuse response.  While the authors acknowledge that
>   IPv6 is a preferred solution, Carrier Grade NAT=
 is a reality in many
>   networks, and is needed in situations where either customer equipmen=
t
>   or Internet content only supports IPv4; this ap=
proach should in no
>   way slow the deployment of IPv6.
>
--_000_119FB78A70E3D343BF99B3F18C5B0A36F01558C3fbiexvme10fbigo_-- From brian.e.carpenter@gmail.com Fri Jan 25 06:16:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DED21F867A for ; Fri, 25 Jan 2013 06:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.606 X-Spam-Level: X-Spam-Status: No, score=-101.606 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob3xXIPg-HNN for ; Fri, 25 Jan 2013 06:16:16 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33E21F8A22 for ; Fri, 25 Jan 2013 06:16:15 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so211676eek.27 for ; Fri, 25 Jan 2013 06:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6uGNPESevKfDap/aSHqMdnxA9vgbEmf817I8Z8yZn/Q=; b=KJGSqfIMyXYKqT+cxfb1yCb3HQ6OC4Appz4mQYR9ytse7gPQwx+IVb8zadIRR4uSdX QX14RCqrASnQ+pN9QZFLbhDC33R74it5YaSOLPljM16i9tBiU6MZXqtLUVpIc5iQsd2Q 6yEAetiUEM/yp2ZNSMUfiv0MJMOkSVvOxoYXfUUbALuH5etqXErQaCOfgj1uFp5XRgXB PfiaWXcCmrfuUtNbrsw9imoDtwnSJ/2z3J2GVUXq5ryIbq9z0qmNOxT0ZyUJly+vOCJB Tcru5K857O9t+ldpHgXI+Zm0jurkcnzUN0skpGCmCsbKBtk5EULFgTXDUzAworq7GkzL uyuQ== X-Received: by 10.14.173.196 with SMTP id v44mr14234737eel.29.1359123373209; Fri, 25 Jan 2013 06:16:13 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-213.as13285.net. [2.102.216.213]) by mx.google.com with ESMTPS id q5sm1725511eeo.17.2013.01.25.06.16.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 06:16:12 -0800 (PST) Message-ID: <510293BB.7000301@gmail.com> Date: Fri, 25 Jan 2013 14:16:27 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20130112151616.14125.21259.idtracker@ietfa.amsl.com> <50F191EC.8040306@gmail.com> <50F26AE6.9070405@gmail.com> <50F50F7A.1070001@gmail.com> <50F65CF0.2060909@gmail.com> <50F65E79.4090802@gmail.com> <50F66235.1060500@gmail.com> In-Reply-To: <50F66235.1060500@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-krishnan-opsawg-large-flow-load-balancing@tools.ietf.org" Subject: Re: [OPSAWG] I-D Action: draft-krishnan-opsawg-large-flow-load-balancing-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:16:16 -0000 On 16/01/2013 08:17, Brian E Carpenter wrote: > On 16/01/2013 08:02, Melinda Shore wrote: >> On 1/15/13 10:55 PM, Brian E Carpenter wrote: >>> "Let us assume the probability of a short-lived flow matching a >>> single hash table entry is .25" >>> That would be a very poor hash function. >> That would be a disturbingly bad hash function. But let me ask this: >> do you think the model would be workable with a better hash function? > > The model works. I just don't see the point of running several inferior > hash functions instead of one good one. Ram has convinced me off line that the algorithm for large flow recognition suggested in the draft does make sense. I hope the next version will make this clearer. Brian From aldrin.ietf@gmail.com Tue Jan 15 10:59:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913811E80C5; Tue, 15 Jan 2013 10:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtXkx3joNYtw; Tue, 15 Jan 2013 10:59:11 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B29921F8551; Tue, 15 Jan 2013 10:59:11 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so276772pad.38 for ; Tue, 15 Jan 2013 10:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=YzcBT5nLQNXMdXo/5/4ZUbNMNo6Wub6c0o4Qk87HyGw=; b=rUxbVUmWxq0lmZP/zbFIax/LFnTIMRRiTwBarm2rl5qJmLmvhm6EXX/HEDzzR5caOP f2/obixcuh9kdtb7AOcwF2Zonj72DCJNwgWcIb6/n0WwBuiC+jEf5u64a1c7t7lxRjZc 1nTBIVn0oBQEZJtkiYI95IOdVJLST1Gpzid2snbiG/h5efS3ygpUUA8BWABzchHYVhR9 LvxsAI7bLtQGcC/Mb9lI1vGXO/VXWkeN1Z5rK8qwN3ZykjfQlCEH7JrfBp7Vn7EHS6Nz MNyTBFfqk8ZkSs4QTA76tl6+Vh1pLBbjrs8BebeoyC0CTtH7MUnH/ndrbJ6RwyNbM7Ag oDLw== X-Received: by 10.69.1.73 with SMTP id be9mr271540385pbd.116.1358276351087; Tue, 15 Jan 2013 10:59:11 -0800 (PST) Received: from [192.168.1.5] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPS id p10sm11309189pax.27.2013.01.15.10.59.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 10:59:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CA0F3E7-DA67-4945-AAF7-F63024E8843F" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Sam Aldrin In-Reply-To: <50F56C49.6090103@cisco.com> Date: Tue, 15 Jan 2013 10:59:07 -0800 Message-Id: <9AFD354D-2EF4-4541-9473-BF2A99784406@gmail.com> References: <20130111193616.19158.16205.idtracker@ietfa.amsl.com> <50F437BF.8040005@cisco.com> <50F56C49.6090103@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Mon, 28 Jan 2013 10:07:44 -0800 Cc: "draft-ietf-opsawg-oam-overview@tools.ietf.org" , Al Morton , opsawg@ietf.org, ietf@ietf.org Subject: Re: [OPSAWG] Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:59:13 -0000 --Apple-Mail=_0CA0F3E7-DA67-4945-AAF7-F63024E8843F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Here are my comments. #1 1.1. The Building Blocks of OAM An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). %sam - I do not think that, MP, MEP, etc., terminology is used in OAM = across different layers. It was introduced in MPLS-TP and later in = TRILL, but prior to that, it is not. Is it the authors intention that = this new terminology be used going forward? #2 Sec 1.1 - An OAM protocol typically supports one or more of the tools described below. %sam - what is OAM protocol? Shouldn't it be management plane OR OAM = tools? #3=20 Section 1.2 The considerations of the control-plane maintenance tools or = the functionality of the management-plane are out of scope for this document, which will concentrate on presenting the forwarding-plane tools that are used for OAM. %sam - Why is it out of scope? For example, checking consistency of = control plane to forwarding plane is part of OAM or not?=20 #4 Section 1.3 The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). %sam - For ex: Is ATM OAM (RFC4717) within the scope of this draft? I = did't see any mention of it or FR. I know that they are legacy, but = still within IETF. One day even MPLS will be legacy protocol (just = saying :D) #5 Over all draft %sam - I do not think this draft even considered 'multicast traffic'. = There are rfc's in ever layer supporting multicast. There is no = reference I could find. Ex: RFC6450, RFC6425 etc #6 Sec 3.5=20 %sam - I think it is good to add details on different types of VCCV = types of CC and CV and their use.=20 #7 General %sam - Do you consider MIB part of OAM? Does Traps considered as error = reporting or fault indication? #8=20 Sec 3.4.3.8 and 9 %sam - Do these consider actual packet LM and DM or synthetic packets?=20= #9=20 Section 4 %sam - I think this section should provide more details on what the = general security issues are with OAM messages etc. And how they could be = mitigated. For in-depth details, one could go into each of those = documents. #10 Sec 3.7 I do not think this is complete representation. For ex: no = representation of multicast. BFD could be used for RDI, I think.=20 #11 IP Ping and Traceroute %sam - When you say IP ping, does it imply ICMP ping or IP/UDP ping? cheers -sam On Jan 15, 2013, at 6:48 AM, Benoit Claise wrote: > Some more feedback, send on behalf of Al Morton. >=20 > Regards, Benoit >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > Hi Benoit, > =20 > Here are some additional comments, just checking a few things > I know a little about. > =20 > Al > =20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- > =20 > 1.1. The Building Blocks of OAM > ... > o Performance Monitoring: > Consists of 3 main functions > =20 > o Loss Measurement (LM) - monitors the packet loss rate of a > connection. > =20 > o Delay Measurement (DM) - monitors the delay and delay > variation between MPs. > =20 > o Throughput measurement - monitors the throughput of a > connection. > =20 > >>> Apparently, no OAM tool currently measures Throughput,=20 > because no such tool is cited in the memo (and the term = =93throughput=94 > never appears again). my guess is that there was some reference = to > RFC 2544 that has now been removed. Remove Throughput from the = list. > =20 > 1.3 OAM Toolsets > ...=20 > o OWAMP and TWAMP: > The One Way Active Measurement Protocol (OWAMP) and the Two Way > Active Measurement Protocols (TWAMP) are two protocols defined = in > the IP Performance Metrics (IPPM) working group in the IETF. = These > protocols allow delay and packet loss measurement in IP = networks. > =20 > >>> and Delay variation, duplication, reordering, etc. (all the = metrics limited tools > completely ignore).=20 > =20 > 1.4 IETF OAM Documents > =20 > >>> Expand Table 1 as noted above, to include all the metrics they = missed. > =20 > =20 > 3.6.1 > ... > TWAMP [TWAMP] is a similar protocol that enables measurement of=20 > >>> both one-way and=20 > two-way (round trip) characteristics. =20 > =20 > >>> sentence below is simply not true, because the authors did not = understand > the one-way measurement capability: > TWAMP does not require accurate > time of day, and, furthermore, allows the use of a simple session > reflector, making it an attractive alternative to OWAMP. > >>> go back and read the memo... > =20 > =20 > 3.7. Summary of OAM Functions > =20 > Table 3 summarizes the OAM functions that are supported in each of > the categories that were analyzed in this section. > =20 > = +-----------+-------+--------+--------+-----------+-------+--------+ > | Standard |Continu|Connecti|Path |Defect |Perform|Other = | > | |ity |vity |Discover|Indications|ance = |Function| > | |Check |Verifica|y | |Monitor|s = | > | | |tion | | |ing | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > ... > + --------- + ----- + ------ + ------ + --------- + ----- + ------ = + > |OWAMP and | | | | |-Delay | = | > |TWAMP | Yes | Yes | | | measur| = | > | | | | | | ement | = | > | | | | | |-Packet| = | > | | | | | | loss | = | > | | | | | | measur| = | > | | | | | | ement | = | > = +-----------+-------+--------+--------+-----------+-------+--------+ > Table 3 Summary of OAM Functions > =20 > >>> Both Continuity Check and Connectivity Verification are tested and > confirmed by establishing the *WAMP Control Protocol TCP connection, > so this should be indicated the table. >=20 >=20 >> draft-ietf-opsawg-oam-overview authors, >>=20 >> Here is my feedback on this document. >>=20 >> 1. >> Is this document in line with = http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?=20 >> * For example, the following definitions could be reused. >> Fault: The term Fault refers to an inability to perform a required >> action, e.g., an unsuccessful attempt to deliver a packet. >>=20 >> Defect: The term Defect refers to an interruption in the normal >> operation, such that over a period of time no packets are = delivered >> successfully. >>=20 >> Failure: The term Failure refers to the termination of the = required >> function over a longer period of time. Persistence of a defect for = a >> period of time is interpreted as a failure. >>=20 >> * For example, on the basic abstract=20 >> Abstract >>=20 >> Operations, Administration, and Maintenance (OAM) is a general = term >> that refers to a toolset that can be used for fault detection and >> isolation, and for performance measurement. OAM mechanisms have = been >> defined for various layers in the protocol stack, and are used = with a >> variety of protocols. >>=20 >> Abstract (draft-ietf-trill-oam-req-04) >>=20 >> OAM (Operations, Administration and Maintenance) is a general term >> used to identify functions and toolsets to troubleshoot and = monitor >> networks. This document presents, OAM Requirements applicable to >> TRILL.=20 >>=20 >> So, as an example: does OAM include function?=20 >> I advice to review draft-ietf-trill-oam-req-04 >>=20 >> 2.=20 >> draft-ietf-trill-oam is not mentioned, while the abstract mentions: >> This document presents an overview of the OAM mechanisms that have >> been defined and are currently being defined by the IETF. >> Search for OAM in the current draft names = (https://datatracker.ietf.org/), and you will find many references. >> Ok, I see later on:=09 >> This document focuses on IETF >> documents that have been published as RFCs, while other ongoing = OAM- >> related work is outside the scope. >> Ok, fine then: we don't need a reference to all the drafts.=20 >> However, draft-ietf-trill-oam is closed to be a RFC, and should be = mentioned. >>=20 >>=20 >> 3. >> Section 1 >> The term OAM in this document refers to Operations, Administration >> and Maintenance [OAM-Def], focusing on the forwarding plane of = OAM. >> What does it mean "focusing on the forwarding plane of OAM"? >> Do you take a subset of the definition for this document? >> Btw, I don't see a definition in the terminology section. >> In section 2.2.3 >> A Maintenance Point (MP) is a functional entity that is defined at = a >> node in the network, and either initiates or reacts to OAM = messages. >> Which plane is MP? >>=20 >> 4. >> Section 1, Introduction >> "Hence, management aspects are outside the scope of this document." >> I don't understand which management aspects we speak about here. >> 5. >> Clarifying question regarding 1.2 >> If speak about OWAMP or TWAMP 'synthetic traffic), is that data = plane, control plane, or management plane? >> Note that I found later on in the draft: >> OWAMP and TWAMP use two separate protocols: a Control plane = protocol, >> and a Test plane protocol. >> Interestingly enough, after reading the document, I reviewed = http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, = and saw the same feedback from Stewart Bryant: >> Provide a clear view of OAM functionality and its relationship >> to various =93planes=94 of networking (data plane, control plane, >> management plane). In particular, the importance of >> fate-sharing of OAM and user traffic flows in packet networks >> should be explained. >> 6. >> I see a multiplication of "plane" terms in the IETF document, and in = this document in particular. >> I could find: forwarding plane, management plane, control plane, data = plane, user plane, and test plane. >> Way too many. >> Please be consistent >> 7. >> Table 1 summarizes the IETF OAM related RFCs discussed in this >> document. >>=20 >> Table 2 summarizes the OAM standards mentioned in this document.=20= >>=20 >> You need to change the Table 2 description. Do you want to say = something along the lines of: >> Table 2 summarizes the OAM standards specified by other Standard = Development Organization=20 >> (SDO) than the IETF, along with IETF references where applicable. >>=20 >>=20 >> 8. >> Section 2.2.1 >> For a formal definition of each term, refer to the references at = the end of >> this document. >> Without a reference to a specific RFC, this is the type of statement = which is not useful: you have 5 pages of references. >> You position this document as "An Overview of Operations, = Administration, and Maintenance (OAM) Mechanisms", but you tell the = reader: "if you want to know about the terms, >> just read first all references!" >>=20 >> 9. >> You specify some terms and some OAM categories,=20 >> 2.2.2. OAM Maintenance Entities .......................... 13 >> 2.2.3. OAM Maintenance Points ............................ = 14 >> 2.2.4. Proactive and On-demand activation ................ = 15 >> 2.2.5. Connectivity Verification and Continuity Checks ... = 15 >> 2.2.6. Failures .......................................... = 15 >> ... but you don't use them in the section 3 >>=20 >> Just one example with section 3.2.2 >> - >> o Demand mode: in this mode, BFD control packets are sent = on-demand. >> Upon need, a system initiates a series of BFD control packets = to >> verify the liveness of the session >> Instead of liveness, you have defined Connectivity Verification and = Continuity Checks in section 2.2.5 >> - OLD: >> Each of the end-points of the monitored path maintains its own >> session identification >> NEW: >> Each of the MEP maintains its own session identification >> OR NEW (actually I don't know) >> Each of the MP maintains its own session identification >> - OLD >> A BFD echo packet is sent to a peer system >> Peer system =3D MEP, MP, or something else? >> - etc...=20 >>=20 >> 10.=20 >> This document is composed of a list of OAM content and references, = but I'm really missing the document "scope and target audience". >> When we did RFC 6632, which is the companion document, we had = http://tools.ietf.org/html/rfc6632#section-1.1 >> =20 >> The target audience of the document is, on the one hand, IETF = working >> groups, which aim to select appropriate standard management = protocols >> and data models to address their needs concerning network = management. >> On the other hand, the document can be used as an overview and >> guideline by non-IETF Standards Development Organizations (SDOs) >> planning to use IETF management technologies and data models for = the >> realization of management applications. The document can also be >> used to initiate a discussion between the bodies with the goal to >> gather new requirements and to detect possible gaps. Finally, = this >> document is directed to all interested parties that seek to get an >> overview of the current set of the IETF network management = protocols >> such as network administrators or newcomers to the IETF. >>=20 >> You should have something similar. >>=20 >>=20 >> 11. >> Section 3.6.1, put the paragraph 2 at the end of the section. The = "alternative" in the following sentence would then make sense >> Alternative protocols for performance measurement are defined, for >> example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in = Ethernet >> OAM [ITU-T-Y1731]. >>=20 >>=20 >> My conclusions: this document still needs some work >>=20 >> Regards, Benoit >> =20 >>> The IESG has received a request from the Operations and Management = Area >>> Working Group WG (opsawg) to consider the following document: >>> - 'An Overview of Operations, Administration, and Maintenance (OAM) >>> Mechanisms' >>> as Informational RFC >>>=20 >>> The IESG plans to make a decision in the next few weeks, and = solicits >>> final comments on this action. Please send substantive comments to = the >>> ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments = may be >>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>>=20 >>> Abstract >>>=20 >>>=20 >>> Operations, Administration, and Maintenance (OAM) is a general = term >>> that refers to a toolset that can be used for fault detection and >>> isolation, and for performance measurement. OAM mechanisms have = been >>> defined for various layers in the protocol stack, and are used = with a >>> variety of protocols. >>>=20 >>> This document presents an overview of the OAM mechanisms that = have >>> been defined and are currently being defined by the IETF. >>>=20 >>>=20 >>>=20 >>>=20 >>> The file can be obtained via >>> http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ >>>=20 >>> IESG discussion can be tracked via >>> = http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/ >>>=20 >>>=20 >>> No IPR declarations have been submitted directly on this I-D. >>>=20 >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_0CA0F3E7-DA67-4945-AAF7-F63024E8843F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Here = are my comments.

#1
1.1. The Building Blocks of OAM

   An OAM protocol is run in the context of a Maintenance Domain,
   consisting of two or more nodes that run the OAM protocol, referred
   to as Maintenance Points (MP).
%sam - I do not think that, = MP, MEP, etc.,  terminology is used in OAM across different layers. = It was introduced in MPLS-TP and later in TRILL, but prior to that, it = is not. Is it the authors intention that this new terminology be used = going forward?

#2
Sec 1.1 = - An OAM = protocol typically supports one or more of the
   tools described below.
%sam - what is = OAM protocol? Shouldn't it be management plane OR OAM = tools?

#3 
Section 1.2 The considerations of the control-plane =
maintenance tools or the
   functionality of the management-plane are out of scope for this
   document, which will concentrate on presenting the forwarding-plane
   tools that are used for OAM.
%sam - Why is it out of scope? = For example, checking consistency of control plane to forwarding plane = is part of OAM or = not? 

#4
Section = 1.3 The set = of OAM
   mechanisms described in this =
memo are applicable to IP unicast, MPLS,
   pseudowires, and MPLS for the transport environment =
(MPLS-TP).
%sam - For ex: Is ATM OAM (RFC4717) within the = scope of this draft? I did't see any mention of it or FR. I know that = they are legacy, but still within IETF. One day even MPLS will be legacy = protocol (just saying :D)

#5
Over all = draft
%sam - I do not think this draft even considered = 'multicast traffic'. There are rfc's in ever layer supporting multicast. = There is no reference I could find. Ex: RFC6450, RFC6425 = etc

#6
Sec 3.5 
%sam - = I think it is good to add details on different types of VCCV types of CC = and CV and their = use. 

#7
General
%sam = - Do you consider MIB part of OAM? Does Traps considered as error = reporting or fault = indication?

#8 
Sec 3.4.3.8 and = 9
%sam - Do these consider actual packet LM and DM or = synthetic = packets? 

#9 
Section = 4
%sam - I think this section should provide more details on = what the general security issues are with OAM messages etc. And how they = could be mitigated. For in-depth details, one could go into each of = those documents.

#10
Sec = 3.7
I do not think this is complete representation. For ex: no = representation of multicast. BFD could be used for RDI, I = think. 

#11
IP Ping and = Traceroute
%sam - When you say IP ping, does it imply ICMP = ping or IP/UDP = ping?


cheers
-sam
<= div>
On Jan 15, 2013, at 6:48 AM, Benoit Claise <bclaise@cisco.com> = wrote:

=20 =20
Some more feedback, send on behalf of Al Morton.

Regards, Benoit

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
Hi Benoit,
 
Here are some additional comments, just checking a few things
I know a little = about.
 
Al
 
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-
 
1.1. The Building Blocks of = OAM
...
   o Performance = Monitoring:
      = Consists of 3 main functions
 
        o = Loss Measurement (LM) - monitors the packet loss rate of a
       &nbs= p;  connection.
 
        o = Delay Measurement (DM) - monitors the delay and delay
       &nbs= p;  variation between MPs.
 
        o = Throughput measurement - monitors the throughput of a
  =         connection.
 
>>> Apparently, no OAM tool currently measures Throughput,
    because no = such tool is cited in the memo (and the term =93throughput=94
    never appears = again).  my guess is that there was some reference to
    RFC 2544 that has = now been removed. Remove Throughput from the list.
 
1.3 OAM = Toolsets
...
   o OWAMP and = TWAMP:
      The = One Way Active Measurement Protocol (OWAMP) and the Two Way
      = Active Measurement Protocols (TWAMP) are two protocols defined in
      the = IP Performance Metrics (IPPM) working group in the IETF. These
      = protocols allow delay and packet loss measurement in IP networks.
 
>>> and Delay variation, duplication, reordering, etc. (all the metrics limited = tools
    completely = ignore).
 
1.4 IETF OAM = Documents
 
>>> Expand Table 1 as noted above, to include all the metrics they = missed.
 
 
3.6.1
...
   TWAMP [TWAMP] is a = similar protocol that enables measurement of
>>> both one-way and =
   two-way (round = trip) characteristics. 
 
>>> sentence below is simply not true, because the authors did not = understand
   the one-way measurement capability:
   TWAMP does not require = accurate
   time of day, and, = furthermore, allows the use of a simple session
   reflector, making it an attractive alternative to OWAMP.
>>> go back and read the memo...
 
 
3.7. Summary of OAM = Functions
 
   Table 3 summarizes the = OAM functions that are supported in each of
   the categories that = were analyzed in this section.
 
   = +-----------+-------+--------+--------+-----------+-------+--------+<= /o:p>
   | Standard  |Continu|Connecti|Path    = |Defect     |Perform|Other   = |
   = |           = |ity    |vity    |Discover|Indications|ance   = |Function|
   = |           = |Check  |Verifica|y       = |           = |Monitor|s       |
   = |           = |       |tion    |        = |           = |ing    |        = |
   = +-----------+-------+--------+--------+-----------+-------+--------+<= /o:p>
...
   + --------- + ----- + = ------ + ------ + --------- + ----- + ------ +
   |OWAMP and  = |       = |        |        = |           |-Delay = |        |
   = |TWAMP      |  Yes  |  = Yes   |        = |           | = measur|        = |
   = |           = |       = |        |        = |           | ement = |        |
   = |           = |       = |        |        = |           = |-Packet|        = |
   = |           = |       = |        |        = |           | = loss  |        = |
   = |           = |       = |        |        = |           | = measur|        = |
   = |           = |       = |        |        = |           | ement = |        |
   = +-----------+-------+--------+--------+-----------+-------+--------+<= /o:p>
       &nbs= p;            = Table 3 Summary of OAM Functions
 
>>> Both Continuity Check and Connectivity Verification are tested = and
confirmed by establishing the *WAMP Control Protocol TCP connection,
so this should be indicated the table.


draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://too= ls.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an =
inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract=20
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL.=20

So, as an example: does OAM include function?=20
I advice to review draft-ietf-trill-oam-req-04

2.=20
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/),=
 and you will find many references.
Ok, I see later on:=09
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts.=20
However, draft-ietf-trill-oam is closed to be a RFC, and should be =
mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate =
protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo= t/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its =
relationship
to various =93planes=94 of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms =
in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data =
plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM =
related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document.=20

You need to change the Table 2 description. Do you want to say something =
along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard =
Development Organization=20
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the =
end of
   this document.
Without a reference to a specific RFC, this is the type of statement =
which is not useful: you have 5 pages of references.
You position this document as "An Overview of =
Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know =
about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories,=20
   2.2.2. OAM Maintenance Entities .......................... =
13
         2.2.3. OAM Maintenance Points ............................ =
14
         2.2.4. Proactive and On-demand activation ................ =
15
         2.2.5. Connectivity Verification and Continuity Checks ... =
15
         2.2.6. Failures .......................................... =
15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and =
Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system =3D MEP, MP, or something else?
- etc...=20

10.=20
This document is composed of a list of OAM content and references, but =
I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.=
org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The =
"alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 

The IESG has received a request from the =
Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by =
2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, =
please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
h=
ttp://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballo=
t/


No IPR declarations have been submitted directly on this I-D.



= --Apple-Mail=_0CA0F3E7-DA67-4945-AAF7-F63024E8843F--