From pwe3-bounces@ietf.org Sun Apr 01 20:25:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAKT-0003vF-8S; Sun, 01 Apr 2007 20:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAKR-0003v7-No for pwe3@ietf.org; Sun, 01 Apr 2007 20:23:23 -0400 Received: from zebra.sycamorenet.com ([12.146.0.145] helo=falcon.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYAKR-0004Qd-Dt for pwe3@ietf.org; Sun, 01 Apr 2007 20:23:23 -0400 Received: from MT-Mail.sycamorenet.com ([192.168.200.86]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 20:22:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt Date: Sun, 1 Apr 2007 20:23:49 -0400 Message-ID: <94B3ADCC6E45544CA75307E399F4E94B010E68BD@MT-Mail.sycamorenet.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D03A4DAA6@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt Thread-Index: Acde53YVthBg/7RwT82AtCwct55I8wUDmgiwAB+o7xAAUZhMMA== References: <94B3ADCC6E45544CA75307E399F4E94B010E6735@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA6@exrad3.ad.rad.co.il> From: "Suberri, Moshe" To: "Orly Nicklass" X-OriginalArrivalTime: 02 Apr 2007 00:22:46.0109 (UTC) FILETIME=[098AF0D0:01C774BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "pwe3 \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\) WG" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org In the current data model the validation of the payload size is one-to-many (assuming multiple TDM circuits are using the TDMCfg row). None of the other objects need any validation with respect to the TDM` circuit.=20 When you move the payload size to the pwTDMTable the validation is one to one. That is, payload size to TDM rate. =20 Pesach Samech! =20 -----Original Message----- From: Orly Nicklass [mailto:orly_n@rad.com]=20 Sent: Saturday, March 31, 2007 5:15 AM To: Suberri, Moshe Cc: pwe3 ((((((((E-mail)))))))) WG Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt=20 pwTDMCfgTable is for all configurable objects while pwTDMTable is for the framework. pwTDMTable holds the rate to distinguish among the various TDM types in a smaller resolution than the one exist in the generic PW table. The validation is needed regardless of the object's position and feasible in both cases. -----Original Message----- From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Friday, March 30, 2007 21:47 To: Orly Nicklass Cc: pwe3 ((((((((E-mail)))))))) WG Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt=20 Dear Orly, Regarding "pwTDMCfgPayloadSize" in the "pwTDMCfgTable" table=20 With exception to the payload size all the objects that in the "pwTDMCfgTable" are generic in nature and do not need to be crossed checked with any other tables or objects. The payload size is rather more complex object. In the case of Structure-Aware PW or T1 Structure-Agnostic octet aligned PW, the payload size is closely related to the TDM Rate. That is the payload size must be an integer multiplication of the TDM rate.=20 Having the payload size in the pwTDMCfgTable forces the NMS (or SNMP agent) to validate that the payload size is correct with respect to all the Structure-Aware circuits that are using this payload size. =20 Therefore, I would like you to consider moving the "pwTDMCfgPayloadSize" from the "pwTDMCfgTable" to the "pwTDMTable". =20 Best Regards Moshe =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Apr 01 20:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAYO-0004Co-LW; Sun, 01 Apr 2007 20:37:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYAYN-0004Cd-DN for pwe3@ietf.org; Sun, 01 Apr 2007 20:37:47 -0400 Received: from zebra.sycamorenet.com ([12.146.0.145] helo=falcon.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYAYM-0005ye-GW for pwe3@ietf.org; Sun, 01 Apr 2007 20:37:47 -0400 Received: from MT-Mail.sycamorenet.com ([192.168.200.86]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 20:37:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Sun, 1 Apr 2007 20:38:16 -0400 Message-ID: <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: AcdLAR1RjlreDJxYTYym8Wr1sA9tuQoA89sAABvRchAAUpwsYA== References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> From: "Suberri, Moshe" To: "Orly Nicklass" , , X-OriginalArrivalTime: 02 Apr 2007 00:37:13.0453 (UTC) FILETIME=[0E8521D0:01C774BF] X-Spam-Score: 0.2 (/) X-Scan-Signature: ae94eee30e48a465014d0c9cbb0ac2ba Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1740291703==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1740291703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C774BF.25AA38C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C774BF.25AA38C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the semantic refers to an active row, the wording should be changed from: =20 "1) Objects that MUST NOT be changed after row creation."=20 =20 to =20 "1) Objects that MUST NOT be changed after row activation." =20 =20 ________________________________ From: Orly Nicklass [mailto:orly_n@rad.com]=20 Sent: Saturday, March 31, 2007 5:09 AM To: Suberri, Moshe; davidz@corrigent.com; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 the semantic refers to active row. =20 ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Friday, March 30, 2007 23:53 To: davidz@corrigent.com; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 "The read-create objects in this tables are divided into three categories: 1) Objects that MUST NOT be changed after row creation. These are objects that define basic properties of the PW (for example type, destination, etc.)." =20 =20 Why "basic properties" (with exception to pwIndex) may not be changed if the object is in Not-Ready state?=20 After all the Not-Ready state supposes to provide a scratch pad configuration which is incomplete.=20 =20 [SNMP-v2-TC] "- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); " =20 =20 Regards Moshe =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. =20 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pwe3-pw-mib-10.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C774BF.25AA38C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the semantic refers to an active = row, the wording should be changed from:

 

“1) Objects that MUST NOT be changed after row = creation.”

 

to

 

“1) Objects that MUST NOT be changed after row = activation<= /font>.”

 

 

From: Orly = Nicklass [mailto:orly_n@rad.com]
Sent: Saturday, March 31, = 2007 5:09 AM
To: Suberri, Moshe; davidz@corrigent.com; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

 

the semantic refers to active = row.

 

From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Friday, March 30, = 2007 23:53
To: davidz@corrigent.com; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

 

"The read-create objects in this tables are divided = into

           = three categories:

           1) = Objects that MUST NOT be changed after row = creation.

           = These are objects that define basic properties of the

           = PW (for example type, destination, = etc.)."

 

 

Why “basic properties” (with exception to pwIndex) = may not be changed if the object is in Not-Ready state? =

After all the Not-Ready state supposes to provide a scratch pad configuration which is incomplete.

 

[SNMP-v2-TC]   “- `notReady', which indicates = that the conceptual row

           = ;      exists in the agent, but is missing = information

           = ;      necessary in order to be available for use by = the

           = ;      managed device (i.e., one or more required columns = in

           = ;      the conceptual row have not been instanciated); “ =   

 

Regards

Moshe

 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 PM
To: i-d-announce@ietf.org
Cc: pwe3@ietf.org
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =

 

A New Internet-Draft is available from the on-line = Internet-Drafts

directories.

This draft is a work item of the Pseudowire Emulation Edge to = Edge Working Group of the IETF.

 

      Title       : Pseudo Wire (PW) Management Information Base

      Author(s)   : D. Zelig, = et al.

      Filename    : draft-ietf-pwe3-pw-mib-10.txt

      Pages       : = 63

      Date        : = 2007-2-7

     

This memo defines an experimental portion of the = Management

   Information Base for use with network management = protocols in the

   Internet community.  In particular, it = describes managed objects for

   modeling of Pseudo Wire Edge-to-Edge services = carried over a general

   Packet Switched = Network.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt=

 

To remove yourself from the I-D Announcement list, send a = message to

i-d-announce-request@ietf.org with the word unsubscribe in the = body of

the message.

You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce =

to change your subscription = settings.

 

Internet-Drafts are also available by anonymous FTP. Login with = the

username "anonymous" and a password of your e-mail = address. After

logging in, type "cd internet-drafts" and then =

"get = draft-ietf-pwe3-pw-mib-10.txt".

 

A list of Internet-Drafts directories can be found = in

http://www.ietf.org/shadow.html

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

      = mailserv@ietf.org.

In the body type:

      "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

     

NOTE: The mail server at ietf.org can return the document = in

      MIME-encoded form by using the "mpack" utility.  To use = this

      feature, insert the command "ENCODING mime" before the = "FILE"

      command.  To decode the response(s), you will need "munpack" = or

      a MIME-compliant mail = reader.  Different MIME-compliant mail readers

      exhibit different behavior, = especially when dealing with

      "multipart" MIME = messages (i.e. documents which have been split

      up into multiple messages), so = check your local documentation on

      how to manipulate these = messages.

 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------_=_NextPart_001_01C774BF.25AA38C8-- --===============1740291703== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1740291703==-- From pwe3-bounces@ietf.org Mon Apr 02 06:09:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJSS-0008If-1S; Mon, 02 Apr 2007 06:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJSP-0008IW-DQ for pwe3@ietf.org; Mon, 02 Apr 2007 06:08:13 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJSM-0003i5-0g for pwe3@ietf.org; Mon, 02 Apr 2007 06:08:13 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 02 Apr 2007 13:07:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Mon, 2 Apr 2007 13:07:48 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: AcdLAR1RjlreDJxYTYym8Wr1sA9tuQoA89sAABvRchAAUpwsYAAUCDHV References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> From: "Orly Nicklass" To: "Suberri, Moshe" , , X-Spam-Score: 0.2 (/) X-Scan-Signature: f5e3f76ec5b90a46b9b8bc53da20ed8e Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1420527033==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1420527033== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7750E.C9F91424" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7750E.C9F91424 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable will do. ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] Sent: Mon 4/2/2007 03:38 To: Orly Nicklass; davidz@corrigent.com; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 If the semantic refers to an active row, the wording should be changed = from: =20 "1) Objects that MUST NOT be changed after row creation."=20 =20 to =20 "1) Objects that MUST NOT be changed after row activation." =20 =20 ________________________________ From: Orly Nicklass [mailto:orly_n@rad.com]=20 Sent: Saturday, March 31, 2007 5:09 AM To: Suberri, Moshe; davidz@corrigent.com; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 the semantic refers to active row. =20 ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Friday, March 30, 2007 23:53 To: davidz@corrigent.com; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 "The read-create objects in this tables are divided into three categories: 1) Objects that MUST NOT be changed after row creation. These are objects that define basic properties of the PW (for example type, destination, etc.)." =20 =20 Why "basic properties" (with exception to pwIndex) may not be changed if = the object is in Not-Ready state?=20 After all the Not-Ready state supposes to provide a scratch pad = configuration which is incomplete.=20 =20 [SNMP-v2-TC] "- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated); " =20 =20 Regards Moshe =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Pseudowire Emulation Edge to Edge = Working Group of the IETF. =20 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pwe3-pw-mib-10.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C7750E.C9F91424 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
will = do.
=0A=
=0A= From: Suberri, Moshe = [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Mon 4/2/2007 = 03:38
To: Orly Nicklass; davidz@corrigent.com; = tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: = [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =

=0A=
=0A=
=0A=

If the = semantic refers to an active row, the wording should be changed = from:

=0A=

 

=0A=

“1) Objects that MUST NOT be changed = after row creation.”

=0A=

 

=0A=

to

=0A=

 

=0A=

“1) Objects that MUST NOT be changed = after row activation.”

=0A=

 

=0A=

 

=0A=
=0A=
=0A=
=0A=
=0A=

From: Orly Nicklass = [mailto:orly_n@rad.com]
Sent: Saturday, March 31, 2007 5:09 AM
To: Suberri, Moshe; = davidz@corrigent.com; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=0A=

 

=0A=
=0A=

the semantic = refers to active row.

=0A=

 

=0A=
=0A=
=0A=
=0A=

From: Suberri, = Moshe [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Friday, March 30, 2007 = 23:53
To: = davidz@corrigent.com; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=0A=

 

=0A=

"The read-create objects in this tables are = divided into

=0A=

           three = categories:

=0A=

           1) = Objects that MUST NOT be changed after row creation.

=0A=

           These = are objects that define basic properties of the

=0A=

           = PW (for example type, destination, = etc.)."

=0A=

 

=0A=

 

=0A=

Why “basic properties” (with = exception to pwIndex) may not be changed if the object is in Not-Ready = state?

=0A=

After all the Not-Ready state supposes to = provide a scratch pad configuration which is incomplete. =

=0A=

 

=0A=

[SNMP-v2-TC]   “- `notReady', = which indicates that the conceptual row

=0A=

           &= nbsp;     exists in the agent, but is missing = information

=0A=

           &= nbsp;     necessary in order to be available for use = by the

=0A=

           &= nbsp;     managed device (i.e., one or more required = columns in

=0A=

           &= nbsp;     the conceptual row have not been = instanciated); “   

=0A=

 

=0A=

Regards

=0A=

Moshe

=0A=

 

=0A=

-----Original Message-----
From: = Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: = Wednesday, February 07, 2007 3:50 PM
To: i-d-announce@ietf.org
Cc: = pwe3@ietf.org
Subject: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=0A=

 

=0A=

A New Internet-Draft is available from the = on-line Internet-Drafts

=0A=

directories.

=0A=

This draft is a work item of the Pseudowire = Emulation Edge to Edge Working Group of the IETF.

=0A=

 

=0A=

      = Title       : Pseudo Wire (PW) Management = Information Base

=0A=

      = Author(s)   : D. Zelig, et al.

=0A=

      = Filename    : = draft-ietf-pwe3-pw-mib-10.txt

=0A=

      = Pages       : 63

=0A=

      = Date        : = 2007-2-7

=0A=

      =

=0A=

This memo defines an experimental portion of = the Management

=0A=

   Information Base for use with = network management protocols in the

=0A=

   Internet community.  In = particular, it describes managed objects for

=0A=

   modeling of Pseudo Wire = Edge-to-Edge services carried over a general

=0A=

   Packet Switched = Network.

=0A=

 

=0A=

A URL for this Internet-Draft = is:

=0A=

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt

=0A=

 

=0A=

To remove yourself from the I-D Announcement = list, send a message to

=0A=

i-d-announce-request@ietf.org with the word = unsubscribe in the body of

=0A=

the message.

=0A=

You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce

=0A=

to change your subscription = settings.

=0A=

 

=0A=

Internet-Drafts are also available by = anonymous FTP. Login with the

=0A=

username "anonymous" and a password of your = e-mail address. After

=0A=

logging in, type "cd internet-drafts" and then =

=0A=

"get = draft-ietf-pwe3-pw-mib-10.txt".

=0A=

 

=0A=

A list of Internet-Drafts directories can be = found in

=0A=

http://www.ietf.org/shadow.html =

=0A=

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=0A=

 

=0A=

Internet-Drafts can also be obtained by = e-mail.

=0A=

 

=0A=

Send a message to:

=0A=

      = mailserv@ietf.org.

=0A=

In the body type:

=0A=

      "FILE = /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

=0A=

      =

=0A=

NOTE: The mail server at ietf.org can return = the document in

=0A=

      MIME-encoded = form by using the "mpack" utility.  To use this

=0A=

      feature, insert = the command "ENCODING mime" before the "FILE"

=0A=

      command.  = To decode the response(s), you will need "munpack" or

=0A=

      a = MIME-compliant mail reader.  Different MIME-compliant mail = readers

=0A=

      exhibit = different behavior, especially when dealing with

=0A=

      "multipart" = MIME messages (i.e. documents which have been split

=0A=

      up into = multiple messages), so check your local documentation = on

=0A=

      how to = manipulate these messages.

=0A=

 

=0A=

Below is the data which will enable a MIME = compliant mail reader

=0A=

implementation to automatically retrieve the = ASCII version of the

=0A=

Internet-Draft.

------_=_NextPart_001_01C7750E.C9F91424-- --===============1420527033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1420527033==-- From pwe3-bounces@ietf.org Mon Apr 02 06:11:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJV5-0001kp-SU; Mon, 02 Apr 2007 06:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJV3-0001kV-Ic for pwe3@ietf.org; Mon, 02 Apr 2007 06:10:57 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJV1-0004Jp-Ky for pwe3@ietf.org; Mon, 02 Apr 2007 06:10:57 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 02 Apr 2007 13:10:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt Date: Mon, 2 Apr 2007 13:09:07 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D2B14C4@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt Thread-Index: Acde53YVthBg/7RwT82AtCwct55I8wUDmgiwAB+o7xAAUZhMMAAVBBUN References: <94B3ADCC6E45544CA75307E399F4E94B010E6735@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA6@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68BD@MT-Mail.sycamorenet.com> From: "Orly Nicklass" To: "Suberri, Moshe" X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: "pwe3 \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\) WG" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194824697==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0194824697== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7750F.2E48FABF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7750F.2E48FABF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Validation is done at assignment time, which is one time, regardless of = where we place the object. ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] Sent: Mon 4/2/2007 03:23 To: Orly Nicklass Cc: pwe3 ((((((((E-mail)))))))) WG Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt=20 In the current data model the validation of the payload size is one-to-many (assuming multiple TDM circuits are using the TDMCfg row). None of the other objects need any validation with respect to the TDM` circuit. When you move the payload size to the pwTDMTable the validation is one to one. That is, payload size to TDM rate. Pesach Samech! =20 -----Original Message----- From: Orly Nicklass [mailto:orly_n@rad.com] Sent: Saturday, March 31, 2007 5:15 AM To: Suberri, Moshe Cc: pwe3 ((((((((E-mail)))))))) WG Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt pwTDMCfgTable is for all configurable objects while pwTDMTable is for the framework. pwTDMTable holds the rate to distinguish among the various TDM types in a smaller resolution than the one exist in the generic PW table. The validation is needed regardless of the object's position and feasible in both cases. -----Original Message----- From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] Sent: Friday, March 30, 2007 21:47 To: Orly Nicklass Cc: pwe3 ((((((((E-mail)))))))) WG Subject: RE: [PWE3] WG LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt Dear Orly, Regarding "pwTDMCfgPayloadSize" in the "pwTDMCfgTable" table With exception to the payload size all the objects that in the "pwTDMCfgTable" are generic in nature and do not need to be crossed checked with any other tables or objects. The payload size is rather more complex object. In the case of Structure-Aware PW or T1 Structure-Agnostic octet aligned PW, the payload size is closely related to the TDM Rate. That is the payload size must be an integer multiplication of the TDM rate. Having the payload size in the pwTDMCfgTable forces the NMS (or SNMP agent) to validate that the payload size is correct with respect to all the Structure-Aware circuits that are using this payload size. =20 Therefore, I would like you to consider moving the "pwTDMCfgPayloadSize" from the "pwTDMCfgTable" to the "pwTDMTable". Best Regards Moshe _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 ------_=_NextPart_001_01C7750F.2E48FABF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] WG LC: I-D = ACTION:draft-ietf-pwe3-tdm-mib-07.txt=0A= =0A= =0A= =0A=
=0A=
 
