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

[Acee Lindem <[e-mail]>]

Hi Masanori, 

Yes - I believe this is correct. You also need to add it to the MIB imports:

Acee-Lindems-iMac-2:Desktop ealflin$ diff -c draft-ietf-ccamp-gmpls-ted-mib-11.txt.orig draft-ietf-ccamp-gmpls-ted-mib-11.txt
*** draft-ietf-ccamp-gmpls-ted-mib-11.txt.orig	2012-04-05 08:36:53.000000000 -0400
--- draft-ietf-ccamp-gmpls-ted-mib-11.txt	2012-04-05 08:38:13.000000000 -0400
***************
*** 352,357 ****
--- 352,359 ----
          FROM IANA-GMPLS-TC-MIB                     -- RFC4802 
         InetAddress, InetAddressType 
          FROM INET-ADDRESS-MIB                      -- [RFC4001] 
+        Float32TC
+         FROM FLOAT-TC-MIB                          -- [RFC6340] 
        ; 
      
     tedMIB MODULE-IDENTITY


Thomas Nadeau is the expert so you should also pass it by him. 

I don't have any more comments on this MIB and believe it is ready for advancement. 

Thanks,
Acee        
On Apr 5, 2012, at 7:37 AM, Masanori Miyazawa wrote:

> Hi, Acee
> 
> Thank you for your comments.
> 
> I modified the definition of the bandwidth based on your comments. 
> In order to use the Float32TC, the Float32TC is imported in this mib, the
> syntax of the objects related to TE bandwidth is defined as Float32TC.
> Would that be right?
> 
> -----example-----------
> tedMaxBandwidth OBJECT-TYPE
>    SYNTAX       Float32TC
>    UNITS        "bit per seconds"
>    MAX-ACCESS   read-only
>    STATUS       current
>    DESCRIPTION
>      "This indicates the maximum bandwidth that can be used on this link in
> this direction."
> REFERENCE
> 	 " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC
> 3630], 2.5.6"
> ::= { tedEntry 14 }
> 
> Regards,
> Masanori
> 
> -----Original Message-----
> From: Acee Lindem [mailto:[e-mail]] 
> Sent: Thursday, March 29, 2012 1:31 AM
> To: Masanori Miyazawa
> Cc: CCAMP
> Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> Hi Masanori, 
> 
> See one comment inline. Hopefully, the message quoting won't be lost. 
> 
> On Mar 21, 2012, at 11:12 AM, Masanori Miyazawa wrote:
> 
>> Acee,
>> 
>> Please see our answer to your comments as below and let us know if you 
>> have any question.
>> 
>> Regards,
>> Masanori
>> 
>>> 1. Many of the textual conventions are longer than they need to be.
>> While
>>> ISIS is, in general, more verbose than OSPF, you most of the textual 
>>> conventions are longer than they need to be.
>>> 
>>> 
>>>          TedAreaIdTC - This is 32 octets while I the longest ISIS
>> address
>>> is 20 octets. For OSPF, the Area ID is 4 octets.
>>>          TedRouterIDTC - This is 32 octets while the OSPF router ID 
>>> is
>>> 4 octets and the ISIS system ID is 6 octets.
>>> 
>>>     This really doesn't cause any problems but I think it needs to 
>>> be addressed.
>> 
>> I modified the lengths of the textual convention.
>> 
>> -----------
>> TedAreaIdTC ::= TEXTUAL-CONVENTION
>>      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       OCTET STRING (SIZE (0..20))
>> 
>> TedRouterIdTC ::= TEXTUAL-CONVENTION
>>      STATUS       current
>>      DESCRIPTION
>>         " The router identifier. If OSPF is used to advertise LSA, 
>> this represents a Router ID. If ISIS is used, this represents a System
> ID."
>>      SYNTAX       OCTET STRING (SIZE (0..6))
> 
> Looks good. 
> 
>> --------------
>> 
>>>  2. Bandwidth values - All the bandwidth values are represented as 
>>> bytes per second with an Unsigned32 range. However, RFC 3630 
>>> represents these values sing an IEEE floating point value. 
>>> Additionally, this
>> representation
>>> results in a maximum bandwidth value of 32Gbps (without error correct).
>>> I think this may soon become much too low (if not already).
>> 
>> As you mentioned, the definitions of the bandwidth value were wrong. 
>> In order to support RFC3630, I think that Syntax should be modified to 
>> OCTET STRING. The below is a example of the modification.
>> What do you think about the modification?
>> 
>> ---example of tedMaxBandwidth---
>> 
>> tedMaxBandwidth OBJECT-TYPE
>>   SYNTAX       OCTET STRING (SIZE(4))
>>   UNITS        "bit per seconds"
>>   MAX-ACCESS   read-only
>>   STATUS       current
>>   DESCRIPTION
>>     "This indicates the maximum bandwidth that can be used on this 
>> link in this direction."
>> REFERENCE
>> 	 " Traffic Engineering (TE) Extensions to OSPF Version 2, [RFC
> 3630], 
>> 2.5.6"
>> ::= { tedEntry 14 }
> 
> I always thought this was a real pain that IEEE floating point values were
> used for TE bandwidth. Aren't these semantics consistent across TE bandwidth
> values? 
> They are consistent in RFC 3630 and RFC 3784. Why not Float32TC from RFC
> 6340 rather than OCTET STRING(SIZE)4))?
> 
>  Float32TC ::= TEXTUAL-CONVENTION
>      STATUS       current
>      DESCRIPTION  "This type represents a 32-bit (4-octet) IEEE
>                    floating-point number in binary interchange format."
>      REFERENCE    "IEEE Standard for Floating-Point Arithmetic,
>                    Standard 754-2008"
>      SYNTAX       OCTET STRING (SIZE(4))
> 
> 
> 
>> ----------------
>> 
>>>  3. For the TED table, please move tedLocalRouterID and
>> TedRemoteRouterID
>>> so the items constituting the index are in the beginning of the TED
> entry.
>> 
>> These indexes were displaced forward. Would that be right?
>> 
>> -------
>> 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 { tedLocalRouterId, tedRemoteRouterId, 
>> tedLinkInformationSource, tedLinkIndex }
> 
> This is correct in draft-ietf-ccamp-gmpls-ted-mib-11.txt. 
> 
> 
>> 
>>>  4. For tedSrlgIndex, should there be a reference another RFC?
>> 
>> I added RFC4203 in tedSrlg as a reference.
>> 
>> -------
>> tedSrlgIndex OBJECT-TYPE
>>   SYNTAX       Unsigned32(1..255)
>>   MAX-ACCESS   not-accessible
>>   STATUS       current
>>   DESCRIPTION
>>     "This index is utilized to identify multiple SRLG values on a 
>> local or remote TE link. This object represents an arbitrary value 
>> which is locally defined in a router".
>>   REFERENCE
>>    " OSPF Extensions in support of GMPLS, [RFC4203], 1.3 "
>> 
>> ::= { tedSrlgEntry 1 }
>> -------
> 
> Ok. 
> 
> 
>> 
>> 
>>>  5. Section 11 is missing one of the key reviewers ;^).
>> My sincere apologies for missing you as a reviewer. We appreciate very 
>> much the support from you.
> 
> Thanks,
> Acee
> 
> 
> 
>> 
>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On 
>>> Behalf Of Acee Lindem
>>> Sent: Monday, March 19, 2012 7:50 AM
>>> To: CCAMP
>>> Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
>>> 
>>> Hey Masanori, Tomohiro, and Tom,
>>> 
>>> Lou asked me to take another look at this draft and I have some
>> significant
>>> comments/questions.
>>> 
>>> 
>>> 1. Many of the textual conventions are longer than they need to be.
>> While
>>> ISIS is, in general, more verbose than OSPF, you most of the textual 
>>> conventions are longer than they need to be.
>>> 
>>> 
>>>          TedAreaIdTC - This is 32 octets while I the longest ISIS
>> address
>>> is 20 octets. For OSPF, the Area ID is 4 octets.
>>>          TedRouterIDTC - This is 32 octets while the OSPF router ID 
>>> is
>>> 4 octets and the ISIS system ID is 6 octets.
>>> 
>>>     This really doesn't cause any problems but I think it needs to 
>>> be addressed.
>>> 
>>> 
>>>  2. Bandwidth values - All the bandwidth values are represented as 
>>> bytes per second with an Unsigned32 range. However, RFC 3630 
>>> represents these values sing an IEEE floating point value. 
>>> Additionally, this
>> representation
>>> results in a maximum bandwidth value of 32Gbps (without error correct).
>>> I think this may soon become much too low (if not already).
>>> 
>>> 
>>>  3. For the TED table, please move tedLocalRouterID and
>> TedRemoteRouterID
>>> so the items constituting the index are in the beginning of the TED
> entry.
>>> 
>>>  4. For tedSrlgIndex, should there be a reference another RFC?
>>> 
>>>  5. Section 11 is missing one of the key reviewers ;^).
>>> 
>>> 
>>> Thanks,
>>> Acee
>> 
>