Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib

["Masanori Miyazawa" <[e-mail]>]

Hi, Acee

Regarding your comments about the definition of index, we think we have to
redefine new indexes in tedTable. 
Here are my idea. If you have no additional comments, we will modify them
and post the updated draft.

tedEntry OBJECT-TYPE
    SYNTAX       TedEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
    "This entry contains TED information commonly utilized in both MPLS and
GMPLS."
   INDEX { tedLinkInformationSource, tedLinkRouterId, tedLinkRemoteRouterID,
tedLinkIndex}
::= { tedTable 1 }

tedLinkInformationSource  ->  ospf, isis etc
tedLinkRouterId  ->  the router ID of the node who originated information
about this link
tedLinkRemoteRouterId  -> the router at the remote end of the link 
tedLinkIndex    -> This index indicates a unique index or arbitrary value to
distinguish between multiple parallel links between routers. If OSPF is
used, this object contains the value of ospfLsdbID as unique index. If ISIS
is used, this object represents the value of isisLSPID as unique index.If a
locally configured link is used, this object represents an arbitrary value
which is locally defined in a router."

Regards,
Masanori

> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]]
> Sent: Monday, May 02, 2011 4:32 AM
> To: Masanori Miyazawa
> Cc: Ben Wright; CCAMP
> Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> Hi Masanori,
> 
> 
> On Apr 30, 2011, at 8:50 PM, Masanori Miyazawa wrote:
> 
> > Hi, Ben
> >
> > Thank you for your comments.
> > I have my answer for your comments inline below.
> > If you have any comments, please let us know.
> >
> > With best Regards,
> > Masanori
> >
> >> *	The tedTable structure doesn't make it easy for network
> >> administrators to query just the TED entries that are learned from,
> >> say,
> >> OSPFv2 (rather than ISIS).  An easy fix for this would be to make the
> > primary
> >> index field the information source (OSPFv2, ISIS etc).  This would
> >> also make the interpretation of the syntax of the remaining index
> >> fields straightforward for MIB agents.
> >
> > To simplify the index field, we define a new primary index (e.g.
> > tedIndex) and use it as index in the tedTable as below. Then, I think
> > you have accessibility to TE link information.
> 
> 
> What is the definition of the this index? You don't want to leave it up
> to the implementation as this will lead to different semantics.
> 
> Also, you should allow 0 in the range for Area IDs as 0 is certainly a
valid
> OSPF area ID.
> 
> 
>    TedAreaIdTC ::= TEXTUAL-CONVENTION
>           DISPLAY-HINT "d"
>           STATUS       current
>           DESCRIPTION
>              "The area identifier of the IGP. If OSPF is used to
>    advertise LSA, this represents an ospfArea. If ISIS is used, this
>    represents an area address."
>           SYNTAX       Unsigned32 (1..4294967295)
> 
> Should be:
>           SYNTAX       Unsigned32 (0..4294967295)
> 
> 
> Thanks,
> Acee
> 
> 
> >
> > tedEntry OBJECT-TYPE
> >    SYNTAX       TedEntry
> >    MAX-ACCESS   not-accessible
> >    STATUS       current
> >    DESCRIPTION
> >    "This entry contains TED information commonly utilized in both MPLS
> > and GMPLS."
> >   INDEX { tedIndex }
> > ::= { tedTable 1 }
> >
> > TedEntry ::= SEQUENCE {
> >    tedIndex                     Unsigned32,
> >    tedAreaId                    TedAreaIdTC,
> >    tedRouterId                  TedRouterIdTC,
> >    tedLinkStateId               TedLinkStateIdTC,
> >    tedLinkInformationSource     INTEGER,
> >    tedLinkInformationData       RowPointer,
> >    tedLinkState                 INTEGER,
> >    tedLinkType                  INTEGER,
> >    tedRouterIdAddrType          InetAddressType,
> >    tedRouterIdAddr              InetAddress,
> >    tedLinkIdAddrType            InetAddressType,
> >    tedLinkIdAddr                InetAddress,
> >    tedMetric                    Integer32,
> >    tedMaxBandwidth              Unsigned32,
> >    tedMaxReservableBandwidth    Unsigned32,
> >    tedUnreservedBandwidthPri0   Unsigned32,
> >    tedUnreservedBandwidthPri1   Unsigned32,
> >    tedUnreservedBandwidthPri2   Unsigned32,
> >    tedUnreservedBandwidthPri3   Unsigned32,
> >    tedUnreservedBandwidthPri4   Unsigned32,
> >    tedUnreservedBandwidthPri5   Unsigned32,
> >    tedUnreservedBandwidthPri6   Unsigned32,
> >    tedUnreservedBandwidthPri7   Unsigned32,
> >    tedAdministrativeGroup       Integer32,
> >    tedLocalId                   Integer32,
> >    tedRemoteId                  Integer32,
> >    tedLinkProtectionType        BITS
> >    }
> >
> >
> >> *	The tedLocalIfAddrTable and tedRemoteIfAddrTable both use an
> >> arbitrary index to distinguish between the different IP addresses on
> >> a
> > given
> >> link.  Is there a reason why we can't just use the address type and
> > address
> >> as index fields instead?  That would guarantee, for a given set of IP
> >> addresses, the ordering of rows in the table is entirely predictable.
> >
> >
> > As you know, note that tedLocalIfAddrTable and tedRemoteIfAddrTable
> > are independently defined, because the Interface IP Address sub-TLV
> > may appear more than once within the same Link-TLV. Therefore, if the
> > address type and the address are used as index, another arbitrary
> > index, such as tedIndex, would be also needed to represent the
> > relationship with tedTable as below,
> >
> > tedLocalIfAddrTable OBJECT-TYPE
> >    SYNTAX       SEQUENCE OF TedLocalIfAddrEntry
> >    MAX-ACCESS   not-accessible
> >    STATUS       current
> >    DESCRIPTION
> >      "This table contains the IP address information of a local TE
link."
> > ::= { tedObjects 2 }
> >
> > tedLocalIfAddrEntry OBJECT-TYPE
> >    SYNTAX       TedLocalIfAddrEntry
> >    MAX-ACCESS   not-accessible
> >    STATUS       current
> >    DESCRIPTION
> >      "This entry contains the IP address information of the local TE
> link."
> >    INDEX { tedIndex, tedLocalifAddr }
> > ::= { tedLocalIfAddrTable 1 }
> >
> > TedLocalIfAddrEntry ::= SEQUENCE {
> >    tedLocalIfAddrType    InetAddressType,
> >    tedLocalIfAddr        InetAddress
> >    }
> >
> > tedLocalIfAddrType OBJECT-TYPE
> >    SYNTAX       InetAddressType
> >    MAX-ACCESS   read-only
> >    STATUS       current
> >    DESCRIPTION
> > "This object indicates the address type of the local TE link. Only
> > values unknown(0), ipv4(1) or ipv6(2) have to be supported."
> > ::= { tedLocalIfAddrEntry 2 }
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Ben Wright
> >> Sent: Thursday, April 21, 2011 6:32 PM
> >> To: CCAMP
> >> Subject: Re: [CCAMP] 2nd WG last call on
> >> draft-ietf-ccamp-gmpls-ted-mib
> >>
> >>
> >> Hi Masanori et al,
> >>
> >> I have a few minor comments on draft-ietf-ccamp-gmpls-ted-mib-08.
> >>
> >> * 	I agree with Wenhu's comments on the OSPF mailing list - we need
> >> to update the Textual Conventions to take into account ISIS syntax.
> >>
> >> *	The tedTable structure doesn't make it easy for network
> >> administrators to query just the TED entries that are learned from,
> >> say,
> >> OSPFv2 (rather than ISIS).  An easy fix for this would be to make the
> > primary
> >> index field the information source (OSPFv2, ISIS etc).  This would
> >> also make the interpretation of the syntax of the remaining index
> >> fields straightforward for MIB agents.
> >>
> >> *	The tedLocalIfAddrTable and tedRemoteIfAddrTable both use an
> >> arbitrary index to distinguish between the different IP addresses on
> >> a
> > given
> >> link.  Is there a reason why we can't just use the address type and
> > address
> >> as index fields instead?  That would guarantee, for a given set of IP
> >> addresses, the ordering of rows in the table is entirely predictable.
> >>
> >> Thanks,
> >>
> >> Ben
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of labn - Lou Berger
> >> Sent: 18 April 2011 20:19
> >> To: CCAMP
> >> Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> >>
> >> This mail begins a 2nd WG last call on:
> >>
> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08
> >>
> >> The draft has been updated after the earlier working group primarily
> >> based on MIB Dr. review and discussion on the ccamp list.
> >>
> >> This working group last call ends on May 2nd. This LC will be
> >> announced on the MPLS, OSPF, and ISIS WG lists.  Please send comments
> >> to the CCAMP mailing list.
> >>
> >> Lou (and Deborah)
> >> _______________________________________________
> >> CCAMP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >> _______________________________________________
> >> CCAMP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp