Subject: [MIB-DOCTORS] RE: [IPFIX] IPFIX MIB: ipfixTransportSessionIndex and sctpAssocId

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 2 Feb 2007 16:11:07 +0100

Dear all,

I just want to summarize what I read here regarding this topic.

- So Unsigned64 does not exist so the original proposal from Benoit does not
work
- all other proposals use double indexing in some kind

Thus we need a separate object for the SCTP Association Id anyway.

My conclusion is:

Leave the table as it stands right now. So we have a single index per
transport session and can refer to the SCTP Association Id directly if we
use SCTP.

Benoit, what do you think.

Regards,

Thomas

-- 
Thomas Dietz                       E-mail: [email-masked]
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de

NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]] 
> Sent: Tuesday, January 30, 2007 9:39 PM
> To: 'kobayashi atsushi'; 'Chris Elliott'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [IPFIX] IPFIX MIB: ipfixTransportSessionIndex 
> and sctpAssocId
> 
> Hi,
> 
> I agree that using {protocol, sessionIndex} to create a discriminated
> union avoids the problem of overlapping sessionIndex values, and would
> allow the sessionIndex to be the value of the corresponding
> sctpAssocId. 
> 
> David Harrington
> [email-masked] 
> [email-masked]
> [email-masked]
> IETF MIB Doctor
> 
> > -----Original Message-----
> > From: kobayashi atsushi [mailto:[email-masked]] 
> > Sent: Monday, January 29, 2007 7:53 AM
> > To: Chris Elliott
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [IPFIX] IPFIX MIB: ipfixTransportSessionIndex 
> > and sctpAssocId
> > 
> > 
> > Chris,
> > 
> > I understand your proposal.
> > 
> > Even if ipfixTransportSessionIndex overlaps between SCTP and
> non-SCTP,
> > the index pair of ipfixTransportSessionProtocol and
> > ipfixTransportSessionIndex can be avoided overlapping as indexes.
> > By indexes of ipfixTransportSessionProtocol and 
> > ipfixTransportSessionIndex,
> > the value of ipfixTransportSessionIndex can be allocated within each
> > protocol and can share sctpAssocId.
> > 
> > On the point of view about dependency on SCTP, I think that 
> > it is better.
> > 
> > Best Regards,
> > Atsushi KOBAYASHI
> > 
> > On Fri, 26 Jan 2007 04:11:10 -0500 (EST)
> > Chris Elliott <[email-masked]> wrote:
> > 
> > > Atsushi KOBAYASHI,
> > > 
> > > I think the concern is that there could be overlap in the 
> > values used for 
> > > sctpAssocId and those used for non-SCTP sessions. This MIB 
> > module cannot 
> > > guarantee there will not be a collision of values because 
> > it does not 
> > > control the values selected for sctpAssocId. No matter what 
> > value is 
> > > picked for the index for a non-SCTP session it's possible 
> > that a new SCTP 
> > > session would use the same index.
> > > 
> > > Chris.
> > > 
> > > On Fri, 26 Jan 2007, kobayashi atsushi wrote:
> > > 
> > > > Benoit and Chris,
> > > >
> > > > I see the double indexes.
> > > >
> > > > If ipfixTransportSessionProtocol and 
> > ipfixTransportSessionIndex become
> > > > the indexes as following table, 
> > ipfixTransportSessionIndex can refer
> > > > sctpAssocId directly. How about this?
> > > >
> > > > ipfixTransportSessionTable
> > > > * ipfixTransportSessionProtocol
> > > > * ipfixTransportSessionIndex --> if sctp, sctpAssocId is used.
> > > >   ipfixTransportAddressType
> > > >   ipfixTransportSessionSourceAddress
> > > >   ipfixTransportSessionDestinationAddress
> > > >   ipfixTransportSessionSourcePort
> > > >   ipfixTransportSessionDestinationPort
> > > >   ipfixTransportSessionSctpAssocId --> remove
> > > >
> > > > If the name of sctpAssocId is used directly, there is a 
> > dependency on
> > > > the SCTP MIB. I think it's better that object name is not
> referred
> > > > directly.
> > > >
> > > >   ipfixTransportSessionEntry OBJECT-TYPE
> > > >       SYNTAX      IpfixTransportSessionEntry
> > > >       MAX-ACCESS  not-accessible
> > > >       STATUS      current
> > > >       DESCRIPTION
> > > >           "Defines an entry in the ipfixTransportSessionTable"
> > > >       INDEX       { ipfixTransportSessionProtocol,
> > > >                     ipfixTransportSessionIndex }
> > > >       ::= { ipfixTransportSessionTable 1 }
> > > >
> > > >    IpfixTransportSessionEntry ::=
> > > >        SEQUENCE {
> > > >           ipfixTransportSessionProtocol               Integer32,
> > > >           ipfixTransportSessionIndex
> Unsigned32,
> > > >           ipfixTransportSessionAddressType            
> > InetAddressType,
> > > >           ipfixTransportSessionSourceAddress
> InetAddress,
> > > >           ipfixTransportSessionDestinationAddress
> InetAddress,
> > > >           ipfixTransportSessionSourcePort             Integer32,
> > > >           ipfixTransportSessionDestinationPort        Integer32,
> > > >           ipfixTransportSessionTemplateRefreshTimeout
> Unsigned32,
> > > >           
> > ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,
> > > >           ipfixTransportSessionGroupId
> Unsigned32,
> > > >           ipfixTransportSessionGroupMemberType        INTEGER,
> > > >           ipfixTransportSessionStatus                 INTEGER
> > > >        }
> > > >
> > > >   ipfixTransportSessionIndex OBJECT-TYPE
> > > >       SYNTAX      Integer32 (0..2147483647)
> > > >       MAX-ACCESS  not-accessible
> > > >       STATUS      current
> > > >       DESCRIPTION
> > > >           "Locally arbitrary, but unique identifier of an entry
> in
> > > >           the ipfixTransportSessionTable. The value is expected
> to
> > > >           remain constant from a re-initialization of the
> entity's
> > > >           network management system to the next
> re-initialization.
> > > >
> > > >           The special value of zero (0) is reserved for use
> within
> > > >           the ipfixObservationDomainTable.
> > > >
> > > >           if ipfixTransportSessionProtocol have the value 
> > 132(SCTP),
> > > >           the value is able to equal the sctpAssocId in the
> > > >           sctpAssocTable defined in the SCTP MIB."
> > > >
> > > > On Thu, 25 Jan 2007 15:30:35 +0100
> > > > Benoit Claise <[email-masked]> wrote:
> > > >
> > > >> Chris,
> > > >>> Benoit,
> > > >>>
> > > >>> SNMP doesn't define Unsigned64. Just Counter64.
> > > >> Oops. I forgot that!
> > > >> This alone kills the proposal :)
> > > >>
> > > >> Thanks for the nice proposal below.
> > > >>
> > > >> Regards, Benoit.
> > > >>> And using Counter64 would be a hack. Further, it would 
> > exclude the use
> > > >>> of SNMPv1 to poll this table.
> > > >>>
> > > >>> I'd rather doubly-index the table and redefine
> > > >>> ipfixTransportSessionIndex to be used just for non-SCTP 
> > transports.
> > > >>> Here's a MIB fragment:
> > > >>>
> > > >>>   ipfixTransportSessionEntry OBJECT-TYPE
> > > >>>       SYNTAX      IpfixTransportSessionEntry
> > > >>>       MAX-ACCESS  not-accessible
> > > >>>       STATUS      current
> > > >>>       DESCRIPTION
> > > >>>           "Defines an entry in the ipfixTransportSessionTable"
> > > >>>       INDEX       { ipfixTransportSessionSctpAssocId,
> > > >>>                     ipfixTransportSessionNonSCTPIndex }
> > > >>>       ::= { ipfixTransportSessionTable 1 }
> > > >>>
> > > >>>    IpfixTransportSessionEntry ::=
> > > >>>        SEQUENCE {
> > > >>>           ipfixTransportSessionSctpAssocId            
> > Unsigned32,
> > > >>>           ipfixTransportSessionNonSCTPIndex
> Integer32,
> > > >>>           ipfixTransportSessionProtocol
> Integer32,
> > > >>>           ipfixTransportSessionAddressType            
> > InetAddressType,
> > > >>>           ipfixTransportSessionSourceAddress          
> > InetAddress,
> > > >>>           ipfixTransportSessionDestinationAddress     
> > InetAddress,
> > > >>>           ipfixTransportSessionSourcePort
> Integer32,
> > > >>>           ipfixTransportSessionDestinationPort
> Integer32,
> > > >>>           ipfixTransportSessionTemplateRefreshTimeout 
> > Unsigned32,
> > > >>>           
> > ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,
> > > >>>           ipfixTransportSessionGroupId                
> > Unsigned32,
> > > >>>           ipfixTransportSessionGroupMemberType        INTEGER,
> > > >>>           ipfixTransportSessionStatus                 INTEGER
> > > >>>        }
> > > >>>
> > > >>>    ipfixTransportSessionSctpAssocId OBJECT-TYPE
> > > >>>        SYNTAX      Unsigned32  (0..4294967295)
> > > >>>        MAX-ACCESS  not-accessible
> > > >>>        STATUS      current
> > > >>>        DESCRIPTION
> > > >>>            "The association id used for the SCTP 
> > session between the
> > > >>>            exporter and the collector of the IPFIX 
> > transport session.
> > > >>>            It equals the sctpAssocId in the sctpAssocTable
> > > >>>            defined in the SCTP MIB. If 
> > ipfixTransportSessionProtocol
> > > >>>            does not have the value 132 (SCTP) then the 
> > value of this
> > > >>>            object shall be zero (0)."
> > > >>>        ::= { ipfixTransportSessionEntry 1 }
> > > >>>
> > > >>>    ipfixTransportSessionNonSCTPIndex OBJECT-TYPE
> > > >>>        SYNTAX      Integer32 (0..2147483647)
> > > >>>        MAX-ACCESS  not-accessible
> > > >>>        STATUS      current
> > > >>>        DESCRIPTION
> > > >>>            "Locally arbitrary, but unique identifier of 
> > an entry in
> > > >>>            the ipfixTransportSessionTable if
> > > >>>            ipfixTransportSessionProtocol does not have 
> > the value 132
> > > >>>            (SCTP). The value of one (1) shall be used if
> > > >>>            ipfixTransportSessionProtocol does have the 
> > value 132 (SCTP).
> > > >>>
> > > >>>            The value is expected to remain constant from a
> > > >>>            re-initialization of the entity's network 
> > management system
> > > >>>            to the next re-initialization.
> > > >>>
> > > >>>            The special value of zero (0) is reserved 
> > for use within
> > > >>>            the ipfixObservationDomainTable."
> > > >>>        ::= { ipfixTransportSessionEntry 2 }
> > > >>>
> > > >>> This way, a row in this table can be accessed, for SCTP 
> > sessions by
> > > >>> specifying the instance ".<sctpAssocId>.1".
> > > >>>
> > > >>> While the use of zero is discouraged as an index value,
> placing
> > > >>> ipfixTransportSessionSctpAssocId first, thus ensuring that the
> > > >>> aggregate index will not end in zero, should meet the 
> > spirit of this
> > > >>> rule.
> > > >>>
> > > >>> Of course, all objects following these two in this 
> > table will have to
> > > >>> be renumbered due to this reordering.
> > > >>>
> > > >>> Chris.
> > > >>>
> > > >>> On Thu, 25 Jan 2007, Benoit Claise wrote:
> > > >>>
> > > >>>> Dear all,
> > > >>>>
> > > >>>> One more design question regarding the IPFIX-MIB.
> > > >>>>
> > > >>>>  ipfixTransportSessionTable  OBJECT-TYPE
> > > >>>>      SYNTAX      SEQUENCE OF IpfixTransportSessionEntry
> > > >>>>      MAX-ACCESS  not-accessible
> > > >>>>      STATUS      current
> > > >>>>      DESCRIPTION
> > > >>>>          "This table lists the currently established
> transport
> > > >>>>          sessions between an exporting process and a
> collecting
> > > >>>>          process."
> > > >>>>      ::= { ipfixObjects 2 }
> > > >>>>
> > > >>>>  ipfixTransportSessionEntry OBJECT-TYPE
> > > >>>>      SYNTAX      IpfixTransportSessionEntry
> > > >>>>      MAX-ACCESS  not-accessible
> > > >>>>      STATUS      current
> > > >>>>      DESCRIPTION
> > > >>>>          "Defines an entry in the ipfixTransportSessionTable"
> > > >>>>      INDEX       { ipfixTransportSessionIndex }        
> >    <------------
> > > >>>>      ::= { ipfixTransportSessionTable 1 }
> > > >>>>
> > > >>>>  IpfixTransportSessionEntry ::=
> > > >>>>      SEQUENCE {
> > > >>>>         ipfixTransportSessionIndex
> Integer32,
> > > >>>>         ipfixTransportSessionProtocol
> Integer32,
> > > >>>>         ipfixTransportSessionAddressType            
> > InetAddressType,
> > > >>>>         ipfixTransportSessionSourceAddress          
> > InetAddress,
> > > >>>>         ipfixTransportSessionDestinationAddress     
> > InetAddress,
> > > >>>>         ipfixTransportSessionSourcePort
> Integer32,
> > > >>>>         ipfixTransportSessionDestinationPort
> Integer32,
> > > >>>>         ipfixTransportSessionSctpAssocId
> Unsigned32,
> > > >>>> <------------
> > > >>>>         ipfixTransportSessionTemplateRefreshTimeout
> Unsigned32,
> > > >>>>         
> > ipfixTransportSessionOptionTemplateRefreshTimeout Unsigned32,
> > > >>>>         ipfixTransportSessionGroupId
> Unsigned32,
> > > >>>>         ipfixTransportSessionGroupMemberType        INTEGER,
> > > >>>>         ipfixTransportSessionStatus                 INTEGER
> > > >>>>      }
> > > >>>>  ipfixTransportSessionSctpAssocId OBJECT-TYPE
> > > >>>>      SYNTAX      Unsigned32
> > > >>>>      MAX-ACCESS  read-only
> > > >>>>      STATUS      current
> > > >>>>      DESCRIPTION
> > > >>>>          "The association id used for the SCTP session 
> > between the
> > > >>>>          exporter and the collector of the IPFIX 
> > transport session.
> > > >>>>          It equals to the sctpAssocId
> > > >>>> entry in the sctpAssocTable defined in the
> > > >>>>          SCTP MIB. This object is only valid if
> > > >>>>          ipfixTransportSessionProtocol has the value 
> > 132 (SCTP)."
> > > >>>>      ::= { ipfixTransportSessionEntry 8 }
> > > >>>>
> > > >>>>
> > > >>>>  ipfixTransportSessionIndex OBJECT-TYPE
> > > >>>>      SYNTAX      Integer32 (0..2147483647)
> > > >>>>      MAX-ACCESS  not-accessible
> > > >>>>      STATUS      current
> > > >>>>      DESCRIPTION
> > > >>>>          "Locally arbitrary, but unique identifier of 
> > an entry in
> > > >>>>          the ipfixTransportSessionTable. The value is 
> > expected to
> > > >>>>          remain constant from a re-initialization of 
> > the entity's
> > > >>>>          network management system to the next 
> > re-initialization.
> > > >>>>
> > > >>>>          The special value of zero (0) is reserved for 
> > use within
> > > >>>>          the ipfixObservationDomainTable."
> > > >>>>
> > > >>>> I've been trying to see if we could reuse sctpAssocId 
> > (RFC 3873)
> > > >>>> instead of the ipfixTransportSessionIndex
> > > >>>>
> > > >>>>  sctpAssocId OBJECT-TYPE
> > > >>>>    SYNTAX         Unsigned32 (1..4294967295)
> > > >>>>    MAX-ACCESS     not-accessible
> > > >>>>    STATUS         current
> > > >>>>    DESCRIPTION
> > > >>>>         "Association Identification. Value identifying the
> > > >>>>         association. "
> > > >>>>
> > > >>>>    ::= { sctpAssocEntry 1 }
> > > >>>>
> > > >>>> I see the advantages:
> > > >>>> - we don't need the ipfixTransportSessionSctpAssocId 
> > in the table
> > > >>>> - the management is easier: from the IPFIX MIB, we can 
> > directly poll
> > > >>>> the information in the SCTP MIB
> > > >>>>
> > > >>>> However, the drawbacks are that:
> > > >>>> - there is a dependency on the SCTP MIB
> > > >>>> - this would not work for UDP and TCP transport protocol
> > > >>>>
> > > >>>> Here is a proposal.
> > > >>>> Since sctpAssocId is Unsigned32, why not use
> > > >>>> ipfixTransportSessionIndex as Unsigned64 with the 
> > following assignment
> > > >>>> bit 0 to 31: reserved for UDP or TCP
> > > >>>> bit 32 to 62: contain the sctpAssocId. The value is 0 
> > if UDP or TCP
> > > >>>> is used.
> > > >>>>
> > > >>>> The advantage is that, in case of SCTP, the values of
> > > >>>> ipfixTransportSessionIndex and sctpAssocId are 
> > identical. The only
> > > >>>> difference is that ipfixTransportSessionIndex is 64 bits,
> while
> > > >>>> sctpAssocId is 32 bits. The disadvantage: we increase 
> > the bandwidth
> > > >>>> requirement as the table index is longer.
> > > >>>>
> > > >>>> We would like to request your feedback:
> > > >>>>   Do we make this unnecessary complicated?
> > > >>>>   Is it worth the pain to save one MIB variable?
> > > >>>>
> > > >>>> Regards, Benoit.
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> IPFIX mailing list
> > > >> [email-masked]
> > > >> https://www1.ietf.org/mailman/listinfo/ipfix
> > > >
> > > > ---
> > > > Atsushi KOBAYASHI  <[email-masked]>
> > > > NTT Information Sharing Platform Lab.
> > > > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> > > >
> > > 
> > > -- 
> > > Chris Elliott  CCIE# 2013       |         |
> > > Customer Diagnostic Engineer   |||       |||
> > > RTP, NC, USA                  |||||     |||||
> > > 919-392-2146              .:|||||||||:|||||||||:.
> > > [email-masked]        c i s c o S y s t e m s
> > 
> > --- 
> > Atsushi KOBAYASHI  <[email-masked]>
> > NTT Information Sharing Platform Lab.
> > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
> > 
> > 
> > 
> > _______________________________________________
> > IPFIX mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipfix
> > 
> 
> 
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix
> 
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Benoit Claise <[email-masked]>
Date: Wed, 07 Feb 2007 23:07:31 +0100

Thomas,
> Benoit, what do you think.
I'm fine with whatever proposals:
    - a single index per transport session with the SCTP Association Id 
in the table.
    - the double index.
Now, I agree that the double index complicates the MIB while keeping the 
SCTP association Id anyway...

Regards, Benoit.
> ------------------------------------------------------------------------
>