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

[Acee Lindem <[e-mail]>]

Hi Masanori,
Based on our discussion off-list and the definition of tedLinkIndex, this satisfies my concerns with the draft.

>> tedLinkIndex OBJECT-TYPE
>>   SYNTAX       OCTET STRING (SIZE (0..8))
>>   MAX-ACCESS   not-accessible
>>   STATUS       current
>>   DESCRIPTION
>>     "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."
>> ::= { tedEntry XX }
>> ------


Thanks,
Acee

On Mar 7, 2012, at 2:34 AM, Masanori Miyazawa wrote:

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