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

[Lou Berger <[e-mail]>]

Acee,
	Glad to hear this.

Authors,
	Please correct me if I'm mistaken, but I think this was the last open
issue on the document and that it'll be ready to move forward once the
update is submitted.  Is this correct?

Much thanks,
Lou

On 3/7/2012 5:56 AM, Acee Lindem wrote:
> 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
>>
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp