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

["Suberri, Moshe" <[e-mail]>]

In lines

 

________________________________

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

 

 

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]
<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

 

 

[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.    

 





-----------------------------------------------------------
> 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] <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
<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-
<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 <http://www.ietf.org/shadow.html>  or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<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
<https://www1.ietf.org/mailman/listinfo/i-d-announce> 
>
>
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
<https://www1.ietf.org/mailman/listinfo/pwe3> 





 

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