Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib
"Masanori Miyazawa" <ma-miyazawa@kddilabs.jp> Sun, 01 May 2011 00:50 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 D9D73E06AF for <ccamp@ietfa.amsl.com>; Sat, 30 Apr 2011 17:50:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poGx3A6gMXhB for <ccamp@ietfa.amsl.com>; Sat, 30 Apr 2011 17:50:21 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 99128E0593 for <ccamp@ietf.org>; Sat, 30 Apr 2011 17:50:19 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 10AF7174835D; Sun, 1 May 2011 09:50:15 +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 U2A-FrgLeLa8; Sun, 1 May 2011 09:50:14 +0900 (JST)
Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id 563E41748396; Sun, 1 May 2011 09:50:14 +0900 (JST)
Received: from miyazawaPC (unknown [172.19.64.90]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 4006C1E0004; Sun, 1 May 2011 09:50:14 +0900 (JST)
From: Masanori Miyazawa <ma-miyazawa@kddilabs.jp>
To: 'Ben Wright' <Ben.Wright@metaswitch.com>, 'CCAMP' <ccamp@ietf.org>
References: <4DAC8EBF.6080400@labn.net> <366E5F2A62306A4783C60773E99A8D62976EBB6C88@ENFIMBOX1.ad.datcon.co.uk>
In-Reply-To: <366E5F2A62306A4783C60773E99A8D62976EBB6C88@ENFIMBOX1.ad.datcon.co.uk>
Date: Sun, 01 May 2011 09:50:17 +0900
Message-ID: <026d01cc0799$bdb29590$3917c0b0$@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: Acv9/aW/CozRUe4rRbO21+TWEhXQ5QCCDyTQAdCyv1A=
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: Sun, 01 May 2011 00:50:22 -0000
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. 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 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 > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp
- [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