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

["Thomas D. Nadeau" <[e-mail]>]

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

> in lines
>
>
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[e-mail]]
> Sent: Tuesday, March 20, 2007 5:26 PM
> To: Ronen Solomon
> Cc: [e-mail];
> [e-mail]; 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.
> [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

> -----------------------------------------------------------
> > 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).
>
>         OK.
> [ON] we can do that but leave the write op as optional.
>
>
> > 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.
>
>         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.
>
> ----------------------------
> 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 }
>
> ------------------------------------------
>
>
> > 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.
>
>         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.
>
> [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.
> --------------------------------
>
> 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
>
>
> >
> > Ronen
> >
> >
> >
> >
> > -----Original Message-----
> > From: Danny McPherson [mailto:[e-mail]]
> > 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
> >
> >
> > Begin forwarded message:
> >
> >> From: [e-mail]
> >> Date: February 13, 2007 1:50:03 PM MST
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> Subject: I-D ACTION:draft-ietf-pwe3-pw-atm-mib-02.txt
> >> Reply-To: [e-mail]
> >>
> >> 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
> >> [e-mail] 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:
> >>      [e-mail].
> >> 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: <[e-mail]>
> >>
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pwe3
>
>

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