Subject: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt

From: Danny McPherson <[email-masked]>
Date: Sun, 4 Mar 2007 22:24:28 -0700

Folks,
Please consider today the beginning of a 3 week WG last call for
this document.  Please direct any comments with this revision of the
draft to the authors and PWE3 mailing list.

Thanks!

-danny & Stewart

Begin forwarded message:

> From: [email-masked]
> Date: February 13, 2007 1:50:03 PM MST
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-pwe3-pw-atm-mib-02.txt
> Reply-To: [email-masked]
>
> 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-02.txt
> 	Pages		: 37
> 	Date		: 2007-2-13
> 	
> 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-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-02.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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-02.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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Ronen Solomon" <[email-masked]>
Date: Tue, 20 Mar 2007 17:17:12 +0200

comments

1. Need to add a separate ATM transparent cell mode table configuration
as VPI and VCI are not applicable rather then use the existing VPI/VCI
1:N tables. The current MIB uses the VPI/VCI tables with 0xFFFFFF which
is not adequate for a management system. 

2. pwAtmCfgFarEndMaxCellConcatenation should also be used as a
read-write object if LDP is not used. The reason is that this parameter
should allow the local node to calculate protocol overhead at the egress
direction of the PW (i.e. direction from the remote PE to the local PE).

3. pwAtmCfgTimeoutMode should be configurable timer. Different
application requires different timeouts such as AAL1 requires different
timeout then AAL2 data traffic. If HW does not support such
functionality then a default vlaue should  be applied.  

4. Suggested to ATM PW Outbound Perf Table a new parameter "Average
concatenated cells" , which will allow the operator the analyze what is
the average number of cells that are concatenated into a single frame.
This has influence on bandwidth usage due to protocol overhead. 

Ronen

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 7:24 AM
To: pwe3 WG ((((((((E-mail))))))))
Subject: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

Folks,
Please consider today the beginning of a 3 week WG last call for this
document.  Please direct any comments with this revision of the draft to
the authors and PWE3 mailing list.

Thanks!

-danny & Stewart

> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-pwe3-pw-atm-mib-02.txt".
>
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 20 Mar 2007 11:25:41 -0400

> is not adequate for a management system.

	Please make specific suggestions.  This will speed
the process along, and also allow the WG to comment
on the specifics of what you are asking.