=0A=
Validation is done at assignment time, which is one time, = regardless of where we place the object.
=0A=
=0A= From: Suberri, Moshe = [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Mon 4/2/2007 = 03:23
To: Orly Nicklass
Cc: pwe3 = ((((((((E-mail)))))))) WG
Subject: RE: [PWE3] WG LC: I-D = ACTION:draft-ietf-pwe3-tdm-mib-07.txt

=0A=
=0A=

In the current data model the validation of the = payload size is
one-to-many (assuming multiple TDM circuits are using = the TDMCfg row).
None of the other objects need any validation with = respect to the TDM`
circuit.

When you move the payload size to = the pwTDMTable the validation is one
to one. That is, payload size to = TDM rate.

Pesach Samech!
  

-----Original = Message-----
From: Orly Nicklass [mailto:orly_n@rad.com]
Sent: = Saturday, March 31, 2007 5:15 AM
To: Suberri, Moshe
Cc: pwe3 = ((((((((E-mail)))))))) WG
Subject: RE: [PWE3] WG LC: I-D = ACTION:draft-ietf-pwe3-tdm-mib-07.txt

 pwTDMCfgTable is for = all configurable objects while pwTDMTable is for
the framework. = pwTDMTable holds the rate to distinguish among the
various TDM types = in a smaller resolution than the one  exist in the
generic PW = table. The validation is needed regardless of the object's
position = and feasible in both cases.


-----Original = Message-----
From: Suberri, Moshe [mailto:Moshe.Suberri@sycamo= renet.com]
Sent: Friday, March 30, 2007 21:47
To: Orly = Nicklass
Cc: pwe3 ((((((((E-mail)))))))) WG
Subject: RE: [PWE3] WG = LC: I-D ACTION:draft-ietf-pwe3-tdm-mib-07.txt

Dear = Orly,

Regarding "pwTDMCfgPayloadSize" in the "pwTDMCfgTable" = table

With exception to the payload size all the objects that in = the
"pwTDMCfgTable" are generic in nature and do not need to be = crossed
checked with any other tables or objects.

The payload = size is rather more complex object. In the case of
Structure-Aware PW = or T1 Structure-Agnostic octet aligned PW, the
payload size is = closely related to the TDM Rate. That is the payload
size must be an = integer multiplication of the TDM rate.

Having the payload size = in the pwTDMCfgTable forces the NMS (or SNMP
agent) to validate that = the payload size is correct with respect to all
the Structure-Aware = circuits that are using this payload = size.  


Therefore, I would like you to consider = moving the "pwTDMCfgPayloadSize"
from the "pwTDMCfgTable" to the = "pwTDMTable".



Best = Regards
Moshe




 _______________________________= ________________
 I-D-Announce mailing = list
 I-D-Announce@ietf.org
 https://www1= .ietf.org/mailman/listinfo/i-d-announce


__________________= _____________________________
pwe3 mailing = list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3



______________________________= _________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3

------_=_NextPart_001_01C7750F.2E48FABF-- --===============0194824697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0194824697==-- From pwe3-bounces@ietf.org Mon Apr 02 06:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYK36-0001f9-So; Mon, 02 Apr 2007 06:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWrIh-0000r8-Rp for pwe3@ietf.org; Thu, 29 Mar 2007 05:52:11 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWrIg-0002ft-FU for pwe3@ietf.org; Thu, 29 Mar 2007 05:52:11 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 11:51:56 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Thu, 29 Mar 2007 11:51:58 +0200 Message-ID: In-Reply-To: <8AA97249241F7148BE6D3D8B93D83F5A0DC8050F@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: AcdsZPSW+vOxD7QJTVi9D5+JKXkHIAEO8zLQAAEMA1AATcUIwAAC39Ww From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Danny McPherson" , "pwe3 \(\(\(\(\(\(\(\(E-mail\)\)\)\)\)\)\)\) WG" X-OriginalArrivalTime: 29 Mar 2007 09:51:56.0945 (UTC) FILETIME=[E35FF810:01C771E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 02 Apr 2007 06:46:05 -0400 Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Danny, all This draft well explains how T-MPLS requirements can be covered with a fine tuning of the existing tool box. I strongly support this draft as a WG doc. Best Regards, JL=20 >=20 >=20 > =09 > Folks, > As discussed in the meeting, I'd like to solicit WG feedback on > adopting this as a WG document. If you're in favor or opposed > to adopting this please speak up now. >=20 > -danny >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Apr 02 06:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYK41-0002sp-Br; Mon, 02 Apr 2007 06:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWuCo-00030n-43 for pwe3@ietf.org; Thu, 29 Mar 2007 08:58:18 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWuCn-0006vZ-In for pwe3@ietf.org; Thu, 29 Mar 2007 08:58:18 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Mar 2007 14:58:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Thu, 29 Mar 2007 14:58:10 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: AcdsvquFHAwvryVVSCaVlRoBslLtXAC9/f0gAJLCFIA= References: <449B2580D802A443A923DABF3EAB82AF0DE0CAF3@OCCLUST04EVS1.ugd.att.com> From: "NIGER Philippe RD-RESA-LAN" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 29 Mar 2007 12:58:10.0865 (UTC) FILETIME=[E78CDA10:01C77201] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 X-Mailman-Approved-At: Mon, 02 Apr 2007 06:47:03 -0400 Cc: Danny McPherson X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Agree also on this position. Philippe.=20 -----Message d'origine----- De : BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Envoy=E9 : lundi 26 mars 2007 17:24 =C0 : pwe3@ietf.org Cc : Danny McPherson Objet : RE: [PWE3] Fwd: I-D = ACTION:draft-bryant-pwe3-mpls-transport-00.txt=20 Agree- this should become a WG draft and we should liaison. The document is ready to be a WG draft as it provides a good basis for = addressing the requirements (listed in the appendix). Liaising as a WG = draft indicates our willingness to work on the topic and cooperate to = progress. Deborah=20 -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Thursday, March 22, 2007 11:01 AM To: Thomas D. Nadeau; Italo Busi Cc: Townsley Mark; pwe3((((((((((((((((E-mail))))))))))))))))WG; Danny = McPherson Subject: Re: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt=20 To the contrary, in fact. I would think that a working group would be unlikely to liaise (although = not precluded from liaising work in progress until it has become a WG = draft. Of course, I would also hope that we can liaise this as soon as = possible. Adrian ----- Original Message ----- From: "Thomas D. Nadeau" To: "Italo Busi" Cc: "Townsley Mark" ; "pwe3 ((((((((((((((((E-mail)))))))))))))))) WG" ; "Danny = McPherson" Sent: Thursday, March 22, 2007 2:18 PM Subject: Re: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt > > Why should that preclude this becoming a WG draft for that reason? The = > IETF's PWE3 Working Group is not barred from accepting drafts based on = > what another SDO might reply to in a liason statement, as far as I=20 > know. Perhaps Townsley can clarify? > > --Tom > > >> I oppose. >> >> Quoting a mail from Stewart on Jan 25, 2007: >> " >> At IETF67 we agreed to liaise draft-bryant-pwe3-mpls-transport-00 to ITU=20 >> SG15 >> " >> >> I do not understand why we are progressing this draft to become a WG >> draft >> without sending such a liaison. >> >> Italo >> >>> -----Original Message----- >>> From: Danny McPherson [mailto:danny@tcb.net] >>> Sent: Thursday, March 22, 2007 10:31 AM >>> To: pwe3 ((((((((E-mail)))))))) WG >>> Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls- transport-00.txt >>> >>> >>> >>> Folks, >>> As discussed in the meeting, I'd like to solicit WG feedback on >>> adopting this as a WG document. If you're in favor or opposed >>> to adopting this please speak up now. >>> >>> -danny >>> >>> >>> Begin forwarded message: >>> >>>> From: Internet-Drafts@ietf.org >>>> Date: October 16, 2006 1:50:01 PM MDT >>>> To: i-d-announce@ietf.org >>>> Subject: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt >>>> Reply-To: internet-drafts@ietf.org >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>> >>>> >>>> Title : Application of PWE3 to MPLS Transport Networks >>>> Author(s) : S. Bryant >>>> Filename : draft-bryant-pwe3-mpls-transport-00.txt >>>> Pages : 13 >>>> Date : 2006-10-16 >>>> >>>> A need has been identified to identify a strict subset of the PWE3 >>>> over MPLS pseudowire functionality suitable for the construction of >>>> transport networks. This draft describes the IETF recommended=20 >>>> profile >>>> for such cases. This document describes the IETF-recommended profile >>>> for such a configuration. In particular the profile of an RFC4448 >>>> PWE3 Ethernet pseudowire that can be used to address these >>>> requirements is described. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-mpls- >>>> transport-00.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the = >>>> username "anonymous" and a password of your e-mail address. After=20 >>>> logging in, type "cd internet-drafts" and then "get=20 >>>> draft-bryant-pwe3-mpls-transport-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in=20 >>>> http://www.ietf.org/shadow.html or=20 >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-bryant-pwe3-mpls-transport-00.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in=20 >>>> MIME-encoded form by using the "mpack" utility. To use this=20 >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or a=20 >>>> MIME-compliant mail reader. Different MIME-compliant mail readers >>>> exhibit different behavior, especially when dealing with=20 >>>> "multipart" MIME messages (i.e. documents which have been split up=20 >>>> into multiple messages), so check your local documentation on how=20 >>>> to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader=20 >>>> implementation to automatically retrieve the ASCII version of the=20 >>>> Internet-Draft. >>>> Content-Type: text/plain >>>> Content-ID: <2006-10-16113713.I-D@ietf.org> >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/i-d-announce >>> >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Apr 02 13:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPt7-0005dn-Ft; Mon, 02 Apr 2007 13:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPt6-0005di-2o for pwe3@ietf.org; Mon, 02 Apr 2007 13:00:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPt4-0007q7-Q4 for pwe3@ietf.org; Mon, 02 Apr 2007 13:00:12 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 19:00:08 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32H07mM016841; Mon, 2 Apr 2007 19:00:07 +0200 Received: from [192.168.0.108] (ams3-vpn-dhcp10.cisco.com [10.61.64.10]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32GxqlZ011305; Mon, 2 Apr 2007 16:59:52 GMT Message-ID: <46113688.30707@cisco.com> Date: Mon, 02 Apr 2007 17:59:52 +0100 From: Stewart Bryant User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "O'Connor, Don" Subject: Re: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=797; t=1175533207; x=1176397207; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20Fwd=3A=20I-D=20ACTION=3Adraft-bryant-pwe3-mp ls-transport-00.txt |Sender:=20; bh=LdvG1YgMhvCw07SVhM14coIcXI9t1QEkpaGHPxVajGs=; b=dKVq819wIfOKUUZKZ0O+YRfeVTmEfMg0wQQ8nshxdfOWttSSBJ7UQ0y9yydArt7P1xffdSEa sEhg6ZNiFVKzkGm1Ebeel/YvMkTJSccVkUp1ijmOMjC3+SVdSPrUpYO6; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pwe3@ietf.org, neil.2.harrison@bt.com, danny@tcb.net X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org O'Connor, Don wrote: > Neil, Stewart, Dave > > In order to accomplish > > "when the MPLS > network of party A requires carriage over the MPLS network of party B?'." > > This should be accomplished (in IETF PWE3) by the Generic Pseudowires concept that has been discussed in the recent past. > > Stewart - where does the PWE3 WG stand on Generic Pseudowires? > > Regards > > Don > Don It's something that the chairs have talked about and think is a good idea. It's not on the charter nor have their been any formal proposals put the WG. So in the strictest sense the WG has no position on this topic. If consensus is that we should work on it - which I think needs at least one solutions proposal, then we will ask for it to be added to the charter. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Apr 04 10:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6PI-00014V-2O; Wed, 04 Apr 2007 10:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6PG-00014I-7h for pwe3@ietf.org; Wed, 04 Apr 2007 10:24:14 -0400 Received: from out001.iad.hostedmail.net ([209.225.56.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6PB-0005GU-K7 for pwe3@ietf.org; Wed, 04 Apr 2007 10:24:14 -0400 Received: from ATL1VEXC010.usdom003.tco.tc ([10.158.7.18]) by out001.iad.hostedmail.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:24:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Apr 2007 10:23:09 -0400 Message-ID: <941E166DB8C7F543B1FDDE0D8CAF29490693884E@ATL1VEXC010.usdom003.tco.tc> In-Reply-To: <941E166DB8C7F543B1FDDE0D8CAF29497F49F8@ATL1VEXC010.usdom003.tco.tc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concern with draft-ietf-pwe3-enet-mib-10 Thread-Index: AcdrOqUbbt9xtCe8QZmvkHqSjstkJwBPPsFwAAQnjcQCjknSgA== References: <941E166DB8C7F543B1FDDE0D8CAF29497F49DE@ATL1VEXC010.usdom003.tco.tc> <44F4E579A764584EA9BDFD07D0CA0813A7827A@tlvmail1.corrigent.com> <941E166DB8C7F543B1FDDE0D8CAF29497F49F8@ATL1VEXC010.usdom003.tco.tc> From: "Ken Young" To: "Ken Young" , "David Zelig" , X-OriginalArrivalTime: 04 Apr 2007 14:24:04.0932 (UTC) FILETIME=[E6179040:01C776C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: Lyndon Ong , Brian Smith , Chris Barrett , tnadeau@cisco.com Subject: [PWE3] RE: Concern with draft-ietf-pwe3-enet-mib-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0841814888==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0841814888== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776C4.E59DCAA5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776C4.E59DCAA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 As I previously stated, I checked into the view of this from the MEF. The MEF is remaining at the services level. As such, they define the attributes of a particular service but not how it gets translated into a particular technology such as pseudowires. The MEF definition is also a moving target. =20 =20 As such, I agree that we can not fix the change the scope of the current PW-ENET MIB to align with the MEF. =20 However, it should align with the requirements of RFC4448. Section 4.7 and Appendix B state that an Ethernet flow can be mapped to a pseudowire using the port, VLAN and p-bit values. I would like to see this added to the PW-ENET MIB. =20 Thanks, Ken =20 ________________________________ From: Ken Young=20 Sent: March 22, 2007 10:04 AM To: David Zelig; pwe3@ietf.org Cc: Lyndon Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10 =20 David, =20 Thanks for resolving issue 1. That gets the list down to 2 outstanding issues. =20 I agree with your comments on issue 2. L2CP discards should be provisioned as part of the NSP. Isn't that what the PW-ENET-MIB is defining for these types of PWs? =20 I hear your point on the fact that there is no process between the MEF and IETF on this issue. I am going to raise this in the MEF technical community and get back to list on this topic. =20 I personally believe this is important since the MEF is defining the customer facing attributes of an Ethernet service offered by Service providers. We have customers demanding that we be MEF certified to be able to sell our equipment. I would prefer to use a standard MIB for this since this is not any part of our secret sauce and I think other companies will benefit. =20 My 2 cents, Ken =20 ________________________________ From: David Zelig [mailto:Davidz@corrigent.com] Sent: Thu 3/22/2007 08:18 To: Ken Young; pwe3@ietf.org Cc: Lyndon Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10 Ken, Please see inside. -----Original Message----- From: Ken Young [mailto:KenY@gridpointsystems.com] Sent: Wednesday, March 21, 2007 12:07 AM To: pwe3@ietf.org Cc: Lyndon Ong; David Zelig; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: Concern with draft-ietf-pwe3-enet-mib-10 All, Since the PW-ENET MIB is heading for last call, I reviewed the MIB today. I realised that the MIB does not comply to the MEF's view of Ethernet E-line services. For more information on this definition, please refer to: http://www.metroethernetforum.org/PDFs/Standards/Overview_of_MEF_6_and_1 0.ppt I realise that this was not the stated intention of the MIB but I would like to see the gaps closed. Note that I believe this gap is small. We only need to address 3 issues: 1/ defining a default VLAN for the untagged and priority packets (this may already be possible) [DZ] Assigning a PW for the default VLAN and priority tagged packets can be supported by the PW-ENET-STD-MIB. 2/ define how L2CP protocols are handled (right now they are tunnelled). We need to add the capability to discard L2CP packets. I believe this is desirable on a per L2CP basis but I need to verify this. [DZ] I think that this part of the functionality is part of the NSP function. In addition, the MEF may change the specifications at any time, and there is no mutual process to synchronize the specifications. 3/ define a way to map p-bit / vlans to a PW. The rest are discarded. [DZ] I believe that this functionality is out of the scope of the PWE3 group (and as such from PWE3 MIB modules). Note also that traffic descriptors at the PW level (as exist in the MEF) are not defined as QOS issues are not defined within the group. I need to review this in more detail to make sure these are the only gaps. However, before I went through this effort, I wanted to bring this issue to the list. Do we see MEF compliance as an objective of the PW-ENET service? [DZ] There is no mutual process between the MEF and IETF to adjust the specifications. The MIB modules are derived from IETF specifications. If the specifications will changed, than we can adapt the MIB modules. Thanks David Please let me know, Ken ------_=_NextPart_001_01C776C4.E59DCAA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Concern with draft-ietf-pwe3-enet-mib-10

David,

 

As I previously stated, I checked = into the view of this from the MEF.  The MEF is remaining at the services = level.  As such, they define the attributes of a particular service but not how it gets translated into a particular technology such as pseudowires.  The MEF definition is = also a moving target. 

 

As such, I agree that we can not = fix the change the scope of the current PW-ENET MIB to align with the = MEF.

 

However, it should align with the requirements of RFC4448.  Section 4.7 and Appendix B state that an = Ethernet flow can be mapped to a pseudowire using the port, VLAN and p-bit = values.  I would like to see this added to the PW-ENET = MIB.

 

Thanks,

=

Ken

 

From: = Ken Young
Sent: March 22, 2007 = 10:04 AM
To: David Zelig; = pwe3@ietf.org
Cc: Lyndon Ong; = tnadeau@cisco.com; Brian = Smith; Chris = Barrett
Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10

 

David,

=

 

Thanks for resolving issue 1.  That gets the = list down to 2 outstanding issues.

 

I agree with your comments on issue 2.  L2CP = discards should be provisioned as part of the NSP.  Isn't that what the = PW-ENET-MIB is defining for these types of PWs?

 

I hear your point on the fact that there is no = process between the MEF and IETF on this issue.  I am going to raise this = in the MEF technical community and get back to list on this = topic.

 

I personally believe this is important since the MEF = is defining the customer facing attributes of an Ethernet service offered = by Service providers.  We have customers demanding that we be MEF = certified to be able to sell our equipment.  I would prefer to use a standard = MIB for this since this is not any part of our secret sauce and I think = other companies will benefit.

 

My 2 cents,

Ken

 

From: David Zelig [mailto:Davidz@corrigent.com]
Sent: Thu 3/22/2007 = 08:18
To: Ken Young; pwe3@ietf.org
Cc: Lyndon Ong; = tnadeau@cisco.com; Brian = Smith; Chris = Barrett
Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10

Ken,
Please see inside.

-----Original Message-----
From: Ken Young [mailto:KenY@gridpointsystems.co= m]
Sent: Wednesday, March 21, 2007 12:07 AM
To: pwe3@ietf.org
Cc: Lyndon Ong; David Zelig; tnadeau@cisco.com; Brian Smith; Chris
Barrett
Subject: Concern with draft-ietf-pwe3-enet-mib-10

All,

Since the PW-ENET MIB is heading for last call, I reviewed the MIB
today.  I realised that the MIB does not comply to the MEF's view = of
Ethernet E-line services.  For more information on this = definition,
please refer to:

http://www.metroethernetforum.org/PDFs/Standards/Overview_of_MEF= _6_and_1
0.ppt
<https://webaccess.hostedmail.net/exchweb/bin/redir.asp?URL=3Dhttp://w= ww.m
etroethernetforum.org/PDFs/Standards/Overview_of_MEF_6_and_10.ppt>
=
I realise that this was not the stated intention of the MIB but I = would
like to see the gaps closed.  Note that I believe this gap is = small.  We
only need to address 3 issues:

1/  defining a default VLAN for the untagged and priority packets = (this
may already be possible)
[DZ] Assigning a PW for the default VLAN and priority tagged packets = can
be supported by the PW-ENET-STD-MIB.

2/  define how L2CP protocols are handled (right now they are
tunnelled).  We need to add the capability to discard L2CP = packets.  I
believe this is desirable on a per L2CP basis but I need to verify = this.
[DZ] I think that this part of the functionality is part of the NSP
function. In addition, the MEF may change the specifications at any
time, and there is no mutual process to synchronize the = specifications.

3/  define a way to map p-bit / vlans to a PW.  The rest are discarded.
[DZ] I believe that this functionality is out of the scope of the = PWE3
group (and as such from PWE3 MIB modules). Note also that traffic
descriptors at the PW level (as exist in the MEF) are not defined as = QOS
issues are not defined within the group.


I need to review this in more detail to make sure these are the only
gaps.  However, before I went through this effort, I wanted to = bring
this issue to the list.

Do we see MEF compliance as an objective of the PW-ENET service?
[DZ] There is no mutual process between the MEF and IETF to adjust = the
specifications. The MIB modules are derived from IETF specifications. = If
the specifications will changed, than we can adapt the MIB modules.

Thanks
David

Please let me know,
Ken

------_=_NextPart_001_01C776C4.E59DCAA5-- --===============0841814888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0841814888==-- From pwe3-bounces@ietf.org Wed Apr 04 15:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUp-0004Rm-I1; Wed, 04 Apr 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUc-0004JA-4z; Wed, 04 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBUY-0000yG-Lf; Wed, 04 Apr 2007 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8D30132A27; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gr-Ed; Wed, 04 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-tdm-mib-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Managed Objects for TDM over Packet Switched Network (PSN) Author(s) : O. Nicklass Filename : draft-ietf-pwe3-tdm-mib-08.txt Pages : 42 Date : 2007-4-4 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdm-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4135201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4135201.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Apr 04 15:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBV6-0004et-MM; Wed, 04 Apr 2007 15:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUc-0004Jp-HR; Wed, 04 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBUb-0000yT-Ca; Wed, 04 Apr 2007 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9724032A2B; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gu-FP; Wed, 04 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-atm-mib-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Managed Objects for ATM over Packet Switched Network (PSN) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-pw-atm-mib-03.txt Pages : 38 Date : 2007-4-4 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN) as defined in the PWE3 [ATMENCAP]and [ATMTRANS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-atm-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4135325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-atm-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4135325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Apr 04 15:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUp-0004Rm-I1; Wed, 04 Apr 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUc-0004JA-4z; Wed, 04 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBUY-0000yG-Lf; Wed, 04 Apr 2007 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 8D30132A27; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gr-Ed; Wed, 04 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-tdm-mib-08.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Managed Objects for TDM over Packet Switched Network (PSN) Author(s) : O. Nicklass Filename : draft-ietf-pwe3-tdm-mib-08.txt Pages : 42 Date : 2007-4-4 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdm-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4135201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdm-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4135201.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Apr 04 15:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBV6-0004et-MM; Wed, 04 Apr 2007 15:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBUc-0004Jp-HR; Wed, 04 Apr 2007 15:50:06 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBUb-0000yT-Ca; Wed, 04 Apr 2007 15:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9724032A2B; Wed, 4 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HZBUY-0001gu-FP; Wed, 04 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-atm-mib-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Managed Objects for ATM over Packet Switched Network (PSN) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-pw-atm-mib-03.txt Pages : 38 Date : 2007-4-4 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN) as defined in the PWE3 [ATMENCAP]and [ATMTRANS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-atm-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-4135325.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-atm-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-4135325.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Apr 09 12:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax6u-0006hD-28; Mon, 09 Apr 2007 12:52:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hax6s-0006h8-27 for pwe3@ietf.org; Mon, 09 Apr 2007 12:52:54 -0400 Received: from black.monoski.com ([63.227.123.238] helo=napoleon.monoski.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hax6p-0006WX-Id for pwe3@ietf.org; Mon, 09 Apr 2007 12:52:54 -0400 Received: from [209.245.27.1] (napoleon.monoski.com [209.245.27.1]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id l39GhpPH023650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 10:44:32 -0600 (MDT) Message-ID: <461A6D47.4020404@cisco.com> Date: Mon, 09 Apr 2007 10:43:51 -0600 From: Luca Martini User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: "PWE3 WG (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0a1 (napoleon.monoski.com [209.245.27.1]); Mon, 09 Apr 2007 10:44:34 -0600 (MDT) X-Scanned-By: MIMEDefang 2.57 on 209.245.27.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "George Swallow \(swallow\)" , Mustapha Aissaoui , Chris Metz , Matthew BOCCI Subject: [PWE3] draft-ietf-pwe3-segmented-pw-04.txt and PW status section X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org WG, I would like to solicit comments on the pw status changes in draft-ietf-pwe3-segmented-pw-04.txt. In particular here a some comments that folks have made in private: 1) Terminology is not clear. This explicit section/segment/line terminology for faults. The reverse/forward fault terminology is not clear. 2) Local PW2 reverse direction fault: Send a PW status message to S-PE1 containing "0x00000008 - Local PSN-facing PW (ingress) Receive Fault" appear to be a bit misleading as it is a transmit fault, and only an assumed rx fault. 3) one proposal to use two more status bits and make the meaning of the fault more clear. So I would like to bring some of these comments to the list. Any more comments on section 9.6 or any other section ? Thanks. Luca _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Apr 09 13:27:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haxdt-0007pG-SA; Mon, 09 Apr 2007 13:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haxdr-0007ol-O5 for pwe3@ietf.org; Mon, 09 Apr 2007 13:26:59 -0400 Received: from zebra.sycamorenet.com ([12.146.0.145] helo=falcon.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaxdW-0005Jc-U4 for pwe3@ietf.org; Mon, 09 Apr 2007 13:26:40 -0400 Received: from MT-Mail.sycamorenet.com ([192.168.200.86]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 13:25:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Mon, 9 Apr 2007 13:27:03 -0400 Message-ID: <94B3ADCC6E45544CA75307E399F4E94B01161ACD@MT-Mail.sycamorenet.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: AcdLAR1RjlreDJxYTYym8Wr1sA9tuQoA89sAABvRchAAUpwsYAAUCDHVAW6k1SA= References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> From: "Suberri, Moshe" To: , X-OriginalArrivalTime: 09 Apr 2007 17:25:59.0000 (UTC) FILETIME=[2372ED80:01C77ACC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 66ff42a56498684039efb58366a4b354 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0434731574==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0434731574== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77ACC.3EC2D7A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77ACC.3EC2D7A8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable " 7. Relations to Other PWE3 MIB Modules . . . - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'." " =20 If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this class of errors. For example, adding a value of 'inconsistentConfiguration' or 'configurationError' will unambiguously identify the problem to the operator.=20 =20 =20 Regards Moshe =20 =20 =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. =20 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pwe3-pw-mib-10.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C77ACC.3EC2D7A8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“

7.  = Relations to Other PWE3 MIB Modules

.

.

.

- =  Unless all the necessary entries in the applicable tables have = been

   created and all the parameters have been consistently configured = in

   those tables, signaling cannot be performed from the local node, = and

   the pwVcOperStatus should report = 'notPresent'.”

“

 

If you = want to expand the definition of the Operational Status to include configuration = anomalies, it could be operationally helpful to uniquely qualify this class of = errors. For example, adding a value of ‘inconsistentConfiguration’ or = ‘configurationError’ will unambiguously identify the problem to the operator. =

 

 

Regards

Moshe =   

 

 

 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 PM
To: i-d-announce@ietf.org
Cc: pwe3@ietf.org
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =

 

A New Internet-Draft is available from the on-line = Internet-Drafts

directories.

This draft is a work item of the Pseudowire Emulation Edge to = Edge Working Group of the IETF.

 

      Title       : Pseudo Wire (PW) Management Information Base

      Author(s)   : D. Zelig, = et al.

      Filename    : draft-ietf-pwe3-pw-mib-10.txt

      Pages       : = 63

      Date        : = 2007-2-7

     

This memo defines an experimental portion of the = Management

   Information Base for use with network management = protocols in the

   Internet community.  In particular, it = describes managed objects for

   modeling of Pseudo Wire Edge-to-Edge services = carried over a general

   Packet Switched = Network.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt=

 

To remove yourself from the I-D Announcement list, send a = message to

i-d-announce-request@ietf.org with the word unsubscribe in the = body of

the message.

You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce =

to change your subscription = settings.

 

Internet-Drafts are also available by anonymous FTP. Login with = the

username "anonymous" and a password of your e-mail = address. After

logging in, type "cd internet-drafts" and then =

"get = draft-ietf-pwe3-pw-mib-10.txt".

 

A list of Internet-Drafts directories can be found = in

http://www.ietf.org/shadow.html

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

      = mailserv@ietf.org.

In the body type:

      "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

     

NOTE: The mail server at ietf.org can return the document = in

      MIME-encoded form by using the "mpack" utility.  To use = this

      feature, insert the command "ENCODING mime" before the = "FILE"

      command.  To decode the response(s), you will need "munpack" = or

      a MIME-compliant mail = reader.  Different MIME-compliant mail readers

      exhibit different behavior, = especially when dealing with

      "multipart" MIME = messages (i.e. documents which have been split

      up into multiple messages), so = check your local documentation on

      how to manipulate these = messages.

 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------_=_NextPart_001_01C77ACC.3EC2D7A8-- --===============0434731574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0434731574==-- From pwe3-bounces@ietf.org Mon Apr 09 18:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2Bj-0002vH-D1; Mon, 09 Apr 2007 18:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2Bf-0002s3-4y; Mon, 09 Apr 2007 18:18:11 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2Be-00024O-Su; Mon, 09 Apr 2007 18:18:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CD629328A2; Mon, 9 Apr 2007 22:18:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hb2Ba-0005et-O4; Mon, 09 Apr 2007 18:18:06 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 09 Apr 2007 18:18:06 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Internet Architecture Board , pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'AII Types for Aggregation' to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has approved the following document: - 'AII Types for Aggregation ' as a Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-aii-aggregate-02.txt Technical Summary The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AII). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability. Working Group Summary This document has been reviewed by the experts in the PWE3 WG and there are no outstanding issues. Protocol Quality This is a very simple and well written extension to the PWE3 signaling protocol. No protocol issues are anticipated. The document was reviewed for the IESG by Mark Townsley, Danny McPherson is the document shepherd. Note to RFC Editor Please create an Informative references section and move [MP-BGP-AUTO-DISC] to it. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Apr 11 02:23:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWEO-0005dx-Bz; Wed, 11 Apr 2007 02:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWEN-0005dr-JW for pwe3@ietf.org; Wed, 11 Apr 2007 02:22:59 -0400 Received: from tlvmail1.corrigent.com ([213.31.203.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbWEJ-0005K3-3y for pwe3@ietf.org; Wed, 11 Apr 2007 02:22:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Apr 2007 09:21:50 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813A78988@tlvmail1.corrigent.com> In-Reply-To: <941E166DB8C7F543B1FDDE0D8CAF29490693884E@ATL1VEXC010.usdom003.tco.tc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concern with draft-ietf-pwe3-enet-mib-10 Thread-Index: AcdrOqUbbt9xtCe8QZmvkHqSjstkJwBPPsFwAAQnjcQCjknSgAFP2BRQ References: <941E166DB8C7F543B1FDDE0D8CAF29497F49DE@ATL1VEXC010.usdom003.tco.tc> <44F4E579A764584EA9BDFD07D0CA0813A7827A@tlvmail1.corrigent.com> <941E166DB8C7F543B1FDDE0D8CAF29497F49F8@ATL1VEXC010.usdom003.tco.tc> <941E166DB8C7F543B1FDDE0D8CAF29490693884E@ATL1VEXC010.usdom003.tco.tc> From: "David Zelig" To: "Ken Young" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Cc: Lyndon Ong , Brian Smith , Chris Barrett , tnadeau@cisco.com Subject: [PWE3] RE: Concern with draft-ietf-pwe3-enet-mib-10 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1805213979==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1805213979== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77C01.D40F5493" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77C01.D40F5493 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ken, Please see inside =20 ________________________________ From: Ken Young [mailto:KenY@gridpointsystems.com]=20 Sent: Wednesday, April 04, 2007 5:23 PM To: Ken Young; David Zelig; pwe3@ietf.org Cc: Lyndon Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10 David, =20 As I previously stated, I checked into the view of this from the MEF. The MEF is remaining at the services level. As such, they define the attributes of a particular service but not how it gets translated into a particular technology such as pseudowires. The MEF definition is also a moving target. =20 =20 As such, I agree that we can not fix the change the scope of the current PW-ENET MIB to align with the MEF. [DZ] OK. =20 However, it should align with the requirements of RFC4448. Section 4.7 and Appendix B state that an Ethernet flow can be mapped to a pseudowire using the port, VLAN and p-bit values. I would like to see this added to the PW-ENET MIB. [DZ] This functionality do not exist in any working implementation as far as the authors know (also verified on the PWE3 list few months ago - before we removed it). We believe that the MIB created by the group should reflect current working practice. =20 Thanks David =20 Thanks, Ken =20 ________________________________ From: Ken Young=20 Sent: March 22, 2007 10:04 AM To: David Zelig; pwe3@ietf.org Cc: Lyndon Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10 =20 David, =20 Thanks for resolving issue 1. That gets the list down to 2 outstanding issues. =20 I agree with your comments on issue 2. L2CP discards should be provisioned as part of the NSP. Isn't that what the PW-ENET-MIB is defining for these types of PWs? =20 I hear your point on the fact that there is no process between the MEF and IETF on this issue. I am going to raise this in the MEF technical community and get back to list on this topic. =20 I personally believe this is important since the MEF is defining the customer facing attributes of an Ethernet service offered by Service providers. We have customers demanding that we be MEF certified to be able to sell our equipment. I would prefer to use a standard MIB for this since this is not any part of our secret sauce and I think other companies will benefit. =20 My 2 cents, Ken =20 ________________________________ From: David Zelig [mailto:Davidz@corrigent.com] Sent: Thu 3/22/2007 08:18 To: Ken Young; pwe3@ietf.org Cc: Lyndon Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: RE: Concern with draft-ietf-pwe3-enet-mib-10 Ken, Please see inside. -----Original Message----- From: Ken Young [mailto:KenY@gridpointsystems.com] Sent: Wednesday, March 21, 2007 12:07 AM To: pwe3@ietf.org Cc: Lyndon Ong; David Zelig; tnadeau@cisco.com; Brian Smith; Chris Barrett Subject: Concern with draft-ietf-pwe3-enet-mib-10 All, Since the PW-ENET MIB is heading for last call, I reviewed the MIB today. I realised that the MIB does not comply to the MEF's view of Ethernet E-line services. For more information on this definition, please refer to: http://www.metroethernetforum.org/PDFs/Standards/Overview_of_MEF_6_and_1 0.ppt I realise that this was not the stated intention of the MIB but I would like to see the gaps closed. Note that I believe this gap is small. We only need to address 3 issues: 1/ defining a default VLAN for the untagged and priority packets (this may already be possible) [DZ] Assigning a PW for the default VLAN and priority tagged packets can be supported by the PW-ENET-STD-MIB. 2/ define how L2CP protocols are handled (right now they are tunnelled). We need to add the capability to discard L2CP packets. I believe this is desirable on a per L2CP basis but I need to verify this. [DZ] I think that this part of the functionality is part of the NSP function. In addition, the MEF may change the specifications at any time, and there is no mutual process to synchronize the specifications. 3/ define a way to map p-bit / vlans to a PW. The rest are discarded. [DZ] I believe that this functionality is out of the scope of the PWE3 group (and as such from PWE3 MIB modules). Note also that traffic descriptors at the PW level (as exist in the MEF) are not defined as QOS issues are not defined within the group. I need to review this in more detail to make sure these are the only gaps. However, before I went through this effort, I wanted to bring this issue to the list. Do we see MEF compliance as an objective of the PW-ENET service? [DZ] There is no mutual process between the MEF and IETF to adjust the specifications. The MIB modules are derived from IETF specifications. If the specifications will changed, than we can adapt the MIB modules. Thanks David Please let me know, Ken ------_=_NextPart_001_01C77C01.D40F5493 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Concern = with draft-ietf-pwe3-enet-mib-10
Ken,
Please=20 see inside
 
From: Ken Young=20 [mailto:KenY@gridpointsystems.com]
Sent: Wednesday, April 04, = 2007=20 5:23 PM
To: Ken Young; David Zelig; = pwe3@ietf.org
Cc: Lyndon=20 Ong; tnadeau@cisco.com; Brian Smith; Chris Barrett
Subject: = RE:=20 Concern with draft-ietf-pwe3-enet-mib-10

David,

 

As I = previously stated,=20 I checked into the view of this from the MEF.  The MEF is remaining = at the=20 services level.  As such, they define the attributes of a = particular=20 service but not how it = gets=20 translated into a particular technology such as pseudowires.  The = MEF=20 definition is also a moving target. 

 

As such, I = agree that=20 we can not fix the change the scope of the current PW-ENET MIB to align = with the=20 MEF.
[DZ] OK.

 

However, it = should=20 align with the requirements of RFC4448.  Section 4.7 and Appendix B = state=20 that an Ethernet flow can be mapped to a pseudowire using the port, VLAN = and=20 p-bit values.  I would like to see this added to the PW-ENET = MIB.
[DZ] This = functionality do not=20 exist in any working implementation as far as the authors = know (also=20 verified on the PWE3 list few months ago - before we removed it). We = believe=20 that the MIB created by the group should reflect current working=20 practice.

 

Thanks

David

 

Thanks,

Ken

 

From:=20 Ken Young
Sent: March 22, 2007 10:04 = AM
To: David Zelig; = pwe3@ietf.org
Cc: Lyndon Ong; = tnadeau@cisco.com;=20 Brian=20 Smith; Chris=20 Barrett
Subject: RE: Concern with=20 draft-ietf-pwe3-enet-mib-10

 

David,

 

Thanks for resolving issue = 1. =20 That gets the list down to 2 outstanding=20 issues.

 

I agree with your comments = on issue=20 2.  L2CP discards should be provisioned as part of the NSP.  = Isn't=20 that what the PW-ENET-MIB is defining for these types of=20 PWs?

 

I hear your point on the = fact that=20 there is no process between the MEF and IETF on this issue.  I am = going to=20 raise this in the MEF technical community and get back to list on this=20 topic.

 

I personally believe this = is=20 important since the MEF is defining the customer facing attributes of an = Ethernet service offered by Service providers.  We have customers = demanding=20 that we be MEF certified to be able to sell our equipment.  I would = prefer=20 to use a standard MIB for this since this is not any part of our secret = sauce=20 and I think other companies will = benefit.

 

My 2=20 cents,

Ken

 

From: David=20 Zelig [mailto:Davidz@corrigent.com]
Sent: Thu 3/22/2007 = 08:18
To: Ken=20 Young; pwe3@ietf.org
Cc: Lyndon Ong; = tnadeau@cisco.com;=20 Brian=20 Smith; Chris=20 Barrett
Subject: RE: Concern with=20 draft-ietf-pwe3-enet-mib-10

Ken,
Please see = inside.

-----Original=20 Message-----
From: Ken = Young [mailto:KenY@gridpointsystems.co= m]
Sent:=20 Wednesday, March 21, 2007 12:07 AM
To: pwe3@ietf.org
Cc: Lyndon = Ong; David=20 Zelig; tnadeau@cisco.com; Brian Smith;=20 Chris
Barrett
Subject: Concern with=20 draft-ietf-pwe3-enet-mib-10

All,

Since the PW-ENET MIB is = heading=20 for last call, I reviewed the MIB
today.  I realised that the = MIB does=20 not comply to the MEF's view of
Ethernet E-line services.  For = more=20 information on this definition,
please refer to:

http://www.metroethernetforum.org/PDFs/Standards/Overview_of_MEF= _6_and_1
0.ppt
<https://webaccess.hostedmail.net/exchweb/bin= /redir.asp?URL=3Dhttp://www.m
etroethernetforum.org/PDFs/Standards/Ove= rview_of_MEF_6_and_10.ppt>

I=20 realise that this was not the stated intention of the MIB but I = would
like to=20 see the gaps closed.  Note that I believe this gap is small. =20 We
only need to address 3 issues:

1/  defining a default = VLAN for=20 the untagged and priority packets (this
may already be = possible)
[DZ]=20 Assigning a PW for the default VLAN and priority tagged packets = can
be=20 supported by the PW-ENET-STD-MIB.

2/  define how L2CP = protocols are=20 handled (right now they are
tunnelled).  We need to add the = capability=20 to discard L2CP packets.  I
believe this is desirable on a per = L2CP=20 basis but I need to verify this.
[DZ] I think that this part of the=20 functionality is part of the NSP
function. In addition, the MEF may = change=20 the specifications at any
time, and there is no mutual process to = synchronize=20 the specifications.

3/  define a way to map p-bit / vlans to = a=20 PW.  The rest are discarded.
[DZ] I believe that this = functionality is=20 out of the scope of the PWE3
group (and as such from PWE3 MIB = modules). Note=20 also that traffic
descriptors at the PW level (as exist in the MEF) = are not=20 defined as QOS
issues are not defined within the group.


I = need to=20 review this in more detail to make sure these are the = only
gaps. =20 However, before I went through this effort, I wanted to bring
this = issue to=20 the list.

Do we see MEF compliance as an objective of the PW-ENET = service?
[DZ] There is no mutual process between the MEF and IETF to = adjust=20 the
specifications. The MIB modules are derived from IETF = specifications.=20 If
the specifications will changed, than we can adapt the MIB=20 modules.

Thanks
David

Please let me=20 know,
Ken

------_=_NextPart_001_01C77C01.D40F5493-- --===============1805213979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1805213979==-- From pwe3-bounces@ietf.org Wed Apr 11 05:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZRk-0007H0-1P; Wed, 11 Apr 2007 05:49:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMrr-0000in-Rx; Mon, 02 Apr 2007 09:46:43 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYMrq-0008Vg-IM; Mon, 02 Apr 2007 09:46:43 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 4BA5C2AC9C; Mon, 2 Apr 2007 13:46:12 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HYMrM-00073T-2O; Mon, 02 Apr 2007 09:46:12 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: stbryant@cisco.com, danny@arbor.net, swallow@cisco.com, loa@pi.se From: Greg Jones (ITU-T SG 15) Message-Id: Date: Mon, 02 Apr 2007 09:46:12 -0400 X-Spam-Score: -2.3 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 11 Apr 2007 05:48:57 -0400 Cc: mpls@lists.ietf.org, , greg.jones@itu.int, pwe3@ietf.org, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, dward@cisco.com, tsbsg15@itu.int, townsley@cisco.com, betts01@nortel.com, Ghani.Abbas@ericsson.com Subject: [PWE3] New Liaison Statement, "Progress on G.8110.1 Amendment" X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsbsg15@itu.int, greg.jones@itu.int List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Title: Progress on G.8110.1 Amendment Submission Date: 2007-04-02 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=312 Please reply by 2007-06-01 From: Greg Jones(ITU-T SG 15) To: IETF PWE3 and MPLS Working Groups(stbryant@cisco.com, danny@arbor.net, swallow@cisco.com, loa@pi.se) Cc: sob@harvard.edu loa@pi.se jari.arkko@piuha.net townsley@cisco.com rcallon@juniper.net dward@cisco.com mpls@lists.ietf.org pwe3@ietf.org sjtrowbridge@alcatel-lucent.com; yoichi.maeda@ntt-at.co.jp betts01@nortel.com Ghani.Abbas@ericsson.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int Technical Contact: betts01@nortel.com Purpose: For comment Body: Q.12/15 thanks the MFA forum for the liaison on G.8110.1 Amendment 1. We also noted the liaison from the IETF mpls and pwe3 Working Groups which indicated that although they did not have time to fully review the draft amendment they did share the concerns expressed by the MFA forum. To address the concerns we have modified the text of the draft amendment as follows: • The description of point to multipoint has been enhanced, in particular Appendix V • A new clause 13 has been added describe security considerations. We have attached the revised version of the amendment for you to review. We intend to consent the amendment, based on this revised draft, at the June 2007 meeting of SG15. Attachment: Draft amendment 1 of G.8110.1 (WD12r4 Milan) Attachment(s): Progress on G.8110.1 Amendment - full text of liaison statement (https://datatracker.ietf.org/documents/LIAISON/file413.doc) Draft amendment 1 of G.8110.1 (WD12r4 Milan) (https://datatracker.ietf.org/documents/LIAISON/file414.doc) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Apr 11 20:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnJd-00036d-Rw; Wed, 11 Apr 2007 20:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnJa-00032D-SM; Wed, 11 Apr 2007 20:37:30 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbnJa-0002Hh-G9; Wed, 11 Apr 2007 20:37:30 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id l3C0bUhQ028936; Wed, 11 Apr 2007 17:37:30 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id l3C0bUk7028935; Wed, 11 Apr 2007 17:37:30 -0700 Date: Wed, 11 Apr 2007 17:37:30 -0700 Message-Id: <200704120037.l3C0bUk7028935@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 4842 on Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4842 Title: Synchronous Optical Network/Synchronous Digital Hierarchy SONET/SDH) Circuit Emulation over Packet (CEP) Author: A. Malis, P. Pate, R. Cohen, Ed., D. Zelig Status: Standards Track Date: April 2007 Mailbox: andrew.g.malis@verizon.com, prayson.pate@overturenetworks.com, ronc@resolutenetworks.com, davidz@corrigent.com Pages: 43 Characters: 96719 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-sonet-14.txt URL: http://www.rfc-editor.org/rfc/rfc4842.txt This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Apr 12 12:07:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1pb-0005vY-K7; Thu, 12 Apr 2007 12:07:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1pa-0005vO-UE for pwe3@ietf.org; Thu, 12 Apr 2007 12:07:31 -0400 Received: from tlvmail1.corrigent.com ([213.31.203.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc1pX-0003eK-3i for pwe3@ietf.org; Thu, 12 Apr 2007 12:07:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Thu, 12 Apr 2007 19:07:26 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813A78B4E@tlvmail1.corrigent.com> In-Reply-To: <94B3ADCC6E45544CA75307E399F4E94B01161ACD@MT-Mail.sycamorenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: AcdLAR1RjlreDJxYTYym8Wr1sA9tuQoA89sAABvRchAAUpwsYAAUCDHVAW6k1SAAlAahwA== References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B01161ACD@MT-Mail.sycamorenet.com> From: "David Zelig" To: "Suberri, Moshe" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 Cc: tnadeau@cisco.com, pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0492788708==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0492788708== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D1C.A605C51E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D1C.A605C51E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Moshe, The definition of the operstatus states are de-facto standard, therefore I believe that adding a new state is not feasible. The 'notPresent' state is rarely used otherwise so it is a good hint to look for configuration inconsistency. Note also that most of configuration inconsistencies/errors are already covered extensively in the service specific MIBs with detailed error coding. =20 Thanks David ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Monday, April 09, 2007 8:27 PM To: David Zelig; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 " 7. Relations to Other PWE3 MIB Modules . . . - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'." " =20 If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this class of errors. For example, adding a value of 'inconsistentConfiguration' or 'configurationError' will unambiguously identify the problem to the operator.=20 =20 =20 Regards Moshe =20 =20 =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. =20 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pwe3-pw-mib-10.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C77D1C.A605C51E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Moshe,
The=20 definition of the operstatus states are de-facto standard, therefore I = believe=20 that adding a new state is not feasible. The 'notPresent' state is = rarely=20 used otherwise so it is a good hint to look for configuration=20 inconsistency.
Note=20 also that most of configuration inconsistencies/errors are already = covered=20 extensively in the service specific MIBs with detailed error=20 coding.
 
Thanks
David

From: Suberri, Moshe=20 [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Monday, April = 09, 2007=20 8:27 PM
To: David Zelig; tnadeau@cisco.com
Cc:=20 pwe3@ietf.org
Subject: RE: [PWE3] I-D=20 ACTION:draft-ietf-pwe3-pw-mib-10.txt

“

7. =20 Relations to Other PWE3 MIB Modules

.

.

.

- =  Unless=20 all the necessary entries in the applicable tables have=20 been

  =20 created and all the parameters have been consistently configured=20 in

  =20 those tables, signaling cannot be performed from the local node,=20 and

  =20 the pwVcOperStatus should report = 'notPresent'.”

“

 

If = you want to=20 expand the definition of the Operational Status to include configuration = anomalies, it could be operationally helpful to uniquely qualify this = class of=20 errors. For example, adding a value of = ‘inconsistentConfiguration’ or=20 ‘configurationError’ will unambiguously identify the problem = to the operator.=20

 

 

Regards

Moshe =   

 

 

 

-----Original Message-----
From:=20 Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: = Wednesday,=20 February 07, 2007 3:50 PM
To: i-d-announce@ietf.org
Cc:=20 pwe3@ietf.org
Subject: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt=20

 

A New Internet-Draft is available from the = on-line=20 Internet-Drafts

directories.

This draft is a work item of the Pseudowire = Emulation=20 Edge to Edge Working Group of the IETF.

 

     =20 Title       : Pseudo Wire (PW) Management=20 Information Base

      = Author(s)   :=20 D. Zelig, et al.

     =20 Filename    :=20 draft-ietf-pwe3-pw-mib-10.txt

     =20 Pages       : = 63

     =20 Date        :=20 2007-2-7

     =20

This memo defines an experimental portion of = the=20 Management

   Information Base for use with = network=20 management protocols in the

   Internet community.  In = particular, it=20 describes managed objects for

   modeling of Pseudo Wire = Edge-to-Edge=20 services carried over a general

   Packet Switched=20 Network.

 

A URL for this Internet-Draft=20 is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt

 

To remove yourself from the I-D Announcement = list, send=20 a message to

i-d-announce-request@ietf.org with the word = unsubscribe=20 in the body of

the message.

You can also visit=20 https://www1.ietf.org/mailman/listinfo/I-D-announce=20

to change your subscription=20 settings.

 

Internet-Drafts are also available by = anonymous FTP.=20 Login with the

username "anonymous" and a password of your = e-mail=20 address. After

logging in, type "cd internet-drafts" and then =

"get=20 draft-ietf-pwe3-pw-mib-10.txt".

 

A list of Internet-Drafts directories can be = found=20 in

http://www.ietf.org/shadow.html=20

or=20 ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

Internet-Drafts can also be obtained by=20 e-mail.

 

Send a message = to:

     =20 mailserv@ietf.org.

In the body type:

      "FILE=20 /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".=

     =20

NOTE: The mail server at ietf.org can return = the=20 document in

      MIME-encoded = form by=20 using the "mpack" utility.  To use = this

      feature, insert = the=20 command "ENCODING mime" before the "FILE"

      command.  = To decode=20 the response(s), you will need "munpack" or

      a = MIME-compliant mail=20 reader.  Different MIME-compliant mail = readers

      exhibit = different=20 behavior, especially when dealing with

      "multipart" = MIME messages=20 (i.e. documents which have been split

      up into = multiple=20 messages), so check your local documentation = on

      how to = manipulate these=20 messages.

 

Below is the data which will enable a MIME = compliant=20 mail reader

implementation to automatically retrieve the = ASCII=20 version of the

Internet-Draft.

------_=_NextPart_001_01C77D1C.A605C51E-- --===============0492788708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0492788708==-- From pwe3-bounces@ietf.org Thu Apr 12 13:48:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3PT-0005ZV-BQ; Thu, 12 Apr 2007 13:48:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3PQ-0005ZL-Us for pwe3@ietf.org; Thu, 12 Apr 2007 13:48:36 -0400 Received: from zebra.sycamorenet.com ([12.146.0.145] helo=falcon.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3PO-0007dC-GH for pwe3@ietf.org; Thu, 12 Apr 2007 13:48:36 -0400 Received: from MT-Mail.sycamorenet.com ([192.168.200.86]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 13:47:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Thu, 12 Apr 2007 13:49:01 -0400 Message-ID: <94B3ADCC6E45544CA75307E399F4E94B011AF41A@MT-Mail.sycamorenet.com> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA0813A78B4E@tlvmail1.corrigent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: AcdLAR1RjlreDJxYTYym8Wr1sA9tuQoA89sAABvRchAAUpwsYAAUCDHVAW6k1SAAlAahwAACKKdA References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B01161ACD@MT-Mail.sycamorenet.com> <44F4E579A764584EA9BDFD07D0CA0813A78B4E@tlvmail1.corrigent.com> From: "Suberri, Moshe" To: "David Zelig" X-OriginalArrivalTime: 12 Apr 2007 17:47:53.0921 (UTC) FILETIME=[B2713310:01C77D2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 Cc: tnadeau@cisco.com, pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0714856116==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0714856116== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D2A.D050F21C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D2A.D050F21C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, =20 It is my understanding that the "Textual Conventions and for Managing Pseudo-Wires" is still a draft document.=20 =20 To be more specific, my concern is with the PW "payload size" and the "TDM rate". Since the "TDM Rate" is in one table and the "Payload size" is in another table, the proposed way to expose an inconsistency between the two objects is through the operational status. =20 If the operational status is cast in stone, the above inconsistency can be exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError object =20 Moshe =20 =20 =20 ________________________________ From: David Zelig [mailto:Davidz@corrigent.com]=20 Sent: Thursday, April 12, 2007 12:07 PM To: Suberri, Moshe Cc: pwe3@ietf.org; tnadeau@cisco.com Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 Moshe, The definition of the operstatus states are de-facto standard, therefore I believe that adding a new state is not feasible. The 'notPresent' state is rarely used otherwise so it is a good hint to look for configuration inconsistency. Note also that most of configuration inconsistencies/errors are already covered extensively in the service specific MIBs with detailed error coding. =20 Thanks David =20 ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Monday, April 09, 2007 8:27 PM To: David Zelig; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 " 7. Relations to Other PWE3 MIB Modules . . . - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'." " =20 If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this class of errors. For example, adding a value of 'inconsistentConfiguration' or 'configurationError' will unambiguously identify the problem to the operator.=20 =20 =20 Regards Moshe =20 =20 =20 =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. =20 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pwe3-pw-mib-10.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C77D2A.D050F21C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 

It is my understanding that the = “Textual Conventions and for Managing Pseudo-Wires” is still a draft = document.

 

To be more specific, my concern is with the PW “payload = size” and the “TDM rate”. Since the “TDM Rate” is in = one table and the “Payload size” is in another table, the proposed way = to expose an inconsistency between the two objects is through the = operational status.

 

If the operational status is cast in stone, the above = inconsistency can be exposed with a new bit (payloadSizeInconsistent) in the = pwTDMConfigError object

 

Moshe  

 

 

From: David = Zelig [mailto:Davidz@corrigent.com]
Sent: Thursday, April 12, = 2007 12:07 PM
To: Suberri, Moshe
Cc: pwe3@ietf.org; tnadeau@cisco.com
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

 

Moshe,

The definition of the operstatus = states are de-facto standard, therefore I believe that adding a new state is = not feasible. The 'notPresent' state is rarely used otherwise so it is = a good hint to look for configuration = inconsistency.

Note also that most of = configuration inconsistencies/errors are already covered extensively in the = service specific MIBs with detailed error coding.

 

Thanks

David

 

From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Monday, April 09, = 2007 8:27 PM
To: David Zelig; = tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

“

7.  Relations to Other PWE3 MIB Modules

.

.

.

- =  Unless all the necessary entries in the applicable tables have = been

   created and all the parameters have been consistently configured = in

   those tables, signaling cannot be performed from the local node, = and

   the pwVcOperStatus should report = 'notPresent'.”

“

 

If you = want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this = class of errors. For example, adding a value of = ‘inconsistentConfiguration’ or ‘configurationError’ will unambiguously identify the = problem to the operator.

 

 

Regards

Moshe   

 

 

 

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 PM
To: i-d-announce@ietf.org
Cc: pwe3@ietf.org
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =

 

A New Internet-Draft is available from the on-line = Internet-Drafts

directories.

This draft is a work item of the Pseudowire Emulation Edge to = Edge Working Group of the IETF.

 

      Title       : Pseudo Wire (PW) Management Information Base

      Author(s)   : D. Zelig, = et al.

      Filename    : draft-ietf-pwe3-pw-mib-10.txt

      Pages       : = 63

      Date        : = 2007-2-7

     

This memo defines an experimental portion of the = Management

   Information Base for use with network management = protocols in the

   Internet community.  In particular, it = describes managed objects for

   modeling of Pseudo Wire Edge-to-Edge services = carried over a general

   Packet Switched = Network.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt=

 

To remove yourself from the I-D Announcement list, send a = message to

i-d-announce-request@ietf.org with the word unsubscribe in the = body of

the message.

You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce =

to change your subscription = settings.

 

Internet-Drafts are also available by anonymous FTP. Login with = the

username "anonymous" and a password of your e-mail = address. After

logging in, type "cd internet-drafts" and then =

"get = draft-ietf-pwe3-pw-mib-10.txt".

 

A list of Internet-Drafts directories can be found = in

http://www.ietf.org/shadow.html

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

Internet-Drafts can also be obtained by = e-mail.

 

Send a message to:

      = mailserv@ietf.org.

In the body type:

      "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

     

NOTE: The mail server at ietf.org can return the document = in

      MIME-encoded form by using the "mpack" utility.  To use = this

      feature, insert the command "ENCODING mime" before the = "FILE"

      command.  To decode the response(s), you will need "munpack" = or

      a MIME-compliant mail = reader.  Different MIME-compliant mail readers

      exhibit different behavior, = especially when dealing with

      "multipart" MIME = messages (i.e. documents which have been split

      up into multiple messages), so = check your local documentation on

      how to manipulate these = messages.

 

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

------_=_NextPart_001_01C77D2A.D050F21C-- --===============0714856116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0714856116==-- From pwe3-bounces@ietf.org Thu Apr 12 14:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3oh-0002Yd-Rc; Thu, 12 Apr 2007 14:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3of-0002RN-4E for pwe3@ietf.org; Thu, 12 Apr 2007 14:14:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3o3-0005sB-VF for pwe3@ietf.org; Thu, 12 Apr 2007 14:14:05 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Apr 2007 11:14:00 -0700 X-IronPort-AV: i="4.14,403,1170662400"; d="scan'208,217"; a="410855582:sNHT230752338" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3CIE0JC023323; Thu, 12 Apr 2007 11:14:00 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3CIDdAk027207; Thu, 12 Apr 2007 18:13:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 14:13:56 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 14:13:55 -0400 In-Reply-To: <94B3ADCC6E45544CA75307E399F4E94B011AF41A@MT-Mail.sycamorenet.com> References: <94B3ADCC6E45544CA75307E399F4E94B010E6817@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D03A4DAA5@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B010E68C0@MT-Mail.sycamorenet.com> <457D36D9D89B5B47BC06DA869B1C815D2B14C3@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B01161ACD@MT-Mail.sycamorenet.com> <44F4E579A764584EA9BDFD07D0CA0813A78B4E@tlvmail1.corrigent.com> <94B3ADCC6E45544CA75307E399F4E94B011AF41A@MT-Mail.sycamorenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <98F4CECC-D708-4B5F-97AD-B39071E396FA@cisco.com> From: "Thomas D. Nadeau" Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Thu, 12 Apr 2007 14:13:54 -0400 To: "Suberri, Moshe" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Apr 2007 18:13:55.0692 (UTC) FILETIME=[55548AC0:01C77D2E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=56123; t=1176401640; x=1177265640; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20I-D=20ACTION=3Adraft-ietf-pwe3-pw-mib-10.txt =20 |Sender:=20; bh=vdocs8ltSowGSp6NQ6RT19tcpP0oqNIgqwoPNirb7JE=; b=Fv0WeLzaGMeXm3nYDAIV1TqolrPeZvQtWOHMO4QwmOpOzpSuw3YyZ4nlbMPwzRHjw/JPKr1t utKlWb3B46xVMKpFPwFNHpXqihSFmDF53Q+C1Dyd6WIOSXib1WmzzH3q; Authentication-Results: sj-dkim-5; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9afae6ba567a505fffabb76c1477f305 Cc: pwe3@ietf.org, David Zelig X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1820996178==" Errors-To: pwe3-bounces@ietf.org --===============1820996178== Content-Type: multipart/alternative; boundary=Apple-Mail-60-525938556 --Apple-Mail-60-525938556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed > David, > > > > It is my understanding that the =93Textual Conventions and for =20 > Managing Pseudo-Wires=94 is still a draft document. Yes, but there are a number of implementations of this draft, so = we =20 need to be careful about how we alter it. With that said, if something is totally broken we =20 need to fix it, but in this case, but I do not think that is the case here. > To be more specific, my concern is with the PW =93payload size=94 and =20= > the =93TDM rate=94. Since the =93TDM Rate=94 is in one table and the =20= > =93Payload size=94 is in another table, the proposed way to expose an =20= > inconsistency between the two objects is through the operational =20 > status. > > > > If the operational status is cast in stone, the above inconsistency =20= > can be exposed with a new bit (payloadSizeInconsistent) in the =20 > pwTDMConfigError object What it sounds like to me is that you are trying to uncover a =20= provisioning inconsistency. In this case, the agent can refuse to create the entry based on the =20 state of the other table. --Tom > Moshe > > > > > > From: David Zelig [mailto:Davidz@corrigent.com] > Sent: Thursday, April 12, 2007 12:07 PM > To: Suberri, Moshe > Cc: pwe3@ietf.org; tnadeau@cisco.com > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > > > Moshe, > > The definition of the operstatus states are de-facto standard, =20 > therefore I believe that adding a new state is not feasible. The =20 > 'notPresent' state is rarely used otherwise so it is a good hint to =20= > look for configuration inconsistency. > > Note also that most of configuration inconsistencies/errors are =20 > already covered extensively in the service specific MIBs with =20 > detailed error coding. > > > > Thanks > > David > > > > From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] > Sent: Monday, April 09, 2007 8:27 PM > To: David Zelig; tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > =93 > > 7. Relations to Other PWE3 MIB Modules > > . > > . > > . > > - Unless all the necessary entries in the applicable tables have been > > created and all the parameters have been consistently configured in > > those tables, signaling cannot be performed from the local node, =20= > and > > the pwVcOperStatus should report 'notPresent'.=94 > > =93 > > > > If you want to expand the definition of the Operational Status to =20 > include configuration anomalies, it could be operationally helpful =20 > to uniquely qualify this class of errors. For example, adding a =20 > value of =91inconsistentConfiguration=92 or =91configurationError=92 = will =20 > unambiguously identify the problem to the operator. > > > > > > Regards > > Moshe > > > > > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, February 07, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Pseudowire Emulation Edge to Edge =20 > Working Group of the IETF. > > > > Title : Pseudo Wire (PW) Management Information Base > > Author(s) : D. Zelig, et al. > > Filename : draft-ietf-pwe3-pw-mib-10.txt > > Pages : 63 > > Date : 2007-2-7 > > > > This memo defines an experimental portion of the Management > > Information Base for use with network management protocols in the > > Internet community. In particular, it describes managed objects =20= > for > > modeling of Pseudo Wire Edge-to-Edge services carried over a =20 > general > > Packet Switched Network. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-pwe3-pw-mib-10.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail =20 > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > --Apple-Mail-60-525938556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252

David,

It is my understanding = that the =93Textual Conventions and for = Managing Pseudo-Wires=94 is still a draft = document.


Yes, but there are a number of = implementations of this draft, so we need to be careful = about
how we alter it. With that said, if something is totally = broken we need to fix it, but in this case,
but I do not think = that is the case here.

To be more specific, my concern is with the PW = =93payload size=94 and the =93TDM rate=94. Since the =93TDM Rate=94 is = in one table and the =93Payload size=94 is in another table, the = proposed way to expose an inconsistency between the two objects is = through the operational status.

=A0

If = the operational status is cast in stone, the above inconsistency can be = exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError = object

What it = sounds like to me is that you are trying to uncover a provisioning = inconsistency.=A0
In this case, the agent can refuse to create = the entry based on the state of the other table.

= --Tom


Moshe=A0=A0

=A0

=A0

From: David Zelig [mailto:Davidz@corrigent.com] =
Thursday, April = 12, 2007 12:07 PM
Suberri, = Moshe
pwe3@ietf.org; tnadeau@cisco.com
RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

The definition of the = operstatus states are de-facto standard, therefore I believe that adding = a new state is not feasible.=A0The 'notPresent' state is rarely used = otherwise so it is a good hint to look for configuration = inconsistency.

Note also that most of = configuration inconsistencies/errors=A0are already covered extensively = in the service specific MIBs with detailed error = coding.=A0

Suberri, Moshe [mailto:Moshe.Suberri@sycamor= enet.com]
Monday, April 09, = 2007 8:27 PM
David Zelig; tnadeau@cisco.com
pwe3@ietf.org
RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=93

7.=A0 Relations to Other PWE3 MIB Modules

.

.

.

- =A0Unless = all the necessary entries in the applicable tables have been

=A0=A0 = created and all the parameters have been consistently configured = in

=A0=A0 those tables, signaling cannot be performed from the = local node, and

=A0=A0 the pwVcOperStatus should report = 'notPresent'.=94

=93

=A0

If you want to expand the definition of the Operational = Status to include configuration anomalies, it could be operationally = helpful to uniquely qualify this class of errors. For example, adding a = value of =91inconsistentConfiguration=92 or =91configurationError=92 = will unambiguously identify the problem to the operator.

=A0

=A0

RegardsMoshe = =A0=A0

=A0

=A0

=A0

-----Original = Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 = PM
To: i-d-announce@ietf.org
Cc: pwe3@ietf.org
Subject: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=A0

A New Internet-Draft is available = from the on-line Internet-Drafts

directories.This draft is = a work item of the Pseudowire Emulation Edge to Edge Working Group of = the IETF.

=A0

=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0= : Pseudo Wire (PW) Management Information Base=A0=A0=A0=A0=A0= Author(s)=A0=A0 : D. Zelig, et al.

=A0=A0=A0=A0=A0 Filename=A0=A0=A0 : = draft-ietf-pwe3-pw-mib-10.txt

=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0= : 63

=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0 : = 2007-2-7

=A0=A0=A0=A0=A0

This memo defines an experimental = portion of the Management

=A0=A0 Information Base for use = with network management protocols in the

=A0=A0 Internet community.=A0 In = particular, it describes managed objects for=A0=A0 = modeling of Pseudo Wire Edge-to-Edge services carried over a = general

=A0=A0 Packet Switched Network.=A0A URL for = this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt=A0To remove = yourself from the I-D Announcement list, send a message toi-d-announce-request@ietf.or= g with the word unsubscribe in the body ofthe = message.

You can also visit https://www1.= ietf.org/mailman/listinfo/I-D-announceto change = your subscription settings.

=A0

Internet-Drafts are also available = by anonymous FTP. Login with the

username "anonymous" and a password = of your e-mail address. After

logging in, type "cd = internet-drafts" and then

"get = draft-ietf-pwe3-pw-mib-10.txt".

=A0

A list of Internet-Drafts = directories can be found in

http://www.ietf.org/shadow.htmlor ftp://ftp.ietf.org/ietf= /1shadow-sites.txt

=A0

Internet-Drafts can also be = obtained by e-mail.

=A0

Send a message to:=A0=A0=A0=A0=A0= mailserv@ietf.org.In the body = type:

=A0=A0=A0=A0=A0 "FILE = /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

NOTE: The mail server at ietf.org = can return the document in

=A0=A0=A0=A0=A0 MIME-encoded form = by using the "mpack" utility.=A0 To use this=A0=A0=A0=A0=A0= feature, insert the command "ENCODING mime" before the = "FILE"

=A0=A0=A0=A0=A0 command.=A0 To decode the response(s), you = will need "munpack" or

=A0=A0=A0=A0=A0 a MIME-compliant = mail reader.=A0 Different MIME-compliant mail readers=A0=A0=A0=A0=A0= exhibit different behavior, especially when dealing with=A0=A0=A0=A0=A0= "multipart" MIME messages (i.e. documents which have been = split

=A0=A0=A0=A0=A0 up into multiple messages), so check your = local documentation on

=A0=A0=A0=A0=A0 how to manipulate = these messages.

=A0

Below is the data which will enable = a MIME compliant mail reader

implementation to automatically = retrieve the ASCII version of the

Internet-Draft.


<= /HTML>= --Apple-Mail-60-525938556-- --===============1820996178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1820996178==-- From pwe3-bounces@ietf.org Fri Apr 13 01:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEIn-0003h1-9u; Fri, 13 Apr 2007 01:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEIm-0003gw-D9 for pwe3@ietf.org; Fri, 13 Apr 2007 01:26:28 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEIh-0001In-AJ for pwe3@ietf.org; Fri, 13 Apr 2007 01:26:28 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 13 Apr 2007 08:26:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Fri, 13 Apr 2007 08:25:30 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> In-Reply-To: <98F4CECC-D708-4B5F-97AD-B39071E396FA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: Acd9LnlIwzzC4o1JT/+OaoBHTl0RXAAXCnAQ From: "Orly Nicklass" To: "Thomas D. Nadeau" , "Suberri, Moshe" X-Spam-Score: 0.0 (/) X-Scan-Signature: afe851332d75a6da8a5802c142db3390 Cc: David Zelig , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0325798851==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0325798851== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77D8C.442DE089" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77D8C.442DE089 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The inconsistency can be a result of single set operation where the agent has the complete set of values to verify integrity among them. As such, the set operation should fail with an error of 'inconsistentValue'. ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 Sent: Thursday, April 12, 2007 21:14 To: Suberri, Moshe Cc: pwe3@ietf.org; David Zelig Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =09 David, =09 It is my understanding that the "Textual Conventions and for Managing Pseudo-Wires" is still a draft document. Yes, but there are a number of implementations of this draft, so we need to be careful about how we alter it. With that said, if something is totally broken we need to fix it, but in this case, but I do not think that is the case here. =09 =09 To be more specific, my concern is with the PW "payload size" and the "TDM rate". Since the "TDM Rate" is in one table and the "Payload size" is in another table, the proposed way to expose an inconsistency between the two objects is through the operational status. =09 If the operational status is cast in stone, the above inconsistency can be exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError object What it sounds like to me is that you are trying to uncover a provisioning inconsistency.=20 In this case, the agent can refuse to create the entry based on the state of the other table. --Tom =09 =09 Moshe =20 =09 =09 =09 ________________________________ From: David Zelig [mailto:Davidz@corrigent.com]=20 Sent: Thursday, April 12, 2007 12:07 PM To: Suberri, Moshe Cc: pwe3@ietf.org; tnadeau@cisco.com Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =09 Moshe, The definition of the operstatus states are de-facto standard, therefore I believe that adding a new state is not feasible. The 'notPresent' state is rarely used otherwise so it is a good hint to look for configuration inconsistency. Note also that most of configuration inconsistencies/errors are already covered extensively in the service specific MIBs with detailed error coding. =09 Thanks David =09 =09 ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Monday, April 09, 2007 8:27 PM To: David Zelig; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt " 7. Relations to Other PWE3 MIB Modules . . . - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'." " =09 If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this class of errors. For example, adding a value of 'inconsistentConfiguration' or 'configurationError' will unambiguously identify the problem to the operator. =09 =09 Regards Moshe =20 =09 =09 =09 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt =09 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. =09 Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt =09 To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. =09 Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mib-10.txt". =09 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =09 Internet-Drafts can also be obtained by e-mail. =09 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C77D8C.442DE089 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 inconsistency can be a result of single set operation where the agent = has the=20 complete set of values to verify integrity among them. As such, the set=20 operation should fail with an error of=20 'inconsistentValue'.

From: Thomas D. Nadeau=20 [mailto:tnadeau@cisco.com]
Sent: Thursday, April 12, 2007=20 21:14
To: Suberri, Moshe
Cc: pwe3@ietf.org; David=20 Zelig
Subject: Re: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt=20

David,

It = is my=20 understanding that the “Textual Conventions and for = Managing=20 Pseudo-Wires” is still a draft = document.


Yes, but there are a number of = implementations=20 of this draft, so we need to be careful about
how we alter it. With that said, if something is totally broken we = need to=20 fix it, but in this case,
but I do not think that is the case here.

To be = more=20 specific, my concern is with the PW “payload size” and the = “TDM rate”. Since=20 the “TDM Rate” is in one table and the “Payload = size” is in another table, the=20 proposed way to expose an inconsistency between the two objects is = through the=20 operational status.

If the = operational=20 status is cast in stone, the above inconsistency can be exposed with a = new bit=20 (payloadSizeInconsistent) in the pwTDMConfigError=20 object

What = it sounds=20 like to me is that you are trying to uncover a provisioning=20 inconsistency. 
In this case, the agent can refuse to create the entry based on the = state=20 of the other table.

--Tom


Moshe  

From: David=20 Zelig [mailto:Davidz@corrigent.com]=20
Sent: Thursday,=20 April 12, 2007 12:07 PMTo: Suberri,=20 Moshe
Cc: pwe3@ietf.org; tnadeau@cisco.comSubject: RE:=20 [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

Moshe,

The = definition of the operstatus states are de-facto standard, therefore I = believe=20 that adding a new state is not feasible. The 'notPresent' state = is rarely=20 used otherwise so it is a good hint to look for configuration=20 inconsistency.

Note also=20 that most of configuration inconsistencies/errors are already = covered=20 extensively in the service specific MIBs with detailed error=20 coding.

Thanks

David

From: Suberri,=20 Moshe [mailto:Moshe.Suberri@sycamo= renet.com]=20
Sent: Monday,=20 April 09, 2007 8:27 PMTo: David=20 Zelig; tnadeau@cisco.comCc: pwe3@ietf.orgSubject: RE:=20 [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

“

7. =20 Relations to Other PWE3 MIB Modules

.

.

.

-=20  Unless all the necessary entries in the applicable tables have=20 been

  =20 created and all the parameters have been consistently configured = in

  =20 those tables, signaling cannot be performed from the local node,=20 and

  =20 the pwVcOperStatus should report 'notPresent'.”

“

If you=20 want to expand the definition of the Operational Status to include=20 configuration anomalies, it could be operationally helpful to uniquely = qualify=20 this class of errors. For example, adding a value of=20 ‘inconsistentConfiguration’ or = ‘configurationError’ will unambiguously=20 identify the problem to the operator.

Regards

Moshe=20   

-----Original=20 Message-----
From:=20 Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /A>]=20
Sent:=20 Wednesday, February 07, 2007 3:50 PMTo: i-d-announce@ietf.orgCc: pwe3@ietf.orgSubject: [PWE3] = I-D=20 ACTION:draft-ietf-pwe3-pw-mib-10.txt

A New = Internet-Draft is=20 available from the on-line Internet-Drafts

directories.

This draft is a = work item of=20 the Pseudowire Emulation Edge to Edge Working Group of the = IETF.

     =20 Title       : Pseudo Wire (PW) = Management=20 Information Base

     =20 Author(s)   : D. Zelig, et al.

     =20 Filename    : draft-ietf-pwe3-pw-mib-10.txt

     =20 Pages       : 63

     =20 Date        : 2007-2-7

     

This memo defines = an=20 experimental portion of the Management

   = Information=20 Base for use with network management protocols in the

   = Internet=20 community.  In particular, it describes managed objects = for

   = modeling of=20 Pseudo Wire Edge-to-Edge services carried over a general

   = Packet Switched=20 Network.

A URL for this=20 Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt

To remove yourself = from the=20 I-D Announcement list, send a message to

i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of

the = message.

You can also visit = https://www1= .ietf.org/mailman/listinfo/I-D-announce

to change your = subscription=20 settings.

Internet-Drafts = are also=20 available by anonymous FTP. Login with the

username = "anonymous" and a=20 password of your e-mail address. After

logging in, type = "cd=20 internet-drafts" and then

"get=20 draft-ietf-pwe3-pw-mib-10.txt".

A list of = Internet-Drafts=20 directories can be found in

http://www.ietf.org/shadow.html<= /A>

or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts = can also be=20 obtained by e-mail.

Send a message=20 to:

     =20 mailserv@ietf.org.

In the body = type:

     =20 "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

     

NOTE: The mail = server at=20 ietf.org can return the document in

     =20 MIME-encoded form by using the "mpack" utility.  To use = this

     =20 feature, insert the command "ENCODING mime" before the = "FILE"

     =20 command.  To decode the response(s), you will need "munpack"=20 or

     =20 a MIME-compliant mail reader.  Different MIME-compliant mail=20 readers

     =20 exhibit different behavior, especially when dealing with

     =20 "multipart" MIME messages (i.e. documents which have been = split

     =20 up into multiple messages), so check your local documentation = on

     =20 how to manipulate these messages.

Below is the data = which will=20 enable a MIME compliant mail reader

implementation to=20 automatically retrieve the ASCII version of the

Internet-Draft.


------_=_NextPart_001_01C77D8C.442DE089-- --===============0325798851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0325798851==-- From pwe3-bounces@ietf.org Fri Apr 13 10:49:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN4w-0005iF-Fx; Fri, 13 Apr 2007 10:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN4u-0005hv-CI for pwe3@ietf.org; Fri, 13 Apr 2007 10:48:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcN4t-0006Jc-7D for pwe3@ietf.org; Fri, 13 Apr 2007 10:48:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Apr 2007 10:48:44 -0400 X-IronPort-AV: i="4.14,408,1170651600"; d="scan'208,217"; a="57570547:sNHT212155368" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DEmg0r010154; Fri, 13 Apr 2007 10:48:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3DEm7Gv024394; Fri, 13 Apr 2007 14:48:38 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:48:31 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:48:30 -0400 In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> References: <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <13A2DE15-CC7F-4D79-A209-9E7EE018FCCA@cisco.com> From: "Thomas D. Nadeau" Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Fri, 13 Apr 2007 10:48:29 -0400 To: Orly Nicklass X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 14:48:31.0056 (UTC) FILETIME=[CDB01500:01C77DDA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=53950; t=1176475722; x=1177339722; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20I-D=20ACTION=3Adraft-ietf-pwe3-pw-mib-10.txt =20 |Sender:=20 |To:=20Orly=20Nicklass=20; bh=b8BkZ5U9FE2WPqPCmRruR0Duz+P5Z/dGGou0/B0fG7c=; b=XxZRSMNfnlaj98om2Y8xya2Ee+N/xPpQsNA/dtffQk3Vo1ZHKGrS9BL3P9/2wB5qXRayFD8w RhWLTfSMaFKD9rr6s4K/eEWzO13N2KHxOGAvGlqvkG8+htpvozdeoKXA; Authentication-Results: rtp-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: df82e91619cd4cb8e8215e3592fa9e0b Cc: David Zelig , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0017995999==" Errors-To: pwe3-bounces@ietf.org --===============0017995999== Content-Type: multipart/alternative; boundary=Apple-Mail-66-600013989 --Apple-Mail-66-600013989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Precisely my point. --Tom > The inconsistency can be a result of single set operation where the =20= > agent has the complete set of values to verify integrity among =20 > them. As such, the set operation should fail with an error of =20 > 'inconsistentValue'. > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, April 12, 2007 21:14 > To: Suberri, Moshe > Cc: pwe3@ietf.org; David Zelig > Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > >> David, >> >> >> It is my understanding that the =93Textual Conventions and for =20 >> Managing Pseudo-Wires=94 is still a draft document. > > Yes, but there are a number of implementations of this draft, so we =20= > need to be careful about > how we alter it. With that said, if something is totally broken we =20 > need to fix it, but in this case, > but I do not think that is the case here. >> >> To be more specific, my concern is with the PW =93payload size=94 and = =20 >> the =93TDM rate=94. Since the =93TDM Rate=94 is in one table and the =20= >> =93Payload size=94 is in another table, the proposed way to expose an = =20 >> inconsistency between the two objects is through the operational =20 >> status. >> >> >> If the operational status is cast in stone, the above =20 >> inconsistency can be exposed with a new bit =20 >> (payloadSizeInconsistent) in the pwTDMConfigError object > What it sounds like to me is that you are trying to uncover a =20 > provisioning inconsistency. > In this case, the agent can refuse to create the entry based on the =20= > state of the other table. > > --Tom > > >> >> Moshe >> >> >> >> From: David Zelig [mailto:Davidz@corrigent.com] >> Sent: Thursday, April 12, 2007 12:07 PM >> To: Suberri, Moshe >> Cc: pwe3@ietf.org; tnadeau@cisco.com >> Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt >> >> >> Moshe, >> >> The definition of the operstatus states are de-facto standard, =20 >> therefore I believe that adding a new state is not feasible. The =20 >> 'notPresent' state is rarely used otherwise so it is a good hint =20 >> to look for configuration inconsistency. >> >> Note also that most of configuration inconsistencies/errors are =20 >> already covered extensively in the service specific MIBs with =20 >> detailed error coding. >> >> >> Thanks >> >> David >> >> >> From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] >> Sent: Monday, April 09, 2007 8:27 PM >> To: David Zelig; tnadeau@cisco.com >> Cc: pwe3@ietf.org >> Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt >> >> =93 >> >> 7. Relations to Other PWE3 MIB Modules >> >> . >> >> . >> >> . >> >> - Unless all the necessary entries in the applicable tables have =20 >> been >> >> created and all the parameters have been consistently =20 >> configured in >> >> those tables, signaling cannot be performed from the local =20 >> node, and >> >> the pwVcOperStatus should report 'notPresent'.=94 >> >> =93 >> >> >> If you want to expand the definition of the Operational Status to =20 >> include configuration anomalies, it could be operationally helpful =20= >> to uniquely qualify this class of errors. For example, adding a =20 >> value of =91inconsistentConfiguration=92 or =91configurationError=92 = will =20 >> unambiguously identify the problem to the operator. >> >> >> >> Regards >> >> Moshe >> >> >> >> >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Wednesday, February 07, 2007 3:50 PM >> To: i-d-announce@ietf.org >> Cc: pwe3@ietf.org >> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> This draft is a work item of the Pseudowire Emulation Edge to Edge =20= >> Working Group of the IETF. >> >> >> Title : Pseudo Wire (PW) Management Information Base >> >> Author(s) : D. Zelig, et al. >> >> Filename : draft-ietf-pwe3-pw-mib-10.txt >> >> Pages : 63 >> >> Date : 2007-2-7 >> >> >> >> This memo defines an experimental portion of the Management >> >> Information Base for use with network management protocols in the >> >> Internet community. In particular, it describes managed =20 >> objects for >> >> modeling of Pseudo Wire Edge-to-Edge services carried over a =20 >> general >> >> Packet Switched Network. >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt >> >> >> To remove yourself from the I-D Announcement list, send a message to >> >> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >> body of >> >> the message. >> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >> announce >> >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> >> username "anonymous" and a password of your e-mail address. After >> >> logging in, type "cd internet-drafts" and then >> >> "get draft-ietf-pwe3-pw-mib-10.txt". >> >> >> A list of Internet-Drafts directories can be found in >> >> http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> >> Send a message to: >> >> mailserv@ietf.org. >> >> In the body type: >> >> "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". >> >> >> >> NOTE: The mail server at ietf.org can return the document in >> >> MIME-encoded form by using the "mpack" utility. To use this >> >> feature, insert the command "ENCODING mime" before the "FILE" >> >> command. To decode the response(s), you will need "munpack" or >> >> a MIME-compliant mail reader. Different MIME-compliant mail =20= >> readers >> >> exhibit different behavior, especially when dealing with >> >> "multipart" MIME messages (i.e. documents which have been split >> >> up into multiple messages), so check your local =20 >> documentation on >> >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> >> implementation to automatically retrieve the ASCII version of the >> >> Internet-Draft. >> >> > --Apple-Mail-66-600013989 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
Precisely = my point.

= --Tom

The inconsistency can be a = result of single set operation where the agent has the complete set of = values to verify integrity among them. As such, the set operation should = fail with an error of 'inconsistentValue'.

=
From: = Thomas D. Nadeau [mailto:tnadeau@cisco.com] =
Sent: Thursday, April 12, 2007 21:14
To: Suberri, = Moshe
Cc: pwe3@ietf.org; = David Zelig
Subject: Re: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=

David,

It is = my understanding that the =93Textual Conventions and for Managing Pseudo-Wires=94 is still a = draft document.


Yes, but there are a number of = implementations of this draft, so we need to be careful about
=
how we alter it. With that said, if something is totally broken we = need to fix it, but in this case,
but I do not think that is = the case here.

To be more specific, my concern is with the PW =93payload = size=94 and the =93TDM rate=94. Since the =93TDM Rate=94 is in one = table and the =93Payload size=94 is in another table, the proposed way = to expose an inconsistency between the two objects is through the = operational status.

If the operational status is = cast in stone, the above inconsistency can be exposed with a new bit = (payloadSizeInconsistent) in the pwTDMConfigError = object

What it = sounds like to me is that you are trying to uncover a provisioning = inconsistency.=A0
In this case, the agent can refuse to = create the entry based on the state of the other table.

--Tom
=


Moshe=A0=A0

From: David Zelig [mailto:Davidz@corrigent.com] =
Sent: Thursday, April 12, 2007 12:07 PM
To: Suberri, = Moshe
Cc: pwe3@ietf.org; tnadeau@cisco.com
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=

Moshe,

The = definition of the operstatus states are de-facto standard, therefore I = believe that adding a new state is not feasible.=A0The 'notPresent' = state is rarely used otherwise so it is a good hint to look for = configuration inconsistency.

Note also that most of configuration = inconsistencies/errors=A0are already covered extensively in the = service specific MIBs with detailed error = coding.

Thanks

David

From: Suberri, Moshe [mailto:Moshe.Suberri@sycamor= enet.com]
Sent: Monday, April 09, 2007 8:27 PM
To: David Zelig; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=93

7.=A0 Relations to Other PWE3 MIB Modules

.

.

.

- =A0Unless all the necessary = entries in the applicable tables have been

=A0=A0 created and all the = parameters have been consistently configured in

=A0=A0 those tables, signaling = cannot be performed from the local node, and

=A0=A0 the pwVcOperStatus = should report 'notPresent'.=94

=93

If you want to expand the = definition of the Operational Status to include configuration = anomalies, it could be operationally helpful to uniquely qualify this = class of errors. For example, adding a value of = =91inconsistentConfiguration=92 or =91configurationError=92 will = unambiguously identify the problem to the operator.

Regards

Moshe =A0=A0

-----Original Message-----
From: Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 = PM
To: i-d-announce@ietf.org
Cc: pwe3@ietf.org
Subject: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

A New Internet-Draft = is available from the on-line Internet-Drafts

directories.

This draft is a work = item of the Pseudowire Emulation Edge to Edge Working Group of the = IETF.

=A0=A0=A0=A0=A0 = Title=A0=A0=A0=A0=A0=A0 : Pseudo Wire (PW) Management Information = Base

=A0=A0=A0=A0=A0 = Author(s)=A0=A0 : D. Zelig, et al.

=A0=A0=A0=A0=A0 Filename=A0=A0=A0 : = draft-ietf-pwe3-pw-mib-10.txt

=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0 : 63

=A0=A0=A0=A0=A0 = Date=A0=A0=A0=A0=A0=A0=A0 : 2007-2-7

=A0=A0=A0=A0=A0

This memo defines an experimental portion of the = Management

=A0=A0 Information = Base for use with network management protocols in the

=A0=A0 Internet = community.=A0 In particular, it describes managed objects for

=A0=A0 modeling of = Pseudo Wire Edge-to-Edge services carried over a general

=A0=A0 Packet = Switched Network.

A URL for this = Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt

To remove yourself = from the I-D Announcement list, send a message to

i-d-announce-request@ietf.or= g with the word unsubscribe in the body of

the = message.

You can also visit = https://www1.= ietf.org/mailman/listinfo/I-D-announce

to change your subscription settings.

Internet-Drafts are = also available by anonymous FTP. Login with the

username "anonymous" = and a password of your e-mail address. After

logging in, type "cd = internet-drafts" and then

"get draft-ietf-pwe3-pw-mib-10.txt".

A list of = Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt

Internet-Drafts can = also be obtained by e-mail.

Send a message = to:

=A0=A0=A0=A0=A0 mailserv@ietf.org.

In the body = type:

=A0=A0=A0=A0=A0 = "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

=A0=A0=A0=A0=A0=

NOTE: The mail = server at ietf.org can return the document in

=A0=A0=A0=A0=A0 = MIME-encoded form by using the "mpack" utility.=A0 To use = this

=A0=A0=A0=A0=A0 = feature, insert the command "ENCODING mime" before the "FILE"

=A0=A0=A0=A0=A0 = command.=A0 To decode the response(s), you will need "munpack" = or

=A0=A0=A0=A0=A0 a = MIME-compliant mail reader.=A0 Different MIME-compliant mail = readers

=A0=A0=A0=A0=A0 = exhibit different behavior, especially when dealing with

=A0=A0=A0=A0=A0 = "multipart" MIME messages (i.e. documents which have been = split

=A0=A0=A0=A0=A0 up = into multiple messages), so check your local documentation on

=A0=A0=A0=A0=A0 = how to manipulate these messages.

Below is the data = which will enable a MIME compliant mail reader

implementation to = automatically retrieve the ASCII version of the

Internet-Draft.




= --Apple-Mail-66-600013989-- --===============0017995999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0017995999==-- From pwe3-bounces@ietf.org Fri Apr 13 11:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNYI-0006Hi-MN; Fri, 13 Apr 2007 11:19:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNYG-0006Hc-Kp for pwe3@ietf.org; Fri, 13 Apr 2007 11:19:04 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNYE-0000am-Gg for pwe3@ietf.org; Fri, 13 Apr 2007 11:19:04 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:19:01 +0100 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:19:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Fri, 13 Apr 2007 16:19:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: Acd93xATp9k2+UZ1Q5ifHZKmzxv+0Q== From: To: X-OriginalArrivalTime: 13 Apr 2007 15:19:01.0614 (UTC) FILETIME=[10C910E0:01C77DDF] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org =09 > Folks, > As discussed in the meeting, I'd like to solicit WG feedback on > adopting this as a WG document. If you're in favor or opposed > to adopting this please speak up now. >=20 > -danny I support draft-bryant-pwe3-mpls-transport becoming a WG document as it provides a mechanism for transporting one party's MPLS network over another's (which we have a requirement for) using existing deployed technology. Ben --=20 Ben Niven-Jenkins Network Architect, BT =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Apr 13 11:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNr2-0003mR-VW; Fri, 13 Apr 2007 11:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNr1-0003m9-AJ for pwe3@ietf.org; Fri, 13 Apr 2007 11:38:27 -0400 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=enfismtp2.datcon.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcNqz-0001Wr-VX for pwe3@ietf.org; Fri, 13 Apr 2007 11:38:27 -0400 Received: from enfimail2.datcon.co.uk ([172.19.14.250]) by enfismtp2.datcon.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:38:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 16:38:24 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB101488E8A@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-pw-mib-10 - fcsRetentionFcsStatus thread-index: Acd94cX1F2+iCRa1TrGrAkrIsgvY6A== From: "Ben Wright" To: "Corrigent - David Zelig" X-OriginalArrivalTime: 13 Apr 2007 15:38:24.0849 (UTC) FILETIME=[C620A410:01C77DE1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Cisco - Thomas Nadeau , pwe3@ietf.org Subject: [PWE3] draft-ietf-pwe3-pw-mib-10 - fcsRetentionFcsStatus X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi David,=20 I have a query about th fcsRetentionFcsSizeMismatch bit in the = fcsRetentionFcsStatus field. The description says is "Set if there is = an FCS size mismatch between the local and the peer node." By RFC 4623, each node signals an interface parameter indicating whether = they support fragmentation. However, this parameter doesn't contain the = configured FCS size. Given this, how does a PE router learn that there = has been an FCS size mismatch? =20 Cheers,=20 Ben=20 Ben Wright Network Protocols Division Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mailto:ben.wright@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Apr 13 12:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOX9-0008AX-Qi; Fri, 13 Apr 2007 12:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOX7-00087R-41 for pwe3@ietf.org; Fri, 13 Apr 2007 12:21:57 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOWE-00079G-TN for pwe3@ietf.org; Fri, 13 Apr 2007 12:21:07 -0400 Received: from I2KF03CV-UKBR.domain1.systemhost.net ([193.113.197.44]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 17:21:02 +0100 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by I2KF03CV-UKBR.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Apr 2007 17:21:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Fri, 13 Apr 2007 17:19:26 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C337BDD@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: Acd93xATp9k2+UZ1Q5ifHZKmzxv+0QABkUvw From: To: X-OriginalArrivalTime: 13 Apr 2007 16:21:01.0995 (UTC) FILETIME=[BA4E27B0:01C77DE7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Agreed Ben....operators need a method to carry the MPLS layer network of one party over the MPLS layer network of another party in a transparent client/server manner, ie the client and server layer MPLS networks are functionally decoupled. Stewart's draft is showing one way to achieve this using existing mechanisms based on PWs. So, from this 'requirement perspective' I also support the draft becoming a WG document....though I should add that I can think of other ways to achieve this and so we should also be open to consider alternatives in the future.=20 regards, Neil BT Global Services CTO=20 > -----Original Message----- > From: benjamin.niven-jenkins@bt.com=20 > [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: 13 April 2007 16:19 > To: pwe3@ietf.org > Subject: [PWE3] Fwd: I-D=20 > ACTION:draft-bryant-pwe3-mpls-transport-00.txt >=20 >=20 > =09 > > Folks, > > As discussed in the meeting, I'd like to solicit WG feedback on > > adopting this as a WG document. If you're in favor or opposed > > to adopting this please speak up now. > >=20 > > -danny >=20 > I support draft-bryant-pwe3-mpls-transport becoming a WG=20 > document as it provides a mechanism for transporting one=20 > party's MPLS network over another's (which we have a=20 > requirement for) using existing deployed technology. >=20 > Ben >=20 > --=20 > Ben Niven-Jenkins > Network Architect, BT > =20 > E-mail: benjamin.niven-jenkins@bt.com=20 > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Apr 15 08:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd48z-0003o3-LL; Sun, 15 Apr 2007 08:47:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd48y-0003ny-8E for pwe3@ietf.org; Sun, 15 Apr 2007 08:47:48 -0400 Received: from tlvmail1.corrigent.com ([213.31.203.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd48w-0004sT-Mc for pwe3@ietf.org; Sun, 15 Apr 2007 08:47:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Apr 2007 15:47:40 +0300 Message-ID: <44F4E579A764584EA9BDFD07D0CA0813A78C80@tlvmail1.corrigent.com> In-Reply-To: <8AC1AD08D396174DBC4E6D44EFACCFB101488E8A@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-pw-mib-10 - fcsRetentionFcsStatus Thread-Index: Acd94cX1F2+iCRa1TrGrAkrIsgvY6ABd6Ymg References: <8AC1AD08D396174DBC4E6D44EFACCFB101488E8A@enfimail2.datcon.co.uk> From: "David Zelig" To: "Ben Wright" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Cisco - Thomas Nadeau , pwe3@ietf.org Subject: [PWE3] RE: draft-ietf-pwe3-pw-mib-10 - fcsRetentionFcsStatus X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Ben, PWE3 Fragmentation is defined in RFC 4720 (not 4623), and there is error (or more precisely status in LDP signaling and error in L2TPv3 signaling) if the size is not compatible between peers. I assumed that the actual size is not part of the pw set of MIBs since the FCS size is known to the agent from the interface configuration. However in the fragmentation text in PW TC MIB I see some error in PwFragStatus reference to FCS size configuration (this has confused you with RFC 4623?). For fragmentation size configuration there are differences between LDP and L2TPv3 signaling that should be captured in the text. I will fix both texts in the following versions. Thanks David -----Original Message----- From: Ben Wright [mailto:BenTWright@dataconnection.com]=20 Sent: Friday, April 13, 2007 6:38 PM To: David Zelig Cc: Cisco - Thomas Nadeau; pwe3@ietf.org Subject: draft-ietf-pwe3-pw-mib-10 - fcsRetentionFcsStatus Hi David,=20 I have a query about th fcsRetentionFcsSizeMismatch bit in the fcsRetentionFcsStatus field. The description says is "Set if there is an FCS size mismatch between the local and the peer node." By RFC 4623, each node signals an interface parameter indicating whether they support fragmentation. However, this parameter doesn't contain the configured FCS size. Given this, how does a PE router learn that there has been an FCS size mismatch? =20 Cheers,=20 Ben=20 Ben Wright Network Protocols Division Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Fax: +44 20 8363 1039 Email: mailto:ben.wright@dataconnection.com Web: http://www.dataconnection.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Mon Apr 16 11:53:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTWM-0006sj-BN; Mon, 16 Apr 2007 11:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTWK-0006se-Qd for pwe3@ietf.org; Mon, 16 Apr 2007 11:53:36 -0400 Received: from zebra.sycamorenet.com ([12.146.0.145] helo=falcon.sycamorenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTWG-0001VI-Nc for pwe3@ietf.org; Mon, 16 Apr 2007 11:53:36 -0400 Received: from MT-Mail.sycamorenet.com ([192.168.200.86]) by falcon.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 11:52:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Mon, 16 Apr 2007 11:53:57 -0400 Message-ID: <94B3ADCC6E45544CA75307E399F4E94B011AFEB4@MT-Mail.sycamorenet.com> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Thread-Index: Acd9LnlIwzzC4o1JT/+OaoBHTl0RXAAXCnAQAKy10aA= References: <98F4CECC-D708-4B5F-97AD-B39071E396FA@cisco.com> <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> From: "Suberri, Moshe" To: "Orly Nicklass" , "Thomas D. Nadeau" X-OriginalArrivalTime: 16 Apr 2007 15:52:48.0921 (UTC) FILETIME=[4864D090:01C7803F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f41f23a95082876d5057edbae3c46bb Cc: David Zelig , pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1471059265==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1471059265== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7803F.68739BBE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7803F.68739BBE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I still feel that the reporting of 'inconsistent configuration' through 'notPresent' in the pwVcOperStatus, is not at all intuitive.=20 A bit in the pwTDMConfigError will do the same job and will be much more self explanatory and intuitive. After all, the pwTDMConfigError object supposes to report configuration related errors and the 'inconsistent configuration' is such an issue.=20 =20 =20 Moshe . . =20 =20 ________________________________ From: Orly Nicklass [mailto:orly_n@rad.com]=20 Sent: Friday, April 13, 2007 1:26 AM To: Thomas D. Nadeau; Suberri, Moshe Cc: pwe3@ietf.org; David Zelig Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =20 The inconsistency can be a result of single set operation where the agent has the complete set of values to verify integrity among them. As such, the set operation should fail with an error of 'inconsistentValue'. =20 ________________________________ From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 Sent: Thursday, April 12, 2007 21:14 To: Suberri, Moshe Cc: pwe3@ietf.org; David Zelig Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt=20 =09 David, It is my understanding that the "Textual Conventions and for Managing Pseudo-Wires" is still a draft document. =20 Yes, but there are a number of implementations of this draft, so we need to be careful about how we alter it. With that said, if something is totally broken we need to fix it, but in this case, but I do not think that is the case here. To be more specific, my concern is with the PW "payload size" and the "TDM rate". Since the "TDM Rate" is in one table and the "Payload size" is in another table, the proposed way to expose an inconsistency between the two objects is through the operational status. If the operational status is cast in stone, the above inconsistency can be exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError object What it sounds like to me is that you are trying to uncover a provisioning inconsistency.=20 In this case, the agent can refuse to create the entry based on the state of the other table. =20 --Tom =20 Moshe =20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>=20 From: David Zelig [mailto:Davidz@corrigent.com]=20 Sent: Thursday, April 12, 2007 12:07 PM To: Suberri, Moshe Cc: pwe3@ietf.org; tnadeau@cisco.com Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Moshe, The definition of the operstatus states are de-facto standard, therefore I believe that adding a new state is not feasible. The 'notPresent' state is rarely used otherwise so it is a good hint to look for configuration inconsistency. Note also that most of configuration inconsistencies/errors are already covered extensively in the service specific MIBs with detailed error coding. Thanks David ________________________________ From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]=20 Sent: Monday, April 09, 2007 8:27 PM To: David Zelig; tnadeau@cisco.com Cc: pwe3@ietf.org Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt " 7. Relations to Other PWE3 MIB Modules . . . - Unless all the necessary entries in the applicable tables have been created and all the parameters have been consistently configured in those tables, signaling cannot be performed from the local node, and the pwVcOperStatus should report 'notPresent'." " If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely qualify this class of errors. For example, adding a value of 'inconsistentConfiguration' or 'configurationError' will unambiguously identify the problem to the operator. Regards Moshe =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, February 07, 2007 3:50 PM To: i-d-announce@ietf.org Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-pw-mib-10.txt Pages : 63 Date : 2007-2-7 =20 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 ------_=_NextPart_001_01C7803F.68739BBE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I still feel that the reporting of = ‘inconsistent configuration’ through ‘notPresent' in the pwVcOperStatus, is not at all intuitive.

A bit in the pwTDMConfigError will do the same job and will be = much more self explanatory and intuitive. After all, the pwTDMConfigError object supposes to report configuration related errors and = the ‘inconsistent configuration’ is such an issue.

 

 

Moshe

. . =  

 

From: Orly = Nicklass [mailto:orly_n@rad.com]
Sent: Friday, April 13, = 2007 1:26 AM
To: Thomas D. Nadeau; = Suberri, Moshe
Cc: pwe3@ietf.org; David = Zelig
Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

 

The inconsistency can be a result = of single set operation where the agent has the complete set of values to = verify integrity among them. As such, the set operation should fail with an = error of 'inconsistentValue'.

 

From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Thursday, April 12, = 2007 21:14
To: Suberri, Moshe
Cc: pwe3@ietf.org; David = Zelig
Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

David,

It is my understanding that the = “Textual Conventions and for = Managing Pseudo-Wires” is still a draft document.

 

Yes, but there are a number of implementations of this draft, so = we need to be careful about

how we alter it. With that said, if something is totally broken = we need to fix it, but in this case,

but I do not think that is the case here.

To be more specific, my concern is with the = PW “payload size” and the “TDM rate”. Since the = “TDM Rate” is in one table and the “Payload size” is in = another table, the proposed way to expose an inconsistency between the two = objects is through the operational status.

If the operational status is cast in stone, the above inconsistency can be = exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError = object

What it sounds like to me is that you are trying to uncover a provisioning inconsistency. 

In this case, the agent can refuse to create the entry based on = the state of the other table.

 

--Tom

 



Moshe  

size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

From: David Zelig = [mailto:Davidz@corrigent.com] =
Sent: Thursday, April 12, 2007 12:07 PM
To: Suberri, Moshe
Cc: pwe3@ietf.org; tnadeau@cisco.com
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

Moshe,

The definition = of the operstatus states are de-facto standard, therefore I believe that adding = a new state is not feasible. The 'notPresent' state is rarely used = otherwise so it is a good hint to look for configuration = inconsistency.

Note also that = most of configuration inconsistencies/errors are already covered = extensively in the service specific MIBs with detailed error = coding.

Thanks

David

From: Suberri, = Moshe [mailto:Moshe.Suberri@sycamo= renet.com]
Sent: Monday, April 09, 2007 8:27 PM
To: David Zelig; tnadeau@cisco.com
Cc: pwe3@ietf.org
Subject: RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

“

7.  Relations to Other PWE3 MIB Modules

.

.

.

-  Unless all the necessary entries in the applicable tables have = been

   created and all the parameters have been consistently configured in

   those tables, signaling cannot be performed from the local node, and

   the pwVcOperStatus should report 'notPresent'.”

“

If you want to expand the definition of the Operational Status to include configuration anomalies, it could be operationally helpful to uniquely = qualify this class of errors. For example, adding a value of ‘inconsistentConfiguration’ or = ‘configurationError’ will unambiguously identify the problem to the operator.

Regards

Moshe   

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org<= /a>]
Sent: Wednesday, February 07, 2007 3:50 = PM
To: i-d-announce@ietf.org Cc: pwe3@ietf.org
Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt

=

A New Internet-Draft is available from the = on-line Internet-Drafts

=

directories.

=

This draft is a work item of the Pseudowire Emulation Edge = to Edge Working Group of the IETF.

=

      Title       : Pseudo Wire (PW) Management Information Base

=

      Author(s)   : D. = Zelig, et al.

=

      Filename    : draft-ietf-pwe3-pw-mib-10.txt

=

      Pages       : 63

=

      Date        : 2007-2-7

=

     

=

This memo defines an experimental portion of the = Management

=

   Information Base for use with network = management protocols in the

=

   Internet community.  In particular, it = describes managed objects for

=

   modeling of Pseudo Wire Edge-to-Edge services = carried over a general

=

   Packet Switched Network.

=

A URL for this Internet-Draft is:

=

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt

=

To remove yourself from the I-D Announcement = list, send a message to

=

i-d-announce-request@ietf.o= rg with the word unsubscribe in the body of

=

the message.

=

You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce

=

to change your subscription settings.

=

Internet-Drafts are also available by = anonymous FTP. Login with the

=

username "anonymous" and a password of your = e-mail address. After

=

logging in, type "cd internet-drafts" and = then

=

"get draft-ietf-pwe3-pw-mib-10.txt".

=

A list of Internet-Drafts directories can be = found in

=

http://www.ietf.org/shadow.html<= /a>

=

or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

=

Internet-Drafts can also be obtained by = e-mail.

=

Send a message to:

=

      mailserv@ietf.org.

=

In the body type:

=

      "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

=

     

=

NOTE: The mail server at ietf.org can return the document = in

=

      MIME-encoded form by using = the "mpack" utility.  To use this

=

      feature, insert the command "ENCODING mime" before the "FILE"

=

      command.  To decode the response(s), you will need "munpack" or

=

      a MIME-compliant mail = reader.  Different MIME-compliant mail readers

=

      exhibit different behavior, = especially when dealing with

=

      "multipart" MIME = messages (i.e. documents which have been split

=

      up into multiple messages), = so check your local documentation on

=

      how to manipulate these = messages.

=

Below is the data which will enable a MIME = compliant mail reader

=

implementation to automatically retrieve the ASCII version = of the

=

Internet-Draft.

=



 

------_=_NextPart_001_01C7803F.68739BBE-- --===============1471059265== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1471059265==-- From pwe3-bounces@ietf.org Mon Apr 16 13:17:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUpM-0004gi-Fr; Mon, 16 Apr 2007 13:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUpK-0004ga-IM for pwe3@ietf.org; Mon, 16 Apr 2007 13:17:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUpG-0001g1-Vz for pwe3@ietf.org; Mon, 16 Apr 2007 13:17:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 13:17:14 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208,217"; a="118647572:sNHT276547550" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GHHEKj032498; Mon, 16 Apr 2007 13:17:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3GHHAlG009006; Mon, 16 Apr 2007 17:17:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:17:09 -0400 Received: from [10.83.15.55] ([10.83.15.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:17:08 -0400 In-Reply-To: <94B3ADCC6E45544CA75307E399F4E94B011AFEB4@MT-Mail.sycamorenet.com> References: <98F4CECC-D708-4B5F-97AD-B39071E396FA@cisco.com> <457D36D9D89B5B47BC06DA869B1C815D03B2E776@exrad3.ad.rad.co.il> <94B3ADCC6E45544CA75307E399F4E94B011AFEB4@MT-Mail.sycamorenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: "Thomas D. Nadeau" Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt Date: Mon, 16 Apr 2007 13:17:07 -0400 To: "Suberri, Moshe" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 17:17:08.0478 (UTC) FILETIME=[101FF1E0:01C7804B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=91466; t=1176743834; x=1177607834; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20Re=3A=20[PWE3]=20I-D=20ACTION=3Adraft-ietf-pwe3-pw-mib-10.txt =20 |Sender:=20 |To:=20=22Suberri,=20Moshe=22=20; bh=fsVvD2LQNKvDIGmf0NidPEmxN1Ji2TnqXC1xatVLACA=; b=R+hTINOR1nIYR/UluG8DY7wJI3DOj2C7qUiZ0tss32H0Se8ES7eJhAPqtoAzJZhEBKz05rXj zO4zaeFlTEDFkl12s4RcHdou2PYyzozrhQxVVvi1Xoo66qGkA2rXDGm/; Authentication-Results: rtp-dkim-2; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 1.4 (+) X-Scan-Signature: fd51b29932ff50b682a542577cd0b7b1 Cc: David Zelig , pwe3@ietf.org, Orly Nicklass X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0604744650==" Errors-To: pwe3-bounces@ietf.org --===============0604744650== Content-Type: multipart/alternative; boundary=Apple-Mail-16-868131496 --Apple-Mail-16-868131496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed If you think if the operStatus is insufficient, that you should = take =20 that up with the WGs that are working on SNMP so that it can be addressed in a common =20 place. Hacking up all of the PWE3 MIBs (and then who knows how many others) to be more explicit about configuration errors seems to be going in the =20 wrong direction IMHO. --Tom > I still feel that the reporting of =91inconsistent configuration=92 =20= > through =91notPresent' in the pwVcOperStatus, is not at all intuitive. > > A bit in the pwTDMConfigError will do the same job and will be much =20= > more self explanatory and intuitive. After all, the =20 > pwTDMConfigError object supposes to report configuration related =20 > errors and the =91inconsistent configuration=92 is such an issue. > > > > > > Moshe > > . . > > > > From: Orly Nicklass [mailto:orly_n@rad.com] > Sent: Friday, April 13, 2007 1:26 AM > To: Thomas D. Nadeau; Suberri, Moshe > Cc: pwe3@ietf.org; David Zelig > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > > > The inconsistency can be a result of single set operation where the =20= > agent has the complete set of values to verify integrity among =20 > them. As such, the set operation should fail with an error of =20 > 'inconsistentValue'. > > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, April 12, 2007 21:14 > To: Suberri, Moshe > Cc: pwe3@ietf.org; David Zelig > Subject: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > >> David, >> >> It is my understanding that the =93Textual Conventions and for =20 >> Managing Pseudo-Wires=94 is still a draft document. > > > Yes, but there are a number of implementations of this draft, so we =20= > need to be careful about > > how we alter it. With that said, if something is totally broken we =20 > need to fix it, but in this case, > > but I do not think that is the case here. > > > To be more specific, my concern is with the PW =93payload size=94 and =20= > the =93TDM rate=94. Since the =93TDM Rate=94 is in one table and the =20= > =93Payload size=94 is in another table, the proposed way to expose an =20= > inconsistency between the two objects is through the operational =20 > status. > > If the operational status is cast in stone, the above inconsistency =20= > can be exposed with a new bit (payloadSizeInconsistent) in the =20 > pwTDMConfigError object > > What it sounds like to me is that you are trying to uncover a =20 > provisioning inconsistency. > > In this case, the agent can refuse to create the entry based on the =20= > state of the other table. > > > > --Tom > > > > > > > Moshe > > size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1> > From: David Zelig [mailto:Davidz@corrigent.com] > Sent: Thursday, April 12, 2007 12:07 PM > To: Suberri, Moshe > Cc: pwe3@ietf.org; tnadeau@cisco.com > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > Moshe, > > The definition of the operstatus states are de-facto standard, =20 > therefore I believe that adding a new state is not feasible. The =20 > 'notPresent' state is rarely used otherwise so it is a good hint to =20= > look for configuration inconsistency. > > Note also that most of configuration inconsistencies/errors are =20 > already covered extensively in the service specific MIBs with =20 > detailed error coding. > > Thanks > > David > > From: Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com] > Sent: Monday, April 09, 2007 8:27 PM > To: David Zelig; tnadeau@cisco.com > Cc: pwe3@ietf.org > Subject: RE: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > =93 > > 7. Relations to Other PWE3 MIB Modules > > . > > . > > . > > - Unless all the necessary entries in the applicable tables have been > > created and all the parameters have been consistently configured in > > those tables, signaling cannot be performed from the local node, =20= > and > > the pwVcOperStatus should report 'notPresent'.=94 > > =93 > > If you want to expand the definition of the Operational Status to =20 > include configuration anomalies, it could be operationally helpful =20 > to uniquely qualify this class of errors. For example, adding a =20 > value of =91inconsistentConfiguration=92 or =91configurationError=92 = will =20 > unambiguously identify the problem to the operator. > > Regards > > Moshe > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, February 07, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: pwe3@ietf.org > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-pw-mib-10.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Pseudowire Emulation Edge to Edge =20 > Working Group of the IETF. > > Title : Pseudo Wire (PW) Management Information Base > > Author(s) : D. Zelig, et al. > > Filename : draft-ietf-pwe3-pw-mib-10.txt > > Pages : 63 > > Date : 2007-2-7 > > > > This memo defines an experimental portion of the Management > > Information Base for use with network management protocols in the > > Internet community. In particular, it describes managed objects =20= > for > > modeling of Pseudo Wire Edge-to-Edge services carried over a =20 > general > > Packet Switched Network. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-10.txt > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-pwe3-pw-mib-10.txt". > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail =20 > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > --Apple-Mail-16-868131496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252
If you = think if the operStatus is insufficient, that you should take that up = with the
WGs that are working on SNMP so that it can be = addressed in a common place.
Hacking up all of the PWE3 MIBs = (and then who knows how many others) to
be more explicit about = configuration errors seems to be going in the wrong
direction = IMHO.

= --Tom

I still feel that the = reporting of =91inconsistent configuration=92 through = =91notPresent' in the pwVcOperStatus, is not at all intuitive.A bit in the = pwTDMConfigError will do the same job = and will be much more self explanatory and intuitive. After all, the = pwTDMConfigError object supposes to report configuration related errors and = the =91inconsistent configuration=92 is such an issue.

Moshe

. . =A0

Orly Nicklass [mailto:orly_n@rad.com]
Friday, April 13, = 2007 1:26 AM
Thomas D. Nadeau; = Suberri, Moshe
pwe3@ietf.org; David Zelig
RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

The inconsistency can = be a result of single set operation where the agent has the complete set = of values to verify integrity among them. As such, the set operation = should fail with an error of = 'inconsistentValue'.

Thomas D. Nadeau [mailto:tnadeau@cisco.com] =
Thursday, April = 12, 2007 21:14
Suberri, = Moshe
pwe3@ietf.org; David Zelig
Re: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

David,It is my understanding = that the =93Yes, but there are a number of = implementations of this draft, so we need to be careful abouthow we alter it. With that = said, if something is totally broken we need to fix it, but in this = case,but I do not think that is the = case here.

To be more specific, my concern is with the PW =93payload = size=94 and the =93TDM rate=94. Since the =93TDM Rate=94 is in one table = and the =93Payload size=94 is in another table, the proposed way to = expose an inconsistency between the two objects is through the = operational status.

If = the operational status is cast in stone, the above inconsistency can be = exposed with a new bit (payloadSizeInconsistent) in the pwTDMConfigError = object

What it sounds like to me is = that you are trying to uncover a provisioning inconsistency.=A0In this case, the agent can = refuse to create the entry based on the state of the other = table.=A0

=A0



Moshe=A0=A0

Suberri, Moshe [mailto:Moshe.Suberri@sycamorenet.com]
Sent: Monday, April 09, 2007 8:27 PM
To: David Zelig; RE: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

=93

7.=A0 = Relations to Other PWE3 MIB Modules

.

.

.

- =A0Unless = all the necessary entries in the applicable tables have been

=A0=A0 = created and all the parameters have been consistently configured = in=A0=A0 those = tables, signaling cannot be performed from the local node, = and=A0=A0 the = pwVcOperStatus should report 'notPresent'.=94

=93

If you want to expand the = definition of the Operational Status to include configuration anomalies, = it could be operationally helpful to uniquely qualify this class of = errors. For example, adding a value of =91inconsistentConfiguration=92 = or =91configurationError=92 will unambiguously identify the problem to = the operator.

RegardsMoshe = =A0=A0-----Original = Message-----
From: Internet-Drafts@ietf.org = [mailto:Internet-Drafts@ietf.org]
Sent: Wednesday, February 07, 2007 3:50 PM
To: Cc: Subject: [PWE3] I-D = ACTION:draft-ietf-pwe3-pw-mib-10.txt

<= P class=3D"MsoPlainText">A New Internet-Draft is available from the on-line = Internet-Drafts

<= P class=3D"MsoPlainText">directories.

<= P class=3D"MsoPlainText">This draft is a work item of the Pseudowire Emulation Edge = to Edge Working Group of the IETF.

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0 : Pseudo Wire (PW) = Management Information Base

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 Author(s)=A0=A0 : D. Zelig, et = al.

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 Filename=A0=A0=A0 : = draft-ietf-pwe3-pw-mib-10.txt

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0 : 63

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0 : = 2007-2-7

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0

<= P class=3D"MsoPlainText">This memo defines an experimental portion of the = Management

<= P class=3D"MsoPlainText">=A0=A0 Information Base for use with network management = protocols in the

<= P class=3D"MsoPlainText">=A0=A0 Internet community.=A0 In particular, it describes = managed objects for

<= P class=3D"MsoPlainText">=A0=A0 modeling of Pseudo Wire Edge-to-Edge services = carried over a general

<= P class=3D"MsoPlainText">=A0=A0 Packet Switched Network.

<= P class=3D"MsoPlainText">A URL for this Internet-Draft is:

<= P class=3D"MsoPlainText">

<= P class=3D"MsoPlainText">To remove yourself from the I-D Announcement list, send a = message to

<= P class=3D"MsoPlainText">i-d-announce-request@ietf.org with the word unsubscribe in the body of

<= P class=3D"MsoPlainText">the message.

<= P class=3D"MsoPlainText">You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce

<= P class=3D"MsoPlainText">to change your subscription settings.

<= P class=3D"MsoPlainText">Internet-Drafts are also available by anonymous FTP. Login = with the

<= P class=3D"MsoPlainText">username "anonymous" and a password of your e-mail address. = After

<= P class=3D"MsoPlainText">logging in, type "cd internet-drafts" and then

<= P class=3D"MsoPlainText">"get draft-ietf-pwe3-pw-mib-10.txt".

<= P class=3D"MsoPlainText">A list of Internet-Drafts directories can be found = in

<= P class=3D"MsoPlainText">

<= P class=3D"MsoPlainText">or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

<= P class=3D"MsoPlainText">Internet-Drafts can also be obtained by e-mail.

<= P class=3D"MsoPlainText">Send a message to:

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 .

<= P class=3D"MsoPlainText">In the body type:

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 "FILE = /internet-drafts/draft-ietf-pwe3-pw-mib-10.txt".

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0

<= P class=3D"MsoPlainText">NOTE: The mail server at ietf.org can return the document = in

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 MIME-encoded form by using the "mpack" = utility.=A0 To use this

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 feature, insert the command "ENCODING mime" = before the "FILE"

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 command.=A0 To decode the response(s), you = will need "munpack" or

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 a MIME-compliant mail reader.=A0 Different = MIME-compliant mail readers

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 exhibit different behavior, especially when = dealing with

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 "multipart" MIME messages (i.e. documents = which have been split

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 up into multiple messages), so check your = local documentation on

<= P class=3D"MsoPlainText">=A0=A0=A0=A0=A0 how to manipulate these = messages.

<= P class=3D"MsoPlainText">Below is the data which will enable a MIME compliant mail = reader

<= P class=3D"MsoPlainText">implementation to automatically retrieve the ASCII version = of the

<= P class=3D"MsoPlainText">Internet-Draft.

<= /DIV>




<= /HTML>= --Apple-Mail-16-868131496-- --===============0604744650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0604744650==-- From pwe3-bounces@ietf.org Mon Apr 16 18:57:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hda8j-0001gz-Et; Mon, 16 Apr 2007 18:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hda8h-0001gi-T2 for pwe3@ietf.org; Mon, 16 Apr 2007 18:57:39 -0400 Received: from fncnmp04.fnc.fujitsu.com ([168.127.0.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hda8f-0004dG-Gn for pwe3@ietf.org; Mon, 16 Apr 2007 18:57:39 -0400 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp04.fnc.fujitsu.com with ESMTP; 16 Apr 2007 17:57:36 -0500 X-IronPort-AV: i="4.14,416,1170655200"; d="scan'208"; a="77399407:sNHT23309480" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Mon, 16 Apr 2007 17:57:36 -0500 Message-ID: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C337BDD@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: Acd93xATp9k2+UZ1Q5ifHZKmzxv+0QABkUvwAKTZcXA= From: "O'Connor, Don" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Neil and Ben This can be accomplished by the Generic PW concept that has been = previously discussed in PWE3. For reference please see the following = email thread http://www1.ietf.org/mail-archive/web/pwe3/current/mail38.html An email from Danny on 1/30/06 indicated (with respect to Generic PW) "One application for the service would be a SP transit domain in which it was desired that there was no interaction between the client and transport network protocols (e.g., MPLS LSP transport services w/no LDP interaction between the transport and client networks)." Is this the capability that you are seeking ? In order to address the Generic PW application, it is not necessary to = make draft-bryant a WG draft=20 Do you have an opinion / view on Generic PW? Regards Don -----Original Message----- From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: Friday, April 13, 2007 11:19 AM To: pwe3@ietf.org Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Agreed Ben....operators need a method to carry the MPLS layer network of one party over the MPLS layer network of another party in a transparent client/server manner, ie the client and server layer MPLS networks are functionally decoupled. Stewart's draft is showing one way to achieve this using existing mechanisms based on PWs. So, from this 'requirement perspective' I also support the draft becoming a WG document....though I should add that I can think of other ways to achieve this and so we should also be open to consider alternatives in the future.=20 regards, Neil BT Global Services CTO=20 > -----Original Message----- > From: benjamin.niven-jenkins@bt.com=20 > [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: 13 April 2007 16:19 > To: pwe3@ietf.org > Subject: [PWE3] Fwd: I-D=20 > ACTION:draft-bryant-pwe3-mpls-transport-00.txt >=20 >=20 > =09 > > Folks, > > As discussed in the meeting, I'd like to solicit WG feedback on > > adopting this as a WG document. If you're in favor or opposed > > to adopting this please speak up now. > >=20 > > -danny >=20 > I support draft-bryant-pwe3-mpls-transport becoming a WG=20 > document as it provides a mechanism for transporting one=20 > party's MPLS network over another's (which we have a=20 > requirement for) using existing deployed technology. >=20 > Ben >=20 > --=20 > Ben Niven-Jenkins > Network Architect, BT > =20 > E-mail: benjamin.niven-jenkins@bt.com=20 > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Apr 17 03:02:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdhi7-0000LF-WF; Tue, 17 Apr 2007 03:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdhi6-0000L3-LE for pwe3@ietf.org; Tue, 17 Apr 2007 03:02:42 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdhi5-0000og-TT for pwe3@ietf.org; Tue, 17 Apr 2007 03:02:42 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 08:02:40 +0100 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 08:02:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Date: Tue, 17 Apr 2007 08:01:55 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C3383E7@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Fwd: I-D ACTION:draft-bryant-pwe3-mpls-transport-00.txt Thread-Index: Acd93xATp9k2+UZ1Q5ifHZKmzxv+0QABkUvwAKTZcXAADsXDEA== From: To: , X-OriginalArrivalTime: 17 Apr 2007 07:02:40.0227 (UTC) FILETIME=[63590B30:01C780BE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Don...please see in-line..... > -----Original Message----- > From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com]=20 > Sent: 16 April 2007 23:58 > To: Harrison,N,Neil,JCGA1 R; pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D=20 > ACTION:draft-bryant-pwe3-mpls-transport-00.txt >=20 >=20 > Neil and Ben >=20 > This can be accomplished by the Generic PW concept that has=20 > been previously discussed in PWE3. For reference please see=20 > the following email thread >=20 > http://www1.ietf.org/mail-archive/web/pwe3/current/mail38.html >=20 > An email from Danny on 1/30/06 indicated (with respect to Generic PW) >=20 > "One application for the service would be a SP transit domain=20 > in which it was desired that there was no interaction between=20 > the client and transport network protocols (e.g., MPLS LSP=20 > transport services w/no LDP interaction between the transport=20 > and client networks)." >=20 > Is this the capability that you are seeking ? NH=3D> Essentially yes. I don't know how far the records go back, but I can recall suggesting to Danny and Stewart the need for an 'MPLS PW' way before this. At the time I don't think many other folks had foreseen that there would be a need at some point for a MPLSoverMPLS C/S (client/server) layer network relationship. I should, however, add that I don't like the manner in which this would have to be done....BUT, given the way MPLS has been designed it is the best one can do. We cannot (repeat cannot) afford to go back now and redesign MPLS. It's too late. There is too much MPLS as-is out there. We have to now find a C/S solution from what exists. I'll come back on this point below. >=20 > In order to address the Generic PW application, it is not=20 > necessary to make draft-bryant a WG draft=20 >=20 > Do you have an opinion / view on Generic PW? NH=3D> Yes. For a start a generic PW is actually a contradiction in terms. PWs should never have existed. MPLS itself should have been 'generic' and designed from the outset to support all clients in a consistent manner if it was going to do more than be an IP-booster. It is the special treatment of IP (ie null encaps *OR* peer PDU...which that is truly bizarre from a func arch layer network perspective if you grok what I mean by this) and MPLS (ie nested LSPs get the wrapper treatment, with the lovely illusion that one can create topology on the fly by simply adding another MPLS labelled header) that creates most of the downstream problems. Note - It is the above observation that is the real architectural problem. The violation of the rules of a connection by allowing merging (vanilla LDP and PHP) are secondary problems. Ditto the lack of simple and correctly specified OAM, no OBB control/management, etc....these are all secondary symptoms. Note also these problems do not afflict GMPLS because one cannot misuse the co-cs mode due to way labelling and resource partitioning work here. PWs are therefore simply a consequential spawn of this anomalous design. Whilst they remained 1-hop they could be considered as an adaptation function (though most of the fields would be redundant in a properly designed co-ps mode layer network)...however, once PWs go multi-hop they become a new full-blown co-ps mode layer network in their own right. And that, I am afraid, is a really bad consequence. I was making these observations maybe 5 or more years ago on the PWE3 list and they were ignored. It is now far too late. We cannot now afford to go back and re-engineer MPLS. One thing folks need to be quite clear on is that we do not need to address all the resource partitioning, etc issues in MPLS to obtain a C/S relationship...we can get this without a major re-engineering of MPLS. MPLS is based on the ability to arbitrarily stack/nest LSPs. This means that such stacked/nested LSPs all belong to the same MPLS layer network....in functional architecture terms stacked/nested LSPs are sublayer constructs within the same MPLS layer network. What this means practically is that it is not possible to directly carry an LSP belonging to the MPLS network of party A say over an LSP belonging to the MPLS network of party B say in a truly transparent functionally decoupled manner. In other words stacked/nested LSPs do not intrinsically provide a client/server layer network relationship. =20 One solution to the problem is to use existing PW techniques to insert a different technology between the two MPLS networks (of say party A and party B as noted above). This provides a 'functional breakwater' between the 2 MPLS networks. This could, in principle, use any PW technology. However, in Stewart's document a choice has been made to use an Ethernet PW as defined in rfc4448. =20 I can think of a possibly more simple/elegant solution (that also has other benefits) by using a reserved label to act as a functional 'stack delimiting label', and thus avoid the need to insert another technology to provide the functional breakwater between the MPLS networks owned/operated by different parties. However, the key purpose of Stewarts document is to show that there is a solution to providing a C/S behaviour using already defined IETF standards without having to undertake a major re-engineering of MPLS....and as I have already noted, it is far too late to countenance this anyway IMO. regards, Neil >=20 > Regards >=20 > Don >=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: Friday, April 13, 2007 11:19 AM > To: pwe3@ietf.org > Subject: RE: [PWE3] Fwd: I-D=20 > ACTION:draft-bryant-pwe3-mpls-transport-00.txt >=20 >=20 > Agreed Ben....operators need a method to carry the MPLS layer=20 > network of one party over the MPLS layer network of another=20 > party in a transparent client/server manner, ie the client=20 > and server layer MPLS networks are functionally decoupled. =20 > Stewart's draft is showing one way to achieve this using=20 > existing mechanisms based on PWs. So, from this 'requirement=20 > perspective' I also support the draft becoming a WG=20 > document....though I should add that I can think of other=20 > ways to achieve this and so we should also be open to=20 > consider alternatives in the future.=20 >=20 > regards, Neil > BT Global Services CTO=20 >=20 > > -----Original Message----- > > From: benjamin.niven-jenkins@bt.com > > [mailto:benjamin.niven-jenkins@bt.com]=20 > > Sent: 13 April 2007 16:19 > > To: pwe3@ietf.org > > Subject: [PWE3] Fwd: I-D=20 > > ACTION:draft-bryant-pwe3-mpls-transport-00.txt > >=20 > >=20 > > =09 > > > Folks, > > > As discussed in the meeting, I'd like to solicit WG feedback on > > > adopting this as a WG document. If you're in favor or opposed > > > to adopting this please speak up now. > > >=20 > > > -danny > >=20 > > I support draft-bryant-pwe3-mpls-transport becoming a WG > > document as it provides a mechanism for transporting one=20 > > party's MPLS network over another's (which we have a=20 > > requirement for) using existing deployed technology. > >=20 > > Ben > >=20 > > -- > > Ben Niven-Jenkins > > Network Architect, BT > > =20 > > E-mail: benjamin.niven-jenkins@bt.com > > Office: +44 (0)1473 648225 > > Mobile: +44 (0)7918 077205 > > Fax: +44 (0)1332 578827 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Apr 26 15:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9ey-0006Ph-9S; Thu, 26 Apr 2007 15:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9ex-0006Oz-JM for pwe3@ietf.org; Thu, 26 Apr 2007 15:29:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9ex-0008QX-3V for pwe3@ietf.org; Thu, 26 Apr 2007 15:29:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2007 15:29:44 -0400 X-IronPort-AV: i="4.14,457,1170651600"; d="scan'208"; a="58723566:sNHT63044472" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3QJTg8N014768; Thu, 26 Apr 2007 15:29:42 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3QJTWlM003415; Thu, 26 Apr 2007 19:29:42 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 15:29:34 -0400 Received: from [10.83.15.56] ([10.83.15.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 15:29:34 -0400 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <6270F872-7224-472E-AD2A-4BDA199D6A8D@cisco.com> Content-Transfer-Encoding: quoted-printable From: "Thomas D. Nadeau" Date: Thu, 26 Apr 2007 15:29:37 -0400 To: "pwe3 ((((((((((((((((E-mail)))))))))))))))) WG" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Apr 2007 19:29:34.0399 (UTC) FILETIME=[3864C4F0:01C78839] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7594; t=1177615782; x=1178479782; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tnadeau@cisco.com; z=From:=20=22Thomas=20D.=20Nadeau=22=20 |Subject:=20IEEE=20CFP=3A=20Next-Generation=20Carrier=20Ethernet=20Transp ort=20Technologies |Sender:=20 |To:=20=22pwe3=20((((((((((((((((E-mail))))))))))))))))=20WG=22=20; bh=/DxqY+L8j2AuJJbXFu+ZrHo97Bwma/5drgEO6W2UEh4=; b=aiaCzoyTFZYpK7qEScany5jubEmEq2GcHJbgUCO13/qGlkXyKHGA28p+Ixvg6nxoBlvciV4q HML8vs+e6Cxg5Z/jkBimX+EKAVzTQWapKRmkSTRDm6pfTnoidvHYLDVF; Authentication-Results: rtp-dkim-1; header.From=tnadeau@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Sharma Vishal , Ashwin Gumaste Subject: [PWE3] IEEE CFP: Next-Generation Carrier Ethernet Transport Technologies X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi all, We wanted to pass this onto the PWE3 community. Apologies for cross-posts to other WG lists you might be on. Tom/Vishal/Ashwin CALL FOR PAPERS ------------------------------ IEEE Communications Magazine Feature Topic on "Next-Generation Carrier Ethernet Transport Technologies=94 Over the last few years, the share of packet-dominated traffic has =20 grown exponentially in networks worldwide. As a result packet-based =20 transport technologies such as MPLS are increasingly deemed to be =20 more efficient for carrying this traffic compared to legacy SDH/SONET =20= technology (and its next-generation incarnations) or the more =20 familiar ATM/FR technology. A majority of this traffic is now either =20 Ethernet or Internet Protocol (IP), so enterprises (and even =20 residential customers) familiar with Ethernet technology have begun =20 demanding a simple, inexpensive and high-speed universal Ethernet =20 service. With the availability of low-cost, high-bandwidth Ethernet =20 beyond the Local Area Network, the Metro Ethernet Forum (MEF) has =20 defined such a service as Carrier Ethernet, and defined it as a =20 ubiquitous, standardized, carrier-class service/application =20 characterized by some key attributes: reliability, hard Quality-of-=20 Service (QoS), service management, and scalability. These features set it apart from the ubiquitously deployed LAN-based =20 Ethernet and serve as an add-on to switched Ethernet (GigE, and =20 10GigE variants). There are, however, several options for building =20 the underlying transport infrastructure to deliver such a carrier =20 Ethernet service. These include, for example, using: IP/MPLS =20 technology to deliver point-to-point Ethernet circuits joined =20 together with physical Ethernet bridges/switches; IP/MPLS with =20 Virtual-Private LAN Service (VPLS) or Hierarchical Virtual Private =20 LAN Service (H-VPLS) (developed at the IETF); Transport-MPLS (T-MPLS) =20= being proposed at the ITU-T, using modified Ethernet technology with =20 Provider Backbone Bridging (PBB) and Provider-Backbone Transport =20 (PBT) being proposed at the IEEE; using a combination of a modified =20 Ethernet data-plane and a GMPLS-based control-plane with VLAN cross-=20 connect (being proposed by several vendors and under consideration at =20= the IETF) and Circuit Emulation Services (CES) over an Ethernet =20 fabric to provision Pseudo Wires (PWs). The quest, therefore, is for the most feature rich, and CAPEX/OPEX =20 efficient, packet-based transport infrastructure for next-generation =20 Carrier Ethernet services. Debate and discussion is rife in the =20 industry and the academic/research communities about which technology =20= will provide the best combination of cost, ease of use, OAM features, =20= performance and service management, ability to offer Quality-of-=20 Service (QoS) guarantees, traffic engineering, and resilience, and =20 capability to manage and bill for services running atop the transport =20= infrastructure. This special issue aims to consolidate and disseminate the latest =20 developments and advances in transport technology options for Carrier =20= Ethernet service. With this objective, the list of topics includes =20 (but will not be limited to) the following: =95 Metro Ethernet and Carrier Ethernet evolutions =96 =20 requirements, services specifications, carrier drivers, customer drivers =95 Requirements on QoS, traffic engineering, resilience, =20 manageability, OAM, and service scalability for carrier Ethernet =20 transport technologies =95 IP/MPLS (VPLS, H-VPLS) for carrier Ethernet services =96 =20= choices, pros, cons, costs/benefits =95 Provider Backbone Bridging (PBB) and Provider Backbone =20 Transport-Traffic Engineered (PBT-TE) as alternatives to IP/MPLS for =20 Ethernet transport =96 pros, cons, costs/benefits =95 Transport-MPLS for carrier Ethernet =96 pros, cons, costs/=20= benefits =95 GMPLS-based control of Ethernet networks =96 changes in = the =20 data and control planes =95 Assessment of the proposed transport solutions in terms =20= of their ability to provide QoS, traffic engineering, resilience, =20 manageability, and so on. =95 OAM, network management, service management =96 options, =20= choices, pitfalls, needs, and cost analysis and comparison of solutions. =95 Solutions that meet the perceived requirements of the =20 community that are alternatives to the ones being proposed in the =20 various standards bodies. =95 Traffic engineering and dimensioning of carrier Ethernet =20= transport networks =95 Techniques to ensure QoS, especially with a mix of =20 transport technologies in use =95 Analysis and studies of resilience and protection =20 approaches utilized by different transport architectures and =20 associated technologies =95 Studies comparing the different transport technologies =20 along multiple dimensions =96 deployment cost, day-to-day running cost, =20= features provided, ease of deployment/management, and so on =95 Comparisons and case-studies from the provider community =20= to highlight why existing technologies do not meet current and =20 evolving provider requirements. =95 Commentaries from providers who feel existing techniques/=20= choices meet their requirements or can be easily modified to meet =20 their requirements. =95 Network operators, vendors, and standards bodies=92 =20 perspectives on any of the above. =95 Implementations, test-beds and field trials related to =20 carrier Ethernet transport technologies =95 State of current standards Submission Articles should be tutorial in nature and should be written in a =20 style comprehensible to readers outside the specialty of the article. =20= Articles may be edited for clarity and grammatical accuracy, and will =20= be copyedited according to the Magazine's style. Mathematical =20 equations should not be used (in justified cases up to three simple =20 equations could be allowed, provided there is consent of the Guest =20 Editor; more than three equations require permission from the Editor-=20 in-Chief). Articles should have no more than 4,500 words, no more =20 than 6 tables/figures, and no more than 15 references. Guidelines for =20= prospective authors can be found on-line at http://www.comsoc.org/=20 pubs/commag/sub_guidelines.html. Please submit no later than 31 July =20 2007. All articles to be considered for publication must be submitted =20= through IEEE Manuscript Central (http://commag-=20 ieee.manuscriptcentral.com). Please select "March 2008/Next-=20 Generation Carrier Ethernet Transport Technologies" in the drop down =20 menu. Accepted papers will also be included in Communications =20 Interactive (CI), the online version of Communications Magazine. Manuscript Due: 1 August 2007 Acceptance Notification: 1 November 2007 Final Manuscript Due: 1 December 2007 Publication Date: March 2008 Guest Editors Thomas D. Nadeau, Cisco Systems, Inc., (tnadeau@cisco.com) Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Ashwin Gumaste, Indian Institute of Technology Bombay (ashwing@ieee.org) =20= _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Apr 27 10:52:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRo4-0001KO-7E; Fri, 27 Apr 2007 10:52:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRo1-0001GH-Qu; Fri, 27 Apr 2007 10:52:17 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhRo0-0008Hr-7J; Fri, 27 Apr 2007 10:52:17 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 249642AC5D; Fri, 27 Apr 2007 14:51:46 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhRnV-0004km-Tv; Fri, 27 Apr 2007 10:51:45 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 27 Apr 2007 10:51:45 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: draft-ietf-pwe3-vccv (Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)) to Proposed Standard X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Pseudo Wire Virtual Circuit Connectivity Verification (VCCV) ' as a Proposed Standard 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 2007-05-11. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-13.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10712&rfc_flag=0 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Apr 27 10:59:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRup-0006jB-KB; Fri, 27 Apr 2007 10:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRsA-0005oS-9G; Fri, 27 Apr 2007 10:56:34 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRms-00026n-IR; Fri, 27 Apr 2007 10:51:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 84D88329C2; Fri, 27 Apr 2007 14:51:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhRms-0004j0-EP; Fri, 27 Apr 2007 10:51:06 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 27 Apr 2007 10:51:06 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: pwe3@ietf.org Subject: [PWE3] Last Call: draft-ietf-pwe3-ms-pw-requirements (Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)) to Informational RFC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IESG has received a request from the Pseudowire Emulation Edge to Edge WG (pwe3) to consider the following document: - 'Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) ' as an 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 2007-05-11. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ms-pw-requirements-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13229&rfc_flag=0 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Apr 27 15:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSu-0003Yz-0u; Fri, 27 Apr 2007 15:50:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSf-00031W-AG; Fri, 27 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhWSe-0002Lx-Uw; Fri, 27 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D2B7F2ACB3; Fri, 27 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhWSA-0002R4-Ir; Fri, 27 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 27 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fc-encap-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Author(s) : M. Roth, et al. Filename : draft-ietf-pwe3-fc-encap-03.txt Pages : 37 Date : 2007-4-27 A Fibre Channel Pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fc-encap-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fc-encap-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fc-encap-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-27115401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-fc-encap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-fc-encap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-27115401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart--