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

From: Acee Lindem <[email-masked]>
Date: Sun, 18 Mar 2012 18:50:22 -0400

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Mar 2012 10:43:58 -0400

Thank you Acee,

Authors,

Looks like we won't be able to request publication until these comments
are addressed.  (Better to address them now rather than IETF LC.)  I
suggest taking advantage of authors and Acee being together next week
and closing these issues.  If it helps, we can make some room in our
overly tight agenda for discussion -- expect the chairs to ask about
status either way...

Lou

On 3/18/2012 6:50 PM, Acee Lindem wrote:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Tue, 20 Mar 2012 22:36:17 +0900

Acee,
Thank you for your comments. 
I will review the latest version based on your comments.

Lou,
Thank you for your help. Unfortunately, I won't be able to attend the next
week's meeting, so I want to have discussions by e-mail.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lou Berger
> Sent: Monday, March 19, 2012 11:44 PM
> To: Acee Lindem; [email-masked]
> Cc: CCAMP
> Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
> 
> Thank you Acee,
> 
> Authors,
> 
suggest
> taking advantage of authors and Acee being together next week and closing
> these issues.  If it helps, we can make some room in our overly tight
agenda
> for discussion -- expect the chairs to ask about status either way...
> 
> Lou
> 
> > 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.
> >
> >    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.
> >

---

From: "Masanori Miyazawa" <[email-masked]>
Date: Thu, 22 Mar 2012 00:12:45 +0900

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

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

>    2. Bandwidth values - All the bandwidth values are represented as bytes
representation
> 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 }
----------------

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

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

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

> 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
> 
significant
>   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
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.
> 
>    2. Bandwidth values - All the bandwidth values are represented as bytes
representation
>    3. For the TED table, please move tedLocalRouterID and
TedRemoteRouterID
> so the items constituting the index are in the beginning of the TED entry.
>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 Mar 2012 12:31:15 -0400

Hi Masanori, 

See one comment inline. Hopefully, the message quoting won't be lost. 

> I modified the lengths of the textual convention.

Looks good. 

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

This is correct in draft-ietf-ccamp-gmpls-ted-mib-11.txt. 

>     " OSPF Extensions in support of GMPLS, [RFC4203], 1.3 "

Ok. 

Thanks,
Acee