> direction of the PW (i.e. direction from the remote PE to the local  

	OK.

> functionality then a default vlaue should  be applied.

	OK.

> This has influence on bandwidth usage due to protocol overhead.

	I do not like this object, at least as a mandatory one,
as it is largely dependent on the local node computing this average.
I would rather than the NMS do this based on gathering statistics
given that some of the PW hardware being used is quite low-end, and
the CPUs are close to %100 dedicated for packet forwarding.

	--Tom

---

From: "Ronen Solomon" <[email-masked]>
Date: Tue, 20 Mar 2007 21:38:28 +0200

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2007 5:26 PM
To: Ronen Solomon
Cc: [email-masked];
[email-masked]; Orly Nicklass; pwe3 WG
((((((((E-mail)))))))); Danny McPherson
Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

On Mar 20, 2007:11:17 AM, at 11:17 AM, Ronen Solomon wrote:

> comments
>
> 1. Need to add a separate ATM transparent cell mode table 
> configuration as VPI and VCI are not applicable rather then use the 
> existing VPI/VCI 1:N tables. The current MIB uses the VPI/VCI tables 
> with 0xFFFFFF which is not adequate for a management system.

	Please make specific suggestions.  This will speed the process
along, and also allow the WG to comment on the specifics of what you are
asking.
-----------------------------------------
pwAtmTable index by pwIndex 

"This table specifies the information for an ATM PW to
          be carried over PSN. An entry is created in this table for
every entry in
          the pwTable with a pwType equal to type 0x0003, ATM
transparent cell transport
          ."

PwAtmEntry ::= SEQUENCE {
    PwAtmIndex                                    RowPointer,
    PwAtmIfIndex                                   InterfaceIndex,
    pwAtmOutboundTrafficParamDescr    RowPointer,
    pwAtmInboundTrafficParamDescr       RowPointer
    pwAtmRowStatus                             RowStatus
}

Row status is used to modify an entry. 

-----------------------------------------------------------

> read-write object if LDP is not used. The reason is that this 
> parameter should allow the local node to calculate protocol overhead 
> at the egress direction of the PW (i.e. direction from the remote PE 
> to the local PE).

	OK.

> application requires different timeouts such as AAL1 requires 
> different timeout then AAL2 data traffic. If HW does not support such 

	OK.

----------------------------
We may have the current parameter foir enable/diable and when enabled
the following configured the timeout with a DEFVAL.    

pwAtmCfgTimeout
SYNTAX  Unsigned32 (100..10000)
    UNITS   "microseconds"
    MAX-ACCESS read-write
    STATUS  current
    DESCRIPTION 
        ""
    DEFVAL { 100 }

------------------------------------------

> concatenated cells" , which will allow the operator the analyze what 
> is the average number of cells that are concatenated into a single 
> frame.

	I do not like this object, at least as a mandatory one, as it is
largely dependent on the local node computing this average.
I would rather than the NMS do this based on gathering statistics given
that some of the PW hardware being used is quite low-end, and the CPUs
are close to %100 dedicated for packet forwarding.
--------------------------------

I can suggest a simple moving averaging (w/o history data or CPU
intensive) method  ==>  

AvergaeN[i] = (1-X) * AvergaeN[i-1] + (X) * CurrentN[i] where X is
implementation specific with value of 0<X<1. 

----------------------------------------
Ronen

	--Tom

> document.  Please direct any comments with this revision of the draft 
> to the authors and PWE3 mailing list.
>
> Thanks!
>
> -danny & Stewart
>
>
> Begin forwarded message:
>

---

From: "Orly Nicklass" <[email-masked]>
Date: Wed, 21 Mar 2007 00:00:02 +0200

in lines

________________________________

From: Ronen Solomon [mailto:[email-masked]]
Sent: Tue 3/20/2007 21:38
To: Thomas D. Nadeau
Cc: [email-masked]; [email-masked]; Orly Nicklass; pwe3 WG ((((((((E-mail)))))))); Danny McPherson
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Tuesday, March 20, 2007 5:26 PM
To: Ronen Solomon
Cc: [email-masked];

Row status is used to modify an entry.
[ON] the idea was to use the existing tables with the same model for all three modes and not have a table per mode. 1:1 table stays for backward compatibility,   the n:1 can serve them all. Having single table for all applicable modes indeed help the nms. I rather leave this part as is

> at the egress direction of the PW (i.e. direction from the remote PE

        OK.
[ON] we can do that but leave the write op as optional.

        OK.

[ON] Time out can be set per PW or at system level, since it is implementation specific, we use en/dis only and leave the actual time value to be in private space. In addition, en/dis allows sparing the timeout value and controlling it externally.

I like to get additional opinion here before we change it or add the actual time value as an additional object or leave it as is.

pwAtmCfgTimeout

[ON] I rather see the NMS handle such.
--------------------------------

        --Tom

---

From: "Ronen Solomon" <[email-masked]>
Date: Wed, 21 Mar 2007 21:13:44 +0200

in line

From: Orly Nicklass [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 12:00 AM
To: Ronen Solomon; Thomas D. Nadeau
Cc: [email-masked];
[email-masked]; pwe3 WG ((((((((E-mail)))))))); Danny
McPherson
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

in lines

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, March 20, 2007 5:26 PM
To: Ronen Solomon
Cc: [email-masked];
[email-masked]; Orly Nicklass; pwe3 WG
((((((((E-mail)))))))); Danny McPherson
Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt

Row status is used to modify an entry.
[ON] the idea was to use the existing tables with the same model for all
three modes and not have a table per mode. 1:1 table stays for backward
compatibility,   the n:1 can serve them all. Having single table for all
applicable modes indeed help the nms. I rather leave this part as is
[Ronen Solomon] I suggest you re-consider this so that the MIB would be
useful for NMS (this is what it is supposed to do). The port-mode is a
bi-directional direction (and The port mode would is very useful for
metro equipment that aggregate ATM switches), and does not require
separation for inbound and outbound. There is no meaning to have this
complexity for a simple port-node scenario. 

        OK.

        OK.

[ON] Time out can be set per PW or at system level, since it is
implementation specific, we use en/dis only and leave the actual time
value to be in private space. In addition, en/dis allows sparing the
timeout value and controlling it externally.
[Ronen Solomon] This is a mandatory object in live operation of ATM
(ALL1 and ALL2 must have different timeout timers), and therefore should
be supported. Hence i believe it should appear as a standard MIB. If HW
does not support such configuration it could set a default parameter.  

I like to get additional opinion here before we change it or add the
actual time value as an additional object or leave it as is.

pwAtmCfgTimeout

[ON] I rather see the NMS handle such.
[Ronen Solomon] Can you suggest a method , how would an NMS perform such
function ? It would require history data or some kind of histogram PMs.
It is much simpler and more efficient for the agent to calculate a
moving average, rather an NMS calculation together with history PMs
gathered by the agent.   
--------------------------------

        --Tom

> From: Danny McPherson [mailto:[email-masked] <mailto:[email-masked]> ]
<http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-02.txt> 
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
<https://www1.ietf.org/mailman/listinfo/I-D-> 
>> announce
>> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  or
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt> 
>> Content-ID: <[email-masked]>
<https://www1.ietf.org/mailman/listinfo/i-d-announce> 
<https://www1.ietf.org/mailman/listinfo/pwe3>

---

From: "Suberri, Moshe" <[email-masked]>
Date: Thu, 22 Mar 2007 19:12:20 -0400

in lines

From: Ronen Solomon [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 3:14 PM
To: Orly Nicklass; Thomas D. Nadeau
Cc: Danny McPherson; pwe3 WG ((((((((E-mail))))))));
[email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

in line

in lines

-----Original Message-----

[Moshe] I can certainly appreciate the point of having one table for all
modes, and the point of having more flexible addressing of the traffic
flow. Will using an 'address type' concept in the current tables will
solve this issue?  

        OK.

        OK.

pwAtmCfgTimeout

        --Tom

---

From: "Orly Nicklass" <[email-masked]>
Date: Fri, 23 Mar 2007 10:28:43 +0200

in lines

-----Original Message-----

[Moshe] I can certainly appreciate the point of having one table for all
modes, and the point of having more flexible addressing of the traffic
flow. Will using an 'address type' concept in the current tables will
solve this issue?  
[Orly Nicklass] Current pwType can dictate the  above. As we all look at
the NMS functionality, it seems as a single type of table simplifys the
implementation. As for the out/in-bound, both need  the TD.

        OK.

        OK.

pwAtmCfgTimeout

        --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 23 Mar 2007 09:50:16 -0400

On Mar 23, 2007:4:28 AM, at 4:28 AM, Orly Nicklass wrote:

> [ON] the idea was to use the existing tables with the same model  
> for all three modes and not have a table per mode. 1:1 table stays  
> for backward compatibility,   the n:1 can serve them all. Having  
> single table for all applicable modes indeed help the nms. I rather  
> leave this part as is
> [Ronen Solomon] I suggest you re-consider this so that the MIB  
> would be useful for NMS (this is what it is supposed to do). The  
> port-mode is a bi-directional direction (and The port mode would is  
> very useful for metro equipment that aggregate ATM switches), and  
> does not require separation for inbound and outbound. There is no  
> meaning to have this complexity for a simple port-node scenario.
>
>
> [Moshe] I can certainly appreciate the point of having one table  
> for all modes, and the point of having more flexible addressing of  
> the traffic flow. Will using an ‘address type’ concept in the  
> current tables will solve this issue?
> [Orly Nicklass] Current pwType can dictate the  above. As we all  
> look at the NMS functionality, it seems as a single type of table  
> simplifys the implementation. As for the out/in-bound, both need   
> the TD.
[TOM] I agree with Orly here %100. The only thing multiple tables  
does is make implementation/conformance of
		the agent-side of the code easier. However, it is more straight- 
forward for the NMS to simply
		talk to a single table and key off the PwType to make any  
refinements of interpreting the
		fields.

	--Tom

> implementation specific, we use en/dis only and leave the actual  
> time value to be in private space. In addition, en/dis allows  
> sparing the timeout value and controlling it externally.
> (ALL1 and ALL2 must have different timeout timers), and therefore  
> should be supported. Hence i believe it should appear as a standard  
> MIB. If HW does not support such configuration it could set a  
> default parameter.
>
> I like to get additional opinion here before we change it or add  
> the actual time value as an additional object or leave it as is.
>
> given
> [Ronen Solomon] Can you suggest a method , how would an NMS perform  
> such function ? It would require history data or some kind of  
> histogram PMs. It is much simpler and more efficient for the agent  
> to calculate a moving average, rather an NMS calculation together  
> with history PMs gathered by the agent.
> this

---

From: "Suberri, Moshe" <[email-masked]>
Date: Thu, 29 Mar 2007 13:59:29 -0400

In lines

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 9:50 AM
To: Orly Nicklass
Cc: Suberri, Moshe; Ronen Solomon; Danny McPherson; pwe3 WG
((((((((E-mail)))))))); [email-masked];
[email-masked]
Subject: Re: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

in lines

-----Original Message-----

[TOM] I agree with Orly here %100. The only thing multiple tables does
is make implementation/conformance of

                        the agent-side of the code easier. However, it
is more straight-forward for the NMS to simply

                        talk to a single table and key off the PwType to
make any refinements of interpreting the

                        fields.

            --Tom

[Moshe] I agree that a single cohesive table will help in the data
management and the implementation. Now that we agree on a single table,
why not combine the 2 outbound tables ( pwAtmOutboundTable,
pwAtmOutboundNto1Table) into one outbound table and do the same for the
inbound tables. And pwType will inform the NMS on how the specialize the
behavior of each row.    

        OK.

        OK.

pwAtmCfgTimeout

        --Tom

---

From: "Orly Nicklass" <[email-masked]>
Date: Thu, 29 Mar 2007 21:20:56 +0200

Moshe,
The idea was to use the existing tables with the same model for all
three modes and not have a table per mode. 1:1 table stays for backward
compatibility,   the n:1 should be used with new implementations and it
is indeed support all 3 modes.
 
To All,
I assume LC time is over by now, can we conclude the following:
#1-no change
#2-change RO to RW optional 
#3-either no change or adding a new object with time pwAtmCfgTimeout --I
would go for no change if I hear nothing
#4-no change
 
tnx
Orly

From: Suberri, Moshe [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 19:59
To: Thomas D. Nadeau; Orly Nicklass
Cc: Ronen Solomon; Danny McPherson; pwe3 WG ((((((((E-mail))))))));
[email-masked]; [email-masked]
Subject: RE: [PWE3] WG LC: draft-ietf-pwe3-pw-atm-mib-02.txt 

In lines

 

in lines

-----Original Message-----

                        fields.

            --Tom

        OK.

        OK.

pwAtmCfgTimeout

        --Tom