Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
"Masanori Miyazawa" <ma-miyazawa@kddilabs.jp> Wed, 21 March 2012 15:13 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 0F0E521F8734 for <ccamp@ietfa.amsl.com>; Wed, 21 Mar 2012 08:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 m-2qyOif4m84 for <ccamp@ietfa.amsl.com>; Wed, 21 Mar 2012 08:13:03 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 335D921F872B for <ccamp@ietf.org>; Wed, 21 Mar 2012 08:12:40 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 43E231748108; Thu, 22 Mar 2012 00:12:39 +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 xlgN1bSYdafo; Thu, 22 Mar 2012 00:12:38 +0900 (JST)
Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6EE8A17480CC; Thu, 22 Mar 2012 00:12:38 +0900 (JST)
Received: from miyazawaPC (unknown [172.19.64.90]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 591BF1E0002; Thu, 22 Mar 2012 00:12:38 +0900 (JST)
From: Masanori Miyazawa <ma-miyazawa@kddilabs.jp>
To: 'Acee Lindem' <acee.lindem@ericsson.com>, 'CCAMP' <ccamp@ietf.org>
References: <4D336515-2D98-4DA7-8D58-28ED03C3854B@ericsson.com>
In-Reply-To: <4D336515-2D98-4DA7-8D58-28ED03C3854B@ericsson.com>
Date: Thu, 22 Mar 2012 00:12:45 +0900
Message-ID: <025501cd0775$11f2b820$35d82860$@jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac0FWYEQpdF1gPaRTquD8Ib5KdDWywCGKVng
Content-Language: ja
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: Wed, 21 Mar 2012 15:13:07 -0000
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)) -------------- > 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 } ---------------- > 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. > -----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