Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
"Masanori Miyazawa" <ma-miyazawa@kddilabs.jp> Thu, 05 April 2012 11:37 UTC
Return-Path: <ma-miyazawa@kddilabs.jp>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D0B21F873A for <ccamp@ietfa.amsl.com>; Thu, 5 Apr 2012 04:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.433
X-Spam-Level:
X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liv8JVUn02sE for <ccamp@ietfa.amsl.com>; Thu, 5 Apr 2012 04:37:48 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 64D2821F8694 for <ccamp@ietf.org>; Thu, 5 Apr 2012 04:37:47 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 771CC17480E4; Thu, 5 Apr 2012 20:37:46 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-uvDmByAM2K; Thu, 5 Apr 2012 20:37:45 +0900 (JST)
Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id CD77917480E3; Thu, 5 Apr 2012 20:37:45 +0900 (JST)
Received: from miyazawaVAIO (dhcp50.wlan.kddilabs.jp [172.19.110.50]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id B939F1E0002; Thu, 5 Apr 2012 20:37:45 +0900 (JST)
From: Masanori Miyazawa <ma-miyazawa@kddilabs.jp>
To: 'Acee Lindem' <acee.lindem@ericsson.com>
References: <4D336515-2D98-4DA7-8D58-28ED03C3854B@ericsson.com> <025501cd0775$11f2b820$35d82860$@jp> <051F9BE0-8E97-4F5C-A859-F9F5809474D4@ericsson.com>
In-Reply-To: <051F9BE0-8E97-4F5C-A859-F9F5809474D4@ericsson.com>
Date: Thu, 05 Apr 2012 20:37:42 +0900
Message-ID: <006d01cd1320$82ff67f0$88fe37d0$@kddilabs.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac0NADMKLs36/4zSQKSGCxBKc+az5AGG7LHw
Content-Language: ja
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 11:37:48 -0000
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:acee.lindem@ericsson.com] 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 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 >
- [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpl… Lou Berger
- Re: [CCAMP] [OSPF] Fwd: 2nd WG last call on draft… Lou Berger
- Re: [CCAMP] [OSPF] Fwd: 2nd WG last call on draft… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Ben Wright
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Acee Lindem
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Lou Berger
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Autumn Liu
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Acee Lindem
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Lou Berger
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Thomas Nadeau
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Tomohiro Otani
- [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpl… Acee Lindem
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Lou Berger
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Acee Lindem
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Acee Lindem
- Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-… Masanori Miyazawa