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

[Thomas Nadeau <[e-mail]>]

	Thanks for the update Acee. I will work with Miyazawa-san to update the document.

	--Tom

On Mar 7, 2012, at 8:53 AM, Lou Berger wrote:

> 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
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>