From B.Hedstrom@CableLabs.com Wed May 4 08:22:45 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2070E07A0 for ; Wed, 4 May 2011 08:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.138 X-Spam-Level: ** X-Spam-Status: No, score=2.138 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 UDyUMCdcR4qs for ; Wed, 4 May 2011 08:22:45 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2FE0750 for ; Wed, 4 May 2011 08:22:44 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id p44FMhxh025645 for ; Wed, 4 May 2011 09:22:43 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 4 May 2011 09:22:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 4 May 2011 09:22:43 -0600 From: Brian Hedstrom To: NETMOD Working Group Date: Wed, 4 May 2011 09:22:39 -0600 Thread-Topic: yangstrip tool Thread-Index: AcwKbw87sQKgPPXzTPqQjVxg8ZEITw== Message-ID: <76AC5FEF83F1E64491446437EA81A61F7D3579E7F8@srvxchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_76AC5FEF83F1E64491446437EA81A61F7D3579E7F8srvxchg_" MIME-Version: 1.0 X-Approved: ondar Subject: [netmod] yangstrip tool X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 15:22:46 -0000 --_000_76AC5FEF83F1E64491446437EA81A61F7D3579E7F8srvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETMOD WG, We have the smistrip tool that will extract MIBs from RFCs as part of libsm= i. Do we have a yangstrip tool that will extract YANG modules from RFCs? Thanks, Brian Hedstrom Senior Architect, Business & Operational Support Systems CableLabs, Inc. 858 Coal Creek Circle Louisville, CO 80027 Direct: 303.661.3829 eFax: 303.664.8120 AIM: brzahedstrom Skype IM: brian.hedstrom b.hedstrom@cablelabs.com --_000_76AC5FEF83F1E64491446437EA81A61F7D3579E7F8srvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

NETMOD WG,<= /o:p>

We have the smistrip tool that will extract M= IBs from RFCs as part of libsmi.

Do we h= ave a yangstrip tool that will extract YANG modules from RFCs?

 

Thanks,

 

= Brian Hedstrom
Senior Architect, Busine= ss & Operational Support Systems
CableLabs, Inc.
858 Coal Creek C= ircle
Louisville, CO 80027
Direct: 303.661.3829
eFax: 303.664.8120=
AIM: brzahedstrom
Skype IM: brian.hedstrom
b.hedstrom@cablelabs.com

=

 

= --_000_76AC5FEF83F1E64491446437EA81A61F7D3579E7F8srvxchg_-- From mbj@tail-f.com Wed May 4 13:59:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2BBE07D3 for ; Wed, 4 May 2011 13:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553] 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 zSZJ75Hk7rWB for ; Wed, 4 May 2011 13:59:30 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id EE0D3E06B7 for ; Wed, 4 May 2011 13:59:29 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id ECC7D76C31A; Wed, 4 May 2011 22:59:27 +0200 (CEST) Date: Wed, 04 May 2011 22:59:25 +0200 (CEST) Message-Id: <20110504.225925.153708592.mbj@tail-f.com> To: B.Hedstrom@CableLabs.com From: Martin Bjorklund In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7D3579E7F8@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7D3579E7F8@srvxchg> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] yangstrip tool X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 20:59:31 -0000 Hi, Brian Hedstrom wrote: > NETMOD WG, > We have the smistrip tool that will extract MIBs from RFCs as part of libsmi. > Do we have a yangstrip tool that will extract YANG modules from RFCs? There is a tool called 'rfcstrip' which is based on smistrip, that can extract YANG modules from RFCs and I-Ds. It is available at http://www.yang-central.org/twiki/bin/view/Main/YangTools. I think it is based on an old version of smistrip, and it might need some updates in the MIB extracion parts, but it works just fine for YANG modules. /martin From j.schoenwaelder@jacobs-university.de Thu May 5 01:43:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA71E06FF for ; Thu, 5 May 2011 01:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.168 X-Spam-Level: X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 MkCLgK2qtu1L for ; Thu, 5 May 2011 01:43:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B302CE06F9 for ; Thu, 5 May 2011 01:43:03 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC65720C2C; Thu, 5 May 2011 10:43:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gBDFe18JsUK6; Thu, 5 May 2011 10:43:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C2B720C2A; Thu, 5 May 2011 10:43:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9B83E185D5D7; Thu, 5 May 2011 10:42:55 +0200 (CEST) Date: Thu, 5 May 2011 10:42:55 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110505084255.GA10488@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20110405100141.GD68335@elstar.local> <20110409.131500.138692468.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110409.131500.138692468.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:43:05 -0000 On Sat, Apr 09, 2011 at 01:15:00PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > * smi2yang-04: string vs. binary > > > > It would be nice to have a reliable mechanism to determine whether > > an OCTET STRING can be represented as a human readable string or is > > a binary string. The current ID suggests to use the presence of a > > DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a > > DISPLAY-HINT when a MIB module is revised, which can lead to > > different translations of different versions of a MIB module. > > > > ** Solution #04-01 > > > > Declare this a non-problem since additions of DISPLAY-HINTs are > > rare. > > I prefer this solution. We should clearly specify what effect this > legal SMIv2 change (and #02) have on YANG revisioning. > > > ** Solution #04-02 > > > > Translate strings into unions that allows both a human readable > > string representation and a binary representation. However, this > > requires to have some mechanism in place to decide whether a value > > is a human readable string or a binary string, which means we > > likely have to mess around with values. > > > > ** Solution #04-03 > > > > Always translate OCTET STRING types into the YANG binary types. We > > could list some well-known types as exceptions, like DisplayString, > > SnmpAdminString, DateAndTime but such a list will always be > > incomplete and hence some human readable data will be encoded into > > base64. Any other opinions? If I do not see more discussion on the list, I (as editor) will assume solution #04-01 has been adopted by the WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu May 5 01:45:50 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87975E0693 for ; Thu, 5 May 2011 01:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nWZakA7vqYIx for ; Thu, 5 May 2011 01:45:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB21AE0691 for ; Thu, 5 May 2011 01:45:49 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDF0D20C1E for ; Thu, 5 May 2011 10:45:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LUSaZZKLKAyB; Thu, 5 May 2011 10:45:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57AAC20C1B; Thu, 5 May 2011 10:45:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1E083185D648; Thu, 5 May 2011 10:45:43 +0200 (CEST) Date: Thu, 5 May 2011 10:45:43 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110505084543.GB10488@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 08:45:50 -0000 * smi2yang-08: inline vs. outside smiv2:oid mapping [open] The current translation uses the smiv2:oid to denote the OID of constructs that are mapped to YANG. However, this leaves out any constructs or OID descriptors that are not mapped to YANG. ** Solution #08-01 Do not inline OID definition but instead create a separate "section" at the end of a YANG module that just contains the OID mappings: smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias "ifNumber"; } This means less "noise" in the YANG definitions and it allows to capture all known OID descriptors within the YANG module. The downside is that in order to find out the OID for say a leaf like ifNumber, one has to do a lookup. I would love to hear opinions so that this can be resolved and closed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu May 5 04:51:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84333E086B for ; Thu, 5 May 2011 04:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 w8XlX-jpx+C5 for ; Thu, 5 May 2011 04:51:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B650DE0865 for ; Thu, 5 May 2011 04:51:05 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD38E20C0F for ; Thu, 5 May 2011 13:51:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e-ZD2UNjANDB; Thu, 5 May 2011 13:51:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25A2920709; Thu, 5 May 2011 13:51:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C4F6A185F70E; Thu, 5 May 2011 13:50:58 +0200 (CEST) Date: Thu, 5 May 2011 13:50:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110505115058.GA12081@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:51:06 -0000 The current translation creates multiple top-level containers. This is somewhat at odds with a guideline given in RFC 6087: There SHOULD only be one top-level data node defined in each YANG module, if any data nodes are defined at all. I do not recall the precise reasoning behind this SHOULD so it is not clear to me whether this is a problem or not. ** Solution #09-01 Declare that the SHOULD allows to us to have multiple top-level containers. ** Solution #09-02 Create an additional (but redundant) container (e.g. named after the module) so we comply to the rule defined in RFC 6087. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Thu May 5 09:57:04 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360FDE0749 for ; Thu, 5 May 2011 09:57:04 -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 7q-zBSbttzmn for ; Thu, 5 May 2011 09:57:03 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 15844E074B for ; Thu, 5 May 2011 09:57:02 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA29865; Thu, 5 May 2011 12:57:01 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA27599; Thu, 5 May 2011 12:57:00 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 5 May 2011 12:56:59 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110505084543.GB10488@elstar.local> Message-ID: References: <20110505084543.GB10488@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 16:57:04 -0000 What was the outcome of the discussion regarding whether the converted YANG document would have containers to mirror the branching of the MIB tree? -dss On Thu, 5 May 2011, Juergen Schoenwaelder wrote: > * smi2yang-08: inline vs. outside smiv2:oid mapping [open] > > The current translation uses the smiv2:oid to denote the OID of > constructs that are mapped to YANG. However, this leaves out any > constructs or OID descriptors that are not mapped to YANG. > > ** Solution #08-01 > > Do not inline OID definition but instead create a separate > "section" at the end of a YANG module that just contains the > OID mappings: > > smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } > smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias "ifNumber"; } > > This means less "noise" in the YANG definitions and it allows to > capture all known OID descriptors within the YANG module. The > downside is that in order to find out the OID for say a leaf like > ifNumber, one has to do a lookup. > > I would love to hear opinions so that this can be resolved and closed. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From phil@juniper.net Thu May 5 10:47:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815ABE0901 for ; Thu, 5 May 2011 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TStq47exDr8x for ; Thu, 5 May 2011 10:47:10 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5A674E08D8 for ; Thu, 5 May 2011 10:47:05 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTcLimGlpGWbRejEgoDq96F/FCyRwIlsX@postini.com; Thu, 05 May 2011 10:47:08 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 5 May 2011 10:43:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p45HhKv74304; Thu, 5 May 2011 10:43:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p45HJB0T006394; Thu, 5 May 2011 17:19:11 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201105051719.p45HJB0T006394@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20110505115058.GA12081@elstar.local> Date: Thu, 5 May 2011 13:19:11 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:47:10 -0000 Juergen Schoenwaelder writes: >** Solution #09-02 > Create an additional (but redundant) container (e.g. named after > the module) so we comply to the rule defined in RFC 6087. I vote for this, since it allows the entire module to be fetched in one operation and enforces a natural hierarchy. Thanks, Phil From spakes@snmp.com Thu May 5 10:52:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6485AE067F for ; Thu, 5 May 2011 10:52:54 -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 oR07GPO0zXJM for ; Thu, 5 May 2011 10:52:53 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 29CE5E0684 for ; Thu, 5 May 2011 10:52:52 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA04452; Thu, 5 May 2011 13:52:43 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA06755; Thu, 5 May 2011 13:52:42 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 5 May 2011 13:52:42 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Phil Shafer In-Reply-To: <201105051719.p45HJB0T006394@idle.juniper.net> Message-ID: References: <201105051719.p45HJB0T006394@idle.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:52:54 -0000 Yes, I agree and vote similarly. -dss On Thu, 5 May 2011, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >** Solution #09-02 > > Create an additional (but redundant) container (e.g. named after > > the module) so we comply to the rule defined in RFC 6087. > > I vote for this, since it allows the entire module to be fetched > in one operation and enforces a natural hierarchy. > > Thanks, > Phil ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From Internet-Drafts@ietf.org Thu May 5 11:00:02 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A440E07CB; Thu, 5 May 2011 11:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2AgSGRjU3vQu; Thu, 5 May 2011 11:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F45E0749; Thu, 5 May 2011 11:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 11:00:01 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:00:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for Routing Configuration Author(s) : L. Lhotka Filename : draft-ietf-netmod-routing-cfg-00.txt Pages : 44 Date : 2011-04-27 This document contains a specification of two YANG modules that together provide a data model for essential configuration of a routing subsystem. It is expected that this module will serve as a basis for further development of data models for individual routing protocols and other related functions. The present data model defines the building blocks for such configurations - routing processes, routes and routing tables, routing protocol instances and route filters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-routing-cfg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05105726.I-D@ietf.org> --NextPart-- From biermana@Brocade.com Thu May 5 11:02:01 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9534E08AE for ; Thu, 5 May 2011 11:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 EV0VNhObAa0R for ; Thu, 5 May 2011 11:02:01 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 09EFBE062A for ; Thu, 5 May 2011 11:02:00 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p45HkmI3028966; Thu, 5 May 2011 11:01:59 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.141.11]) by mx0a-000f0801.pphosted.com with ESMTP id w3ufa07ua-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 05 May 2011 11:01:59 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE02.corp.brocade.com (144.49.141.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 5 May 2011 11:10:51 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::192e:5a11:9069:7a70]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 5 May 2011 11:01:46 -0700 From: Andy Bierman To: David Spakes , Phil Shafer Date: Thu, 5 May 2011 11:01:44 -0700 Thread-Topic: [netmod] smi2yang-09: multiple top-level containers Thread-Index: AcwLTUVV4iBG7dSGS6W3YFdczS7EjQAAHXEw Message-ID: References: <201105051719.p45HJB0T006394@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-05-05_07:2011-05-05, 2011-05-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1105050111 Cc: "netmod@ietf.org" Subject: Re: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:02:02 -0000 A) We don't vote in the IETF. We agree or disagree ;-) I agree with both of you. B) Does this mean the top-level container for scalars can be moved? Just move that container to the top-level, and make all data nodes (not just scalars) child nodes of that container. Andy -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= David Spakes Sent: Thursday, May 05, 2011 10:53 AM To: Phil Shafer Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-09: multiple top-level containers Yes, I agree and vote similarly. -dss On Thu, 5 May 2011, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >** Solution #09-02 > > Create an additional (but redundant) container (e.g. named after > > the module) so we comply to the rule defined in RFC 6087. > > I vote for this, since it allows the entire module to be fetched > in one operation and enforces a natural hierarchy. > > Thanks, > Phil ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From lhotka@cesnet.cz Thu May 5 11:12:09 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE9E0786 for ; Thu, 5 May 2011 11:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 DRhAd+Lf7mit for ; Thu, 5 May 2011 11:12:08 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 28E54E0688 for ; Thu, 5 May 2011 11:12:08 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 342472CDE058 for ; Thu, 5 May 2011 20:12:06 +0200 (CEST) From: Ladislav Lhotka Content-Type: multipart/signed; boundary=Apple-Mail-21--105588226; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 5 May 2011 20:12:06 +0200 References: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <171451E3-C998-48DB-98B2-8717CE96A373@cesnet.cz> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [netmod] Fwd: I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 18:12:09 -0000 --Apple-Mail-21--105588226 Content-Type: multipart/mixed; boundary=Apple-Mail-20--105588288 --Apple-Mail-20--105588288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this is a new version of the core routing data model. It now consists of = two YANG modules, one of them just defines top-level containers and the = other provides a basic framework for IPv4 unicast routing, and could = serve as a model for other address families. Please send your comments = to this mailing list. Thanks, Lada=20 Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: May 5, 2011 8:00:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org > Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt >=20 > A new Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : A YANG Data Model for Routing Configuration > Author(s) : L. Lhotka > Filename : draft-ietf-netmod-routing-cfg-00.txt > Pages : 44 > Date : 2011-04-27 >=20 > This document contains a specification of two YANG modules that > together provide a data model for essential configuration of a > routing subsystem. It is expected that this module will serve as a > basis for further development of data models for individual routing > protocols and other related functions. The present data model > defines the building blocks for such configurations - routing > processes, routes and routing tables, routing protocol instances and > route filters. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-20--105588288 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-05-05105726.I-D@ietf.org>

--Apple-Mail-20--105588288 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-20--105588288-- --Apple-Mail-21--105588226 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTA1MTgxMjA2WjAjBgkqhkiG9w0BCQQxFgQUI5S8vxU1+DoHALI6rMCPaoeQrqEwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQC2b0tDPCB6TW9G+5YqRtQ456sH 5EoEuTGOKbkD1sCeeW/fvuj8U3P9bcMQP8dNrTegioBE2A7msSHiWm/w8DQT/136OhByEHLs3yyU DcoKZXbsiFGtYV4xVN7Tl8DlPmJsTNLKQcr1x5gvJ0zNGsk7SGobD0+6ecdDv1bf4xetqHrkgCTK 4snace92K6wNRZB4Roll8SO8dbX/bkeAPdefntqaFBKs7f06LuIOpIY6vmN6XZnw/ILASmP7hl9O ziYn9aOWnkOrnRkEdcTXagWtSvjyH1A7JenlDlxpJcw/pGegMzdmJKBt03jE6UajIuC6y9b+b7fH GLHtpzgLikX/AAAAAAAA --Apple-Mail-21--105588226-- From phil@juniper.net Thu May 5 13:03:38 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AB1E09C2 for ; Thu, 5 May 2011 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 t25l8d+bOOOT for ; Thu, 5 May 2011 13:03:38 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id B537FE09DA for ; Thu, 5 May 2011 13:03:37 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTcMCmHWnmbOK3lU6coddRQHL93Jit8t8@postini.com; Thu, 05 May 2011 13:03:37 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 5 May 2011 13:01:18 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p45K1Hv41370 for ; Thu, 5 May 2011 13:01:17 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p45Jb8Pq007750 for ; Thu, 5 May 2011 19:37:08 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201105051937.p45Jb8Pq007750@idle.juniper.net> To: In-Reply-To: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> Date: Thu, 5 May 2011 15:37:08 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 20:03:38 -0000 > Title : A YANG Data Model for Routing Configuration There are a number of modern routing features that we should ensure are incorporated. I've not read the draft, but a quick skim found no mention of logical routers, chained next-hops, etc. I'm not sure if these are add-ons that will be layered on top of the model in later modules, but the picture with one FIB at the top makes me nervous. Do we have engagement from the routing community to ensure our model reflects today's needs? Also the use of the word "process" is confusing, since there should be minimal implementation constraints placed on the system. Even the word "process" is heavily overloaded, with unix geeks thinking you mean one thing and IOS users think another. I'd avoid the word. FWIW, in JUNOS, we call these "routing instances" and they run in the single JUNOS routing protocol daemon (RPD) (where logical routers get distinct daemons). However any such internal processes mappings are not visible to the user. Thanks, Phil From jmh@joelhalpern.com Thu May 5 14:23:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0CE0700 for ; Thu, 5 May 2011 14:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 QHvYdqiPG6ld for ; Thu, 5 May 2011 14:23:52 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E419E0593 for ; Thu, 5 May 2011 14:23:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D40C843B316; Thu, 5 May 2011 14:23:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.154.181.35] (unknown [129.192.147.67]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 5FC5343B313; Thu, 5 May 2011 14:23:46 -0700 (PDT) Message-ID: <4DC31560.3020808@joelhalpern.com> Date: Thu, 05 May 2011 17:23:44 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ladislav Lhotka References: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> <171451E3-C998-48DB-98B2-8717CE96A373@cesnet.cz> In-Reply-To: <171451E3-C998-48DB-98B2-8717CE96A373@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 21:23:54 -0000 Can you please elaborate a bit on the purpose of the model? Is it to enable configuring static routes? Is to to enable fetching the current forwarding behavior of the device? is it to give access to the common RIB, which consolidates the effect of different routing protocols? Is it ostensibly generic enough to serve as a bse, from whcih to subclass models for RIBs for different routing protocols? Before I try to evaluate the proposed model, I need to know what purpose it is intended to fulfill. (We have made the mistake before of building models for the sake of models. That proves not to be useful.) Yours, Joel On 5/5/2011 2:12 PM, Ladislav Lhotka wrote: > Hi, > > this is a new version of the core routing data model. It now consists of two YANG modules, one of them just defines top-level containers and the other provides a basic framework for IPv4 unicast routing, and could serve as a model for other address families. Please send your comments to this mailing list. > > Thanks, Lada > > Begin forwarded message: > >> From: Internet-Drafts@ietf.org >> Date: May 5, 2011 8:00:01 PM GMT+02:00 >> To: i-d-announce@ietf.org >> Cc: netmod@ietf.org >> Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt >> >> A new Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. >> >> Title : A YANG Data Model for Routing Configuration >> Author(s) : L. Lhotka >> Filename : draft-ietf-netmod-routing-cfg-00.txt >> Pages : 44 >> Date : 2011-04-27 >> >> This document contains a specification of two YANG modules that >> together provide a data model for essential configuration of a >> routing subsystem. It is expected that this module will serve as a >> basis for further development of data models for individual routing >> protocols and other related functions. The present data model >> defines the building blocks for such configurations - routing >> processes, routes and routing tables, routing protocol instances and >> route filters. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C >> >> >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From j.schoenwaelder@jacobs-university.de Thu May 5 23:19:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F16E067C for ; Thu, 5 May 2011 23:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 fVVjSykQKFuP for ; Thu, 5 May 2011 23:19:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 410E3E066A for ; Thu, 5 May 2011 23:19:45 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40B8420C1E; Fri, 6 May 2011 08:19:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J+MR-XxNJTZz; Fri, 6 May 2011 08:19:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BD2920C1D; Fri, 6 May 2011 08:19:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 42DF31860729; Fri, 6 May 2011 08:19:38 +0200 (CEST) Date: Fri, 6 May 2011 08:19:38 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110506061938.GB14287@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20110505084543.GB10488@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 06:19:48 -0000 On Thu, May 05, 2011 at 12:56:59PM -0400, David Spakes wrote: > What was the outcome of the discussion regarding whether the converted > YANG document would have containers to mirror the branching of the MIB > tree? We dropped this idea because there is no reliable way to obtain names for the containers: You can have multiple descriptors for a given OID so its not clear which one to choose. Furthermore, the order of OID value assignments can change when modules are revised and the number of descriptors per OID can also change when MIB modules are revised. So for these robustness reasons, we better only rely on descriptors introduced by macro invocations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri May 6 00:01:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531D2E0663 for ; Fri, 6 May 2011 00:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.176 X-Spam-Level: X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 y8C-aeaR-Ed4 for ; Fri, 6 May 2011 00:01:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 43D75E06BE for ; Fri, 6 May 2011 00:01:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB32D20C18; Fri, 6 May 2011 09:01:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LOY7bpYVzxKC; Fri, 6 May 2011 09:01:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1873920C06; Fri, 6 May 2011 09:01:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 85FF418607CF; Fri, 6 May 2011 09:01:07 +0200 (CEST) Date: Fri, 6 May 2011 09:01:07 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20110506070107.GA14445@elstar.local> Mail-Followup-To: Phil Shafer , netmod@ietf.org References: <20110505115058.GA12081@elstar.local> <201105051719.p45HJB0T006394@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105051719.p45HJB0T006394@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 07:01:17 -0000 On Thu, May 05, 2011 at 01:19:11PM -0400, Phil Shafer wrote: > Juergen Schoenwaelder writes: > >** Solution #09-02 > > Create an additional (but redundant) container (e.g. named after > > the module) so we comply to the rule defined in RFC 6087. > > I vote for this, since it allows the entire module to be fetched > in one operation and enforces a natural hierarchy. To fetch the 'entire module', you have to fetch the module's namespace since retrieving the top-level container(s) leaves out augmentations made in other subtrees. (Since NETCONF's subtree filtering mechanism does not support selecting just on a namespace, you need to know the set of top-level container(s).) I think my point is that the assumption that I can retrieve the 'entire module' by retrieving the top-level containers is potentially misleading. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri May 6 00:09:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2E2E0679 for ; Fri, 6 May 2011 00:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.178 X-Spam-Level: X-Spam-Status: No, score=-103.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 3-KBxKfLEW-X for ; Fri, 6 May 2011 00:09:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 72C9FE0659 for ; Fri, 6 May 2011 00:09:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 551E020C23; Fri, 6 May 2011 09:09:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kVZw0VClTiOb; Fri, 6 May 2011 09:09:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D56920C21; Fri, 6 May 2011 09:09:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E520E1860834; Fri, 6 May 2011 09:09:40 +0200 (CEST) Date: Fri, 6 May 2011 09:09:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20110506070940.GB14445@elstar.local> Mail-Followup-To: Andy Bierman , David Spakes , Phil Shafer , "netmod@ietf.org" References: <201105051719.p45HJB0T006394@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] smi2yang-09: multiple top-level containers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 07:09:54 -0000 On Thu, May 05, 2011 at 11:01:44AM -0700, Andy Bierman wrote: > A) We don't vote in the IETF. We agree or disagree ;-) > I agree with both of you. > > B) Does this mean the top-level container for scalars can > be moved? Just move that container to the top-level, > and make all data nodes (not just scalars) child nodes > of that container. Yes, one simple solution is to move the (non-augmenting) tables to the top-level container holding the scalars. That is, for the IF-MIB, we have: OLD: +--ro ifMIB | +--ro ifNumber? int32 | +--ro ifTableLastChange? yang:timeticks | +--ro ifStackLastChange? yang:timeticks +--ro ifTable | +--ro ifEntry [ifIndex] ... +--ro ifStackTable | +--ro ifStackEntry [ifStackHigherLayer ifStackLowerLayer] ... +--ro ifRcvAddressTable +--ro ifRcvAddressEntry [ifIndex ifRcvAddressAddress] NEW: +--ro ifMIB +--ro ifNumber? int32 +--ro ifTableLastChange? yang:timeticks +--ro ifStackLastChange? yang:timeticks +--ro ifTable | +--ro ifEntry [ifIndex] ... +--ro ifStackTable | +--ro ifStackEntry [ifStackHigherLayer ifStackLowerLayer] ... +--ro ifRcvAddressTable +--ro ifRcvAddressEntry [ifIndex ifRcvAddressAddress] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri May 6 02:36:08 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C277E0716 for ; Fri, 6 May 2011 02:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 3d-VVE7xr3jn for ; Fri, 6 May 2011 02:36:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5DDE071B for ; Fri, 6 May 2011 02:36:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D3D120C27 for ; Fri, 6 May 2011 11:36:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id w73UuVpTtuPW; Fri, 6 May 2011 11:36:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0CF020C1E; Fri, 6 May 2011 11:36:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 410481860EF5; Fri, 6 May 2011 11:35:58 +0200 (CEST) Date: Fri, 6 May 2011 11:35:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110506093558.GA15151@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] smi2yang-10: "reference" substatement for "revision" statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:36:08 -0000 RFC 6087 requires that every revision statement MUST has a reference statement. While this requirement makes sense for newly written modules, it does not make sense for modules derived from SMIv2 modules where this information is usually provided in the description clause. ** Solution #10-01 Declare that this is really a bug in RFC 6087 - the requirement should have been a SHOULD not a MUST to allow for SMIv2 derived modules that do not provide an explicit reference. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri May 6 03:03:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181CE06FD for ; Fri, 6 May 2011 03:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 xDaeb7TrifZ2 for ; Fri, 6 May 2011 03:03:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67AE06CE for ; Fri, 6 May 2011 03:03:53 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id D241F76C272; Fri, 6 May 2011 12:03:51 +0200 (CEST) Date: Fri, 06 May 2011 12:03:51 +0200 (CEST) Message-Id: <20110506.120351.2024566227150272768.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110506093558.GA15151@elstar.local> References: <20110506093558.GA15151@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-10: "reference" substatement for "revision" statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 10:03:54 -0000 Juergen Schoenwaelder wrote: > RFC 6087 requires that every revision statement MUST has a reference > statement. While this requirement makes sense for newly written > modules, it does not make sense for modules derived from SMIv2 > modules where this information is usually provided in the > description clause. 6087 says: This document defines a set of usage guidelines for Standards Track documents containing YANG [RFC6020] data models. and: A revision statement MUST be present for each published version of the module. The revision statement MUST have a reference substatement. It MUST identify the published document that contains the module. So the only question is what should be done if a YANG module generated from a MIB module gets published - should we manually modify the revision statement or not. /martin From j.schoenwaelder@jacobs-university.de Fri May 6 03:08:04 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A61E06FD for ; Fri, 6 May 2011 03:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 eGZdvMgBoGBb for ; Fri, 6 May 2011 03:08:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 681A5E06CE for ; Fri, 6 May 2011 03:08:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7659120C27; Fri, 6 May 2011 12:08:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WyLItytBpTa1; Fri, 6 May 2011 12:08:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D722620C28; Fri, 6 May 2011 12:08:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8FDB91861120; Fri, 6 May 2011 12:07:56 +0200 (CEST) Date: Fri, 6 May 2011 12:07:56 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110506100756.GA19655@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20110506093558.GA15151@elstar.local> <20110506.120351.2024566227150272768.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110506.120351.2024566227150272768.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-10: "reference" substatement for "revision" statements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 10:08:04 -0000 On Fri, May 06, 2011 at 12:03:51PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > RFC 6087 requires that every revision statement MUST has a reference > > statement. While this requirement makes sense for newly written > > modules, it does not make sense for modules derived from SMIv2 > > modules where this information is usually provided in the > > description clause. > > 6087 says: > > This document defines a set of usage guidelines for Standards Track > documents containing YANG [RFC6020] data models. > > and: > > A revision statement MUST be present for each published version of > the module. The revision statement MUST have a reference > substatement. It MUST identify the published document that contains > the module. > > So the only question is what should be done if a YANG module generated > from a MIB module gets published - should we manually modify the > revision statement or not. Lets postpone this discussion - and I believe a SHOULD in RFC 6087 would have been good enough. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Fri May 6 04:38:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7678E0729 for ; Fri, 6 May 2011 04:38:34 -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=[AWL=-0.000, 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 Q3soQHcmFMlc for ; Fri, 6 May 2011 04:38:21 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 96F1FE064B for ; Fri, 6 May 2011 04:38:20 -0700 (PDT) Received: from dhcp-74-021.eduroam.muni.cz (dhcp-74-021.eduroam.muni.cz [147.251.74.21]) by office2.cesnet.cz (Postfix) with ESMTPSA id F0F5B2CDE058; Fri, 6 May 2011 13:38:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-3--42816453; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <201105051937.p45Jb8Pq007750@idle.juniper.net> Date: Fri, 6 May 2011 13:38:17 +0200 Message-Id: <9E099F7F-CDAD-4AEF-A2E9-20D63E6BA29F@cesnet.cz> References: <201105051937.p45Jb8Pq007750@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1084) Cc: netmod@ietf.org Subject: Re: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 11:38:35 -0000 --Apple-Mail-3--42816453 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 5, 2011, at 9:37 PM, Phil Shafer wrote: >> Title : A YANG Data Model for Routing Configuration >=20 > There are a number of modern routing features that we should ensure > are incorporated. I've not read the draft, but a quick skim found > no mention of logical routers, chained next-hops, etc. I'm not The routing process is intended to represent a virtual router. I am not = sure what "chained next-hop" exactly means but probably it requires a = list of next hops instead of one? If it is not practical to achieve it = via augmenting, we can change the model. > sure if these are add-ons that will be layered on top of the model > in later modules, but the picture with one FIB at the top makes me It's one FIB per routing process (virtual router). > nervous. Do we have engagement from the routing community to ensure > our model reflects today's needs? Yes, we need to involve the routing community, Dan has already tried but = I haven't seen any response yet. >=20 > Also the use of the word "process" is confusing, since there should > be minimal implementation constraints placed on the system. Even > the word "process" is heavily overloaded, with unix geeks thinking > you mean one thing and IOS users think another. I'd avoid the word. I agree, but so is the word "virtual". >=20 > FWIW, in JUNOS, we call these "routing instances" and they run in > the single JUNOS routing protocol daemon (RPD) (where logical routers > get distinct daemons). However any such internal processes mappings > are not visible to the user. I was thinkink about "routing instances" but as there are also routing = protocol instances, I thought it could be confusing. Lada >=20 > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-3--42816453 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTA2MTEzODE4WjAjBgkqhkiG9w0BCQQxFgQUroRrXD6wNOngBdyXcM+3qwJEX50wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQA37k2UyaOnADvAy/0Y6e6rljH4 JCQZKgnOVYDbNj3tthzR5bCtKnqm5oM0nB8s+bJhzsKf343cKmW1dCXdjdULDaJS8IapJSImp06l +3yhpn1+SiMAiY6YWn+PtfAxUaBhzWGFmyyvIzMRkcn29HJ7s7Vo/YqcwksxarlaXJ4akps17neK wGBUOLHOLcau24em+vAgrrNt5smSqJX+R6MATjSSbADL/tC1ari0gTUsutSH4t/K2FfbHWaa/rdE XqhIah7AFbuOmYVA3r7DrZ6HEOHH+nHQQ3iNeOGWEK63FmJ/xyyvpjB+NrkcF9HIDAh7WiPN2WJz ppSnYwrUCWRmAAAAAAAA --Apple-Mail-3--42816453-- From lhotka@cesnet.cz Fri May 6 04:54:28 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76CE06D0 for ; Fri, 6 May 2011 04:54:28 -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=[AWL=-0.000, 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 6hx5knfL3-F8 for ; Fri, 6 May 2011 04:54:24 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6EE064B for ; Fri, 6 May 2011 04:54:21 -0700 (PDT) Received: from dhcp-74-021.eduroam.muni.cz (dhcp-74-021.eduroam.muni.cz [147.251.74.21]) by office2.cesnet.cz (Postfix) with ESMTPSA id 716272CDE058; Fri, 6 May 2011 13:54:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4--41853860; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4DC31560.3020808@joelhalpern.com> Date: Fri, 6 May 2011 13:54:20 +0200 Message-Id: References: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> <171451E3-C998-48DB-98B2-8717CE96A373@cesnet.cz> <4DC31560.3020808@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1084) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 11:54:28 -0000 --Apple-Mail-4--41853860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 5, 2011, at 11:23 PM, Joel M. Halpern wrote: > Can you please elaborate a bit on the purpose of the model? > Is it to enable configuring static routes? > Is to to enable fetching the current forwarding behavior of the = device? > is it to give access to the common RIB, which consolidates the effect = of different routing protocols? > Is it ostensibly generic enough to serve as a bse, from whcih to = subclass models for RIBs for different routing protocols? I think it's mainly the last one, i.e. to provide a generic framework on = which real data models for routing subsystems can be built (by other = WGs). It's not that much about subclassing but rather about augmenting = the framework. =20 >=20 > Before I try to evaluate the proposed model, I need to know what = purpose it is intended to fulfill. > (We have made the mistake before of building models for the sake of = models. That proves not to be useful.) The purpose is stated in the WG charter. I sort of expect that my = initial concepts will prove to be somewhat naive but we have to start = somewhere. Lada >=20 > Yours, > Joel >=20 > On 5/5/2011 2:12 PM, Ladislav Lhotka wrote: >> Hi, >>=20 >> this is a new version of the core routing data model. It now consists = of two YANG modules, one of them just defines top-level containers and = the other provides a basic framework for IPv4 unicast routing, and could = serve as a model for other address families. Please send your comments = to this mailing list. >>=20 >> Thanks, Lada >>=20 >> Begin forwarded message: >>=20 >>> From: Internet-Drafts@ietf.org >>> Date: May 5, 2011 8:00:01 PM GMT+02:00 >>> To: i-d-announce@ietf.org >>> Cc: netmod@ietf.org >>> Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt >>>=20 >>> A new Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >>>=20 >>> Title : A YANG Data Model for Routing Configuration >>> Author(s) : L. Lhotka >>> Filename : draft-ietf-netmod-routing-cfg-00.txt >>> Pages : 44 >>> Date : 2011-04-27 >>>=20 >>> This document contains a specification of two YANG modules that >>> together provide a data model for essential configuration of a >>> routing subsystem. It is expected that this module will serve as = a >>> basis for further development of data models for individual = routing >>> protocols and other related functions. The present data model >>> defines the building blocks for such configurations - routing >>> processes, routes and routing tables, routing protocol instances = and >>> route filters. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>>=20 >>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-4--41853860 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTA2MTE1NDIwWjAjBgkqhkiG9w0BCQQxFgQUjJ+eT8EhTMcswLKGbSf08lRSWGMwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCCcEqcRx68tjZuDMomqULGD6YU 9sWBu3Lh2UZTk37a1DXrj8k8MVlOscrwxrF7h2bFB23HqbLm/Oi91lMPjiahUlpBsUQ97uAKoy8Y Ag33zBRXyDlYaCTfCbbi/LwVCmAcg2BmmCoK4/ISBo9VNYmfh3EdNnotgfRBARhDOm1UEMP3qUiX diufo1k5sDmXfMqRJtSCP37/mLiUOQBiZMClrY0PohI8M44wwTQivlh8oSBIeWhVRgedzF617vzx 5MV/FHo9Ql3CyWR8XVc9fd5ouO/vfE8Koz1J4danhirHI84z8l7uEOL+p+wPez9hgsNer2MdPuaD dh0WdtmGEWUUAAAAAAAA --Apple-Mail-4--41853860-- From spakes@snmp.com Fri May 6 07:18:22 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97C5E0758 for ; Fri, 6 May 2011 07:18:22 -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 r+NHSfAXQR3C for ; Fri, 6 May 2011 07:18:21 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3551EE0756 for ; Fri, 6 May 2011 07:18:20 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA27621; Fri, 6 May 2011 10:18:17 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA10984; Fri, 6 May 2011 10:18:09 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 6 May 2011 10:18:08 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110506061938.GB14287@elstar.local> Message-ID: References: <20110505084543.GB10488@elstar.local> <20110506061938.GB14287@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:18:22 -0000 On Fri, 6 May 2011, Juergen Schoenwaelder wrote: > We dropped this idea because there is no reliable way to obtain names > for the containers: You can have multiple descriptors for a given OID > so its not clear which one to choose. So do I understand correctly that you're talking about taking a MIB document with branching; e.g., +-------- statsTableA | +-- statsGroupA --+ | | +-- stats --+ +-------- statsTableB | | -----+ +-- statsGroupB ----------- statsTableC | | +-- configGroupA -- configTableA | | +-- configuration --+ | | | +-- configGroupB -- configTableB | +-- conformanceStatements ... and collapsing it down to a single layer; e.g., +-- statsTableA | +-- statsTableB | -----+-- statsTableC | +-- configTableA | +-- configTableB because, for example, between two revisions of the above MIB, the object descriptor "statsGroupA" might change to "oldStatsGroupA"? > Furthermore, > the order of OID value assignments can change when modules are revised My recollection is that at one time, there was a requirement in YANG that objects had to be in the same order between revisions. But I think this is no longer true. If my recollection is correct, why would this present a problem for smi2yang? > and the number of descriptors per OID can also change when MIB modules > are revised. Would this problem not disappear if we simply allow duplications of value for the smiv2:oid statement? Example: smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "statsGroupA"; } smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "oldStatsGroupA"; } Regards, -dss > So for these robustness reasons, we better only rely on descriptors > introduced by macro invocations. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From jmh@joelhalpern.com Fri May 6 07:35:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB080E0752 for ; Fri, 6 May 2011 07:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 JThIO7GVvfQT for ; Fri, 6 May 2011 07:35:05 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id E4D82E075A for ; Fri, 6 May 2011 07:35:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id CFF9332453D5; Fri, 6 May 2011 07:35:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B3AEA3228034; Fri, 6 May 2011 07:35:05 -0700 (PDT) Message-ID: <4DC40717.5030409@joelhalpern.com> Date: Fri, 06 May 2011 10:35:03 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ladislav Lhotka References: <20110505180001.31385.28083.idtracker@ietfa.amsl.com> <171451E3-C998-48DB-98B2-8717CE96A373@cesnet.cz> <4DC31560.3020808@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:35:06 -0000 The largest problem I see is the confusion between RIB and routing process. For example, BGP is normally run as a single routing process, exchanging multiple protocols with multiple neighbors. It conceptually maintains a separate RIB-IN for the information it receives from each neighbor, a consolidate RIB for what it has concluded, and a RIB-Out for each neighbor for what it will send to each neighbor. An additional item that confused me is that the routing process seems to have a mandatory operation for deleting routes. From a system perspective, you can create, delete, and modify static routes. On some systems there are ways to prevent the system as a whole from learning a route from some routing protocol. But you may not reach in and delete the routes that a given routing protocol is learning / using. That would break the routing protocol. There is an additional reason that most modeling efforts have tried to model only the central rib where the system decides what to make of all the information it gathers. That can be meaningfully represented independently of the routing protocol. In contrast, for example, OSPF does not represent a RIB. Rather, it represents the link state information. And if you try to represent each RIB, then you are inviting the problem of how to represent the interaction between the RIBs. If you actually know a common abstraction across the vendors for how we look at that, it would be very powerful. Yours, Joel On 5/6/2011 7:54 AM, Ladislav Lhotka wrote: > > On May 5, 2011, at 11:23 PM, Joel M. Halpern wrote: > >> Can you please elaborate a bit on the purpose of the model? >> Is it to enable configuring static routes? >> Is to to enable fetching the current forwarding behavior of the device? >> is it to give access to the common RIB, which consolidates the effect of different routing protocols? >> Is it ostensibly generic enough to serve as a bse, from whcih to subclass models for RIBs for different routing protocols? > > I think it's mainly the last one, i.e. to provide a generic framework on which real data models for routing subsystems can be built (by other WGs). It's not that much about subclassing but rather about augmenting the framework. > >> >> Before I try to evaluate the proposed model, I need to know what purpose it is intended to fulfill. >> (We have made the mistake before of building models for the sake of models. That proves not to be useful.) > > The purpose is stated in the WG charter. I sort of expect that my initial concepts will prove to be somewhat naive but we have to start somewhere. > > Lada > >> >> Yours, >> Joel >> >> On 5/5/2011 2:12 PM, Ladislav Lhotka wrote: >>> Hi, >>> >>> this is a new version of the core routing data model. It now consists of two YANG modules, one of them just defines top-level containers and the other provides a basic framework for IPv4 unicast routing, and could serve as a model for other address families. Please send your comments to this mailing list. >>> >>> Thanks, Lada >>> >>> Begin forwarded message: >>> >>>> From: Internet-Drafts@ietf.org >>>> Date: May 5, 2011 8:00:01 PM GMT+02:00 >>>> To: i-d-announce@ietf.org >>>> Cc: netmod@ietf.org >>>> Subject: [netmod] I-D ACTION:draft-ietf-netmod-routing-cfg-00.txt >>>> >>>> A new Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. >>>> >>>> Title : A YANG Data Model for Routing Configuration >>>> Author(s) : L. Lhotka >>>> Filename : draft-ietf-netmod-routing-cfg-00.txt >>>> Pages : 44 >>>> Date : 2011-04-27 >>>> >>>> This document contains a specification of two YANG modules that >>>> together provide a data model for essential configuration of a >>>> routing subsystem. It is expected that this module will serve as a >>>> basis for further development of data models for individual routing >>>> protocols and other related functions. The present data model >>>> defines the building blocks for such configurations - routing >>>> processes, routes and routing tables, routing protocol instances and >>>> route filters. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-netmod-routing-cfg-00.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> -- >>>> Ladislav Lhotka, CESNET >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > From j.schoenwaelder@jacobs-university.de Fri May 6 07:57:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BDFE06C0 for ; Fri, 6 May 2011 07:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.183 X-Spam-Level: X-Spam-Status: No, score=-103.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 YB08dREK06tw for ; Fri, 6 May 2011 07:57:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 78663E0691 for ; Fri, 6 May 2011 07:57:29 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ABFA20C2A; Fri, 6 May 2011 16:57:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KTgQZTZWLRC1; Fri, 6 May 2011 16:57:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68E0B20C1E; Fri, 6 May 2011 16:57:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CA69186D000; Fri, 6 May 2011 16:57:22 +0200 (CEST) Date: Fri, 6 May 2011 16:57:22 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110506145722.GA21855@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20110505084543.GB10488@elstar.local> <20110506061938.GB14287@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:57:31 -0000 On Fri, May 06, 2011 at 10:18:08AM -0400, David Spakes wrote: > On Fri, 6 May 2011, Juergen Schoenwaelder wrote: > > > We dropped this idea because there is no reliable way to obtain names > > for the containers: You can have multiple descriptors for a given OID > > so its not clear which one to choose. > > > So do I understand correctly that you're talking about taking a MIB > document with branching; e.g., > > +-------- statsTableA > | > +-- statsGroupA --+ > | | > +-- stats --+ +-------- statsTableB > | | > -----+ +-- statsGroupB ----------- statsTableC > | > | +-- configGroupA -- configTableA > | | > +-- configuration --+ > | | > | +-- configGroupB -- configTableB > | > +-- conformanceStatements ... > > > and collapsing it down to a single layer; e.g., > > > +-- statsTableA > | > +-- statsTableB > | > -----+-- statsTableC > | > +-- configTableA > | > +-- configTableB > > > because, for example, between two revisions of the above MIB, the > object descriptor "statsGroupA" might change to "oldStatsGroupA"? You understand the collapsing correctly. The reason is that descriptors can change and you have have multiple descriptors for the same OID, hence it is ambiguous which one to choose. > > Furthermore, > > the order of OID value assignments can change when modules are revised > > My recollection is that at one time, there was a requirement in YANG > that objects had to be in the same order between revisions. But I think > this is no longer true. > > If my recollection is correct, why would this present a problem for > smi2yang? Since OID descriptors may be ambiguous, finding a resolution by picking the first of the last also does not work. Also note that YANG augmentations MUST be top-level statements, hence capturing the nesting of augmenting tables would not work anyway. > > and the number of descriptors per OID can also change when MIB modules > > are revised. > > Would this problem not disappear if we simply allow duplications of > value for the smiv2:oid statement? Example: > > smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "statsGroupA"; } > smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "oldStatsGroupA"; } Right now, the smiv2:oid statements are inline with the translated SMIv2 macros. This means and this means not all OID descriptors are captured. If the proposal is accepted to change the smiv2:oid statement, I would prefer smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:alias "statsGroupA"; smiv2:alias "oldStatsGroupA"; } and perhaps we could even distinguish hard names (assigned via macro invocations) from weak descriptors (assigned via OID value assignments) like this: smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { smiv2:name "fooTable"; smiv2:alias "bar"; } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Fri May 20 05:23:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE9E077D; Fri, 20 May 2011 05:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5L77IaADdNDi; Fri, 20 May 2011 05:23:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B32FE065D; Fri, 20 May 2011 05:23:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110520122307.24945.87639.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2011 05:23:07 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 12:23:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for Interface Configuration Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-01.txt Pages : 23 Date : 2011-05-20 This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-interfaces-cfg-01.txt From mbj@tail-f.com Fri May 20 05:36:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974C1E077D for ; Fri, 20 May 2011 05:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 pZFi6ripHT9S for ; Fri, 20 May 2011 05:36:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id ABCC1E06FE for ; Fri, 20 May 2011 05:36:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B367976C4A8 for ; Fri, 20 May 2011 14:36:04 +0200 (CEST) Date: Fri, 20 May 2011 14:36:03 +0200 (CEST) Message-Id: <20110520.143603.1699845414046565032.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] Interface and IP config models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 12:36:07 -0000 Hi, I have submitted http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-01 which resolves the (few) open issues I had. In particular, I have also submitted http://tools.ietf.org/html/draft-bjorklund-netmod-ip-cfg-00 which extends the interface model with ip address configuration objects. Please review draft-ietf-netmod-interfaces-cfg-01. With the current scope of this module, I feel that I am done with the document. /martin From j.schoenwaelder@jacobs-university.de Fri May 20 16:11:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4FFE073A for ; Fri, 20 May 2011 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 PYBCNck-Q-DI for ; Fri, 20 May 2011 16:11:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 84FEAE06EB for ; Fri, 20 May 2011 16:11:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C05F720BF7 for ; Sat, 21 May 2011 01:11:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g7SIUacNjGlf; Sat, 21 May 2011 01:11:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B39F20BEB; Sat, 21 May 2011 01:11:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C38FC18B2A18; Sat, 21 May 2011 01:11:03 +0200 (CEST) Date: Sat, 21 May 2011 01:11:03 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110520231103.GA1710@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20110405100141.GD68335@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110405100141.GD68335@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] smi2yang-04: string vs. binary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 23:11:15 -0000 On Tue, Apr 05, 2011 at 12:01:41PM +0200, Juergen Schoenwaelder wrote: > * smi2yang-04: string vs. binary > > It would be nice to have a reliable mechanism to determine whether > an OCTET STRING can be represented as a human readable string or is > a binary string. The current ID suggests to use the presence of a > DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a > DISPLAY-HINT when a MIB module is revised, which can lead to > different translations of different versions of a MIB module. > > ** Solution #04-01 > > Declare this a non-problem since additions of DISPLAY-HINTs are > rare. > > ** Solution #04-02 > > Translate strings into unions that allows both a human readable > string representation and a binary representation. However, this > requires to have some mechanism in place to decide whether a value > is a human readable string or a binary string, which means we > likely have to mess around with values. > > ** Solution #04-03 > > Always translate OCTET STRING types into the YANG binary types. We > could list some well-known types as exceptions, like DisplayString, > SnmpAdminString, DateAndTime but such a list will always be > incomplete and hence some human readable data will be encoded into > base64. ** Solution #04-04 Always translate OCTET STRINGS into a choice which contains a binary leaf. Add a second string leaf if there is a DISPLAY-HINT. This would also apply to objects using an OCTET STRING TC, that is in the extreme case (no special rules for well known string types), we get for sysDescr: choice sysDescr-leaf { leaf sysDescr-string { type string; } leaf sysDescr-binary { type binary; } } While this solution is robust wrt. module revisions that add a DISPLAY-HINT, the cost of having to support two formats are significant. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@cesnet.cz Mon May 23 09:21:26 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3ECE0776 for ; Mon, 23 May 2011 09:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] 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 rwuoiI5FKdGf for ; Mon, 23 May 2011 09:21:17 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by ietfa.amsl.com (Postfix) with ESMTP id DFF79E0679 for ; Mon, 23 May 2011 09:21:16 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 0C5D22CDE057; Mon, 23 May 2011 18:20:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-6--704553127; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: Date: Mon, 23 May 2011 18:20:44 +0200 Message-Id: <505D29B6-E30C-4DFA-9B9F-28E04BEB035E@cesnet.cz> References: To: Eric Gray X-Mailer: Apple Mail (2.1084) Cc: Adrian.Farrel@huawei.com, danli@huawei.com, "BRUNGARD, DEBORAH A \(ATTLABS\)" , netmod@ietf.org, ext Stewart Bryant Subject: Re: [netmod] RTG DIR Review of http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:21:26 -0000 --Apple-Mail-6--704553127 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Eric, thanks for your thorough review, my replies and comments are inline. On May 20, 2011, at 8:26 PM, Eric Gray wrote: > Authors, > =20 > There's probably boiler-plate for this review, somewhere. Assume I = found it, put > it here and you read it. > =20 > In general: it looks to me as if the intention with this draft may be = to provide a > data model that is good enough for static route configuration, but = with enough > flexibility to support more complex management of dynamic routing and = routing > protocols. Yes, that was the intention. > =20 > I get the sense that this is the case because - while the parameters = defined in this > draft at present seem adequate to support configuration of static = routes, there are > a lot of holes that would need to be filled to support anything more = complicated. Right. It would also be possible to put static routing in a separate = module, but I thought static routing was so ubiquitous that every = implementation would need it. > =20 > You include an example for RIP in an appendix, probably intended to be = illustrative > rather than definitive. Is that correct? Yes, and this is clearly stated in the first paragraph of Appendix A. > =20 > If this is the case, this should be made clearer in the abstract. = This would also > help in understanding the objectives. As it is just an example, it is IMO not worth mentioning in the = abstract. In fact, as soon as there is a real module for any routing = protocol, this appendix could be removed. > =20 > Also, in general, I found this draft to be very well written. > =20 > Section 2 (Terminology and Notation): > =20 > I am not certain that I would call what RFC 4741 does with respect to = the terms > "client" and "server" (at least) as "defining" them. It uses these = terms extensively, > and the introduction provides a brief description of both. The = situation is worse for > the terms "message" and "operation" - because these are generic terms = that are > not even described generically (messages are defined, as are = operations, but not > the generic terms, and certainly not the terms "message" and = "operation"). In this case I just followed the suit of other documents of the NETMOD = WG, such as RFC 6087. > =20 > I suspect that what the author(s) mean is that these terms are meant = to be used > as they are used in RFC 4741. That's right, but a reader should certainly have no doubts about their = meaning.=20 > =20 > There appears to be a mix for terms listed as "defined" in RFC 6020. = Most terms > are actually defined in RFC 6020 ("augment", "configuration data", = "data model", > "data node", "data type", etc.) while others are not ("identity", = "mandatory node", > etc.). In many cases, the terms are either described in detail (e.g. = "mandatory > node"), or there is an implicit definition ("identifier" is defined, = but "identity" is not). I guess it depends on what you call a definition. My original background = is math, so I do see your point, but I have no problem accepting Sec. = 3.1 in RFC 6020 as the definition of the term "mandatory node". > Also, in at least one case, the usage is clear but I cannot determine = that there is > a "definition" per se (e.g. - "prefix"). > =20 > When stating that the terms are "defined" in another document, the = author needs > to consider who may be a reader. Either the reader will be familar = with the terms > as used in these other documents (and will not have to look them up), = or they will > expect to find actual explicit definitions in these other documents. > =20 > Since the documents referred to are published, it would not hurt to = explicitly repeat > the definitions in this draft. It's possible, but the same would be needed to be done in other = documents as well. I would prefer to have concise and authoritative = definitions in one place. > =20 > Section 3 (Objectives) > =20 > It is not clear what usefulness there is in the expression "On the = other hand" (third > bullet, first paragraph). Also, with this bullet, it is very unclear = what objective is It means that simple things should be done in a simple way but complex = things should also be possible. =20 > meant to be addressed by "complicated setups invoving multiple routing = tables and > multiple routing protocols" - this makes me nervous, because this is = sufficiently > inclusive that it could very likely be meant to include = implementation-specific stuff. > I suspect that what it is meant to describe is simpler - for example - = describing a > set of rules for resolving conflicting route information. At the end of the day, implementors will be encouraged to publish even = their proprietary knobs, bells and whistles as YANG modules. This should = not make you or anybody nervous because the proprietary stuff cannot be = avoided, and it is IMO better if it is published. =20 > =20 > The fourth bullet is written in a relatively loose way, starting with = a justification and > then listing the objective. I suggest a clean listing of objectives = should be separate > from justifications for any of them. OK, I agree. > =20 > Section 3 and 4 (Design of the Core Routing Data Model) both use the = term "setup" > in a way that does not seem clear to me. Is this term meant to be = synonymous > with "configuration"? Is there a reason to use "setup" instead of = what it means, or > should we include a definition for what is meant by "setup"? The term "configuration" has a more specific meaning in NETCONF/NETMOD = circles, the word "setup" is intended to mean "organization of a routing = subsystem". =20 > =20 > (By the way, there is no information content in a leading "The" in a = section title.) Which section title do you mean, I don't see any leading "The" in the = titles of Sec. 3 or 4. (Nevertheless, I am ready to admit that my use of = English articles is far from perfect because my native language - Czech = - has no such beast.) =20 > =20 > The example in Figure 1 is probably not typical. For example, = implementers will > not usually have the concept of a "main routing table" and "additional = routing table" > (or "tables") but will have tables comprising input to a function = meant to resolve > discrepancies and combine inputs (thus resulting in a combined routing = table). It > seems likely that this is an isomorphism of what you show, but it also = seems (to > me) like this example may engender more confusion that it helps to = eliminate.=20 > In many implementations I've seen, static routes (for example) are = just another set > of inputs (typically with the highest resolution priority, or = preemptive rules). In the routing configuration languages I have used in the past, this = seems a plausible setup, though by no means the only one. The present = design also has to do with the distinction between configuration and = operational state data - routing tables belong to the latter category. > =20 > Minimally, I would change "the routing subsystem" to "a routing = subsystem" in > the figure caption. OK. > =20 > Section 4.3 (Routing Protocol Instances): > =20 > The model in this section implied by the text in the second paragraph = seems to be > implementation specific. In at least a few implementations this is = inconsistent with > how the implementations actually work. For example, implementations = may have > a single routing (or route) table with the input to a filtering = function from each of a > number of different routing protocols. Storage of routing protocol = information may > or may not be in some form that can be logically represented as a = separate table, > and will very likely include a considerable amount of = protocol-relevant additional > information. I believe all this is still possible. For example, all routing protocols = may be connected to the same routing table. Do you have a particular = implementation in mind which cannot be represented using the framework = of the draft? Note that routing protocols may store other information = apart from routing tables, both as configuration and operational state = data.=20 > =20 > Also, the filtering described in the bullets of the fourth paragraph = implies what may > be a messy mechanism for determining which of several routing inputs = is used in > constructing a set of route table entries. If you were - for example = - required to > describe route-input by route-input which one would be accepted or = rejected, this > information might be harder to maintain than the separate route = tables. Also, I > strongly suspect that the filters would need to be defined pair-wise = for all pairs of > routing protocols in use (i.e. if RP1, RP2, RP3 and RP4 are in use, = there would > need to be a set of filters for each pair {RP1:RP2}, {RP1:RP3}, = {RP1:RP4}, etc.) > and this too could get messy. This very much depends on the number of routing tables in use. = Essentially, any structure of interconnected routing tables with = filtering functions attached to any connection should be possible. = Various implementations differ in their configuration logic, so it is = quite likely that some will be a better fit for the generic framework = than others. =20 > =20 > Section 7 (IANA Considerations): > =20 > Are the two namespace URIs already allocated (using the early = allocation process), > or are we simply assuming these values will be allocated? > =20 > Same question for YANG modules. My understanding is that these allocations are performed quite late in = the document life cycle, just before it is published as an RFC. =20 > =20 > Section 8 (Security Considerations): > =20 > I suspect that there is text you can import for this section from = other extensions to > YANG. The idea should be that configuration operations usually need = to be verified > and authenticated. Yes, that would be useful, but no such text exists, AFAIK. > =20 > I didn't review the Appendix, or much of the actual modules elsewhere = in the draft. > I assume there is some tool to verify that the text has the right = number of opens > and closes and is other wise syntactically correct and that these = tools will be used > prior to publication of this draft. Yes, the modules and XML instance documents were validated with pyang = tools. Thanks again, Lada > =20 > Thanks! > -- > Eric Gray > =20 > PS: if the boiler-plate is supposed to include some closing remarks, = pretend I > put that here, and you read it... -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-6--704553127 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTIzMTYyMDQ1WjAjBgkqhkiG9w0BCQQxFgQUrNQPtSElkYK4J/Kcwxfltyfv8M8wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCHTpGh0fHIT+Qn3ZAqrecEnfTx cijyXbQBW3VplgK/D27apEFUno9X7/E0KhxfhNWv2LY6e32rGG5uXHWhlQ3gIiaoTZvoBw5wcISc LkSgiZiO3fyIKYq4OOCj7jOOtR0Wf4nthbZZxspqJb7Mkp6BMSlHxOaVVm4LFJBYJjdlZa5QE9Xc ltFisC8i6VyWKWae/zOUnYIMn2yf1e75hMQXaem8+kQDVP/aj9BN2GrQiiCXL2LW1+L3VBteB/6P 7eMtYgmo14Z+hOVIxAVw3Wv47SMBsB6skIw70VAXh0ID/MvDdMzOPclAJ/aprEM5ScNXavYlj5Hb f4krr8Q/F0XzAAAAAAAA --Apple-Mail-6--704553127-- From mbj@tail-f.com Tue May 24 00:52:01 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1AE06D4 for ; Tue, 24 May 2011 00:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 NGP69Xlh5phH for ; Tue, 24 May 2011 00:52:01 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 16B6BE06CE for ; Tue, 24 May 2011 00:52:00 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 03629616002 for ; Tue, 24 May 2011 09:51:58 +0200 (CEST) Date: Tue, 24 May 2011 09:51:58 +0200 (CEST) Message-Id: <20110524.095158.1438741224791011432.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] draft-ietf-netconf-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 07:52:01 -0000 Hi, I have some general questions regarding this document. In the previous version, there was one single module, but in this version, it is split into two, one generic, and one ipv4-unicast specific module. This seems fine, from a high level pow. But in the current document, some of the generic concepts, like route filtering, routing tables, are defined in the ipv4-unicast module. The only concept defined in the generic routing module is routing process. What is the reasoning behind this? It means that when we define e.g. a ipv6-unicast module, we either need to reinvent route filters and routing tables, or might come up with completely new concepts. Woudln't it be better to move all the generic concepts back into the main routing module? /martin From lhotka@cesnet.cz Tue May 24 01:28:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D368AE06F6 for ; Tue, 24 May 2011 01:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 ACWQtw6Pi5QB for ; Tue, 24 May 2011 01:28:29 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id B03C1E06E9 for ; Tue, 24 May 2011 01:28:28 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 6EFB12CDE058; Tue, 24 May 2011 10:28:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2--646492116; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20110524.095158.1438741224791011432.mbj@tail-f.com> Date: Tue, 24 May 2011 10:28:25 +0200 Message-Id: <4594F2C1-C752-473F-9ACE-95F45E2706B4@cesnet.cz> References: <20110524.095158.1438741224791011432.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1084) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netconf-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:28:29 -0000 --Apple-Mail-2--646492116 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 24, 2011, at 9:51 AM, Martin Bjorklund wrote: > Hi, >=20 > I have some general questions regarding this document. In the > previous version, there was one single module, but in this version, it > is split into two, one generic, and one ipv4-unicast specific module. > This seems fine, from a high level pow. >=20 > But in the current document, some of the generic concepts, like route > filtering, routing tables, are defined in the ipv4-unicast module. > The only concept defined in the generic routing module is routing > process. What is the reasoning behind this? It means that when we I did it in order to be able to support other address families, = especially in multiprotocol BGP. Even if nobody was interested in = AppleTalk or IPX anymore, things like IP-MPLS or multicast will be = needed, I think. > define e.g. a ipv6-unicast module, we either need to reinvent route > filters and routing tables, or might come up with completely new > concepts. Yes, that's the deal. >=20 > Woudln't it be better to move all the generic concepts back into the > main routing module? The concepts could perhaps be made generic, to some extent, only for = pure unicast IP but not for other address families. So we could have a = generic model for IP but I don't think it we could go very far with it. = One problem is that union types such as ip-address don't tell whether = their contents is IPv4 or IPv6. Lada =20 >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-2--646492116 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTI0MDgyODI2WjAjBgkqhkiG9w0BCQQxFgQULJB7l3EsCAcOgYX7mxeV2BlVYTcwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCPeg03xwD+nQ5Pb9Gew57XT/dV BE840nP/1UhfUuc6bWVbl/OMM0UJkV0rEDPvMLUnkfKqYmmu/DfU8s2QDs4NZG78KWFWW3tSVvKa R22YfIxddxoUoVgYcCxGgsSpqftDwmMONzqsmrbgAj2H9P1f/gU8/gAqEHOc79zEf17PQM8lcgdY OSULSOsUosLz+fxvqInmyr4yNB9wBHPZXQT5UdvSbok+rocyjQjzgTq9nopAI7SA1osKb18n7Xsu LmGQSR+nXBDy1PcJH6jTlRapUdGPwAc46vu4jNNso0/uXqaS9MKUS8ViTwsDwYKAAyKwCHFBaHnv uBnPXZ3H9dmDAAAAAAAA --Apple-Mail-2--646492116-- From mbj@tail-f.com Tue May 24 01:46:56 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF643E0675 for ; Tue, 24 May 2011 01:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 b9J-BBesmvcW for ; Tue, 24 May 2011 01:46:56 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 54F41E070C for ; Tue, 24 May 2011 01:46:52 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 820B8616002; Tue, 24 May 2011 10:46:51 +0200 (CEST) Date: Tue, 24 May 2011 10:46:50 +0200 (CEST) Message-Id: <20110524.104650.1078102800466131450.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <4594F2C1-C752-473F-9ACE-95F45E2706B4@cesnet.cz> References: <20110524.095158.1438741224791011432.mbj@tail-f.com> <4594F2C1-C752-473F-9ACE-95F45E2706B4@cesnet.cz> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netconf-routing-cfg-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 08:46:56 -0000 Ladislav Lhotka wrote: > > On May 24, 2011, at 9:51 AM, Martin Bjorklund wrote: > > > Hi, > > > > I have some general questions regarding this document. In the > > previous version, there was one single module, but in this version, it > > is split into two, one generic, and one ipv4-unicast specific module. > > This seems fine, from a high level pow. > > > > But in the current document, some of the generic concepts, like route > > filtering, routing tables, are defined in the ipv4-unicast module. > > The only concept defined in the generic routing module is routing > > process. What is the reasoning behind this? It means that when we > > I did it in order to be able to support other address families, especially in > multiprotocol BGP. Even if nobody was interested in AppleTalk or IPX anymore, > things like IP-MPLS or multicast will be needed, I think. It seems to me that 'routing-protocol-instance', 'route-filters', and 'routing-tables' all could be generic. The ipv4-unicast module would augment 'routing-protocol-instance' with its static routes, and augment 'routing-table' with the ipv4-specific routes. Maybe we can discuss this approach off-list... /martin From jmh@joelhalpern.com Tue May 24 07:32:20 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94EE075B for ; Tue, 24 May 2011 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3BUIr6xP6gez for ; Tue, 24 May 2011 07:32:19 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF4EEE06AF for ; Tue, 24 May 2011 07:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 711DE4300FA for ; Tue, 24 May 2011 07:32:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 36FF44300EA for ; Tue, 24 May 2011 07:32:19 -0700 (PDT) Message-ID: <4DDBC170.6060309@joelhalpern.com> Date: Tue, 24 May 2011 10:32:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 14:32:20 -0000 I sent a question about this several weeks ago. I apologize if there was a clear answer which I missed. The document seems to have a major problem of mixing the notions of RIB and routing process. The reality is quite different from the document in several regards. Conceptually, RIB and Routing Process are orthogonal concepts. A routing process may maintain several RIBs. it may manitain only one. It also may pull information from RIBs beyond the one or ones it maintains. It may work with one address family, or several. It may handle only unicast, only multicast, or both. And, conversely, some routing protocols do not operate in terms of maintaining a RIB (although they still have to interact with one or more RIBs at the edge. I get further confused by the placement of operations like one for deleting routes in the routing protocols. If a routing protocol learns a route, you generally MUST NOT delete it. Depending upon the routing protocol, you may or may not have knobs to control whether it is used. (And there may be separate knobs affecting the way the system uses the RIB output from the routing protocol, but that is a different matter.) Normally, modeling has concentrated on the central RIB, with its policy and data. Routing protocol configuration has focussed on the individual knobs for the routing protocols. And instances are handled on a case by case basis. Better commonality is good. Mixing the concepts of RIB and Routing protocol instance is at best VERY confusing, and possibly worse. Yours, Joel M. Halpern From lhotka@cesnet.cz Tue May 24 09:27:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66AEE067F for ; Tue, 24 May 2011 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 lB9VA5CC4GId for ; Tue, 24 May 2011 09:27:42 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id B4C1CE0671 for ; Tue, 24 May 2011 09:27:38 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4D7012CDE057; Tue, 24 May 2011 18:27:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-8--617742009; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4DDBC170.6060309@joelhalpern.com> Date: Tue, 24 May 2011 18:27:35 +0200 Message-Id: <03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> References: <4DDBC170.6060309@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1084) Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 16:27:43 -0000 --Apple-Mail-8--617742009 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Joel, I have to apologize, you didn't miss anything. Your comments are quite = far-reaching, so I had no quick answer and then had to work on other = things. On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: > I sent a question about this several weeks ago. I apologize if there = was a clear answer which I missed. >=20 > The document seems to have a major problem of mixing the notions of = RIB and routing process. The reality is quite different from the = document in several regards. Conceptually, RIB and Routing Process are = orthogonal concepts. A routing process may maintain several RIBs. it = may manitain only one. It also may pull information from There may be a terminological confusion, as Phil already pointed out. A = routing process is essentially a "virtual router", so, by definition, = its routing information is not shared with other virtual routers. I = think that what you call "routing process" is a = "routing-protocol-instance" in my terminology. On the other hand, each routing-process (=3D virtual router) is limited = to a single address family (AFI+SAFI), in order to make the data model = extensible and manageable. =46rom a practical point of view, is it a = serious limitation? > RIBs beyond the one or ones it maintains. It may work with one = address family, or several. It may handle only unicast, only multicast, = or both. > And, conversely, some routing protocols do not operate in terms of = maintaining a RIB (although they still have to interact with one or more = RIBs at the edge. >=20 > I get further confused by the placement of operations like one for = deleting routes in the routing protocols. If a routing protocol learns = a route, you generally MUST NOT delete it. Depending upon the routing = protocol, you may or may not have knobs to I think this "MUST NOT" only applies to link-state protocols, otherwise = routes learned by other routing protocols can be filtered before they = are imported to a routing table. In any case, the "delete-route" operation can be removed and other = operations/knobs added, this area is open to further discussion. I just = wanted to include at least one rpc statement in the module to make = people that are not very familiar with YANG aware of the possibility to = define new operations. > control whether it is used. > (And there may be separate knobs affecting the way the system uses the = RIB output from the routing protocol, but that is a different matter.) >=20 > Normally, modeling has concentrated on the central RIB, with its = policy and data. Routing protocol configuration has focussed on the = individual knobs for the routing protocols. And instances are handled = on a case by case basis. > Better commonality is good. > Mixing the concepts of RIB and Routing protocol instance is at best = VERY confusing, and possibly worse. Could you sketch how the data model should be organized? I am not sure = that the concept of a central RIB fits existing implementations with = policy routing, where sets of routes can be filtered, manipulated and = redistributed between routing protocols in many different ways. Thanks, Lada >=20 > Yours, > Joel M. Halpern > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-8--617742009 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTI0MTYyNzM2WjAjBgkqhkiG9w0BCQQxFgQUnop1Uu7tEnp5LuVTgxzTuGmVeX4wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCjQ3kXs7+Nf7MZ2Pb2hOtlxV1n P1rNcspBkZ1X5tGD15IPJI6wzFY6e0ihNOQk7MRj30p6h2GKSGGTxHsPFVGCiyfG+O+00/+GlWLJ krZwR1CLvJdhfqQC92huMYJo4SK4SweHzSr4rnEH5gprw9bJk6ycCHnBRilv388gFGt1oTFWoFt5 ysjzrrgVFZ07B1N1VrYn1K7+urdh84/Tly/QTcge46sK+sj0tjA45Y6LbEnzYBIBOeQWQhPLaHh3 dLrZzg03Esijj936jYXZ9rY3D5IkzpCkXbuKSJqaBpIyXWqEDsSUAFqb3FlItd0HL5X89N9GTFh3 KN7o6VZhZF+LAAAAAAAA --Apple-Mail-8--617742009-- From reid@snmp.com Tue May 24 14:05:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B976FE078C for ; Tue, 24 May 2011 14:05:17 -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 b-t94ECOwcwe for ; Tue, 24 May 2011 14:05:16 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC47DE0791 for ; Tue, 24 May 2011 14:05:16 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA27163; Tue, 24 May 2011 17:05:14 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA16781; Tue, 24 May 2011 17:05:05 -0400 (EDT) Message-Id: <201105242105.RAA16781@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Sat, 21 May 2011 01:11:03 +0200. <20110520231103.GA1710@elstar.local> Date: Tue, 24 May 2011 17:05:05 -0400 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 21:05:17 -0000 > ** Solution #04-04 > > Always translate OCTET STRINGS into a choice which contains a > binary leaf. Add a second string leaf if there is a DISPLAY-HINT. > This would also apply to objects using an OCTET STRING TC, that is > in the extreme case (no special rules for well known string types), > we get for sysDescr: > > choice sysDescr-leaf { > leaf sysDescr-string { > type string; > } > leaf sysDescr-binary { > type binary; > } > } > > While this solution is robust wrt. module revisions that add a > DISPLAY-HINT, the cost of having to support two formats are > significant. > > /js I like this solution. I need to think more about the implementation cost. But at first look, I think it is a quite clever solution. I have one suggestion: always include both string and binary in the choice whether it has a DISPLAY-HINT or not and let the server decide which one to use. The server knows best what the best encoding should be. And if someone did not want to incur the extra cost, they could use binary in every case. -David Reid From j.schoenwaelder@jacobs-university.de Tue May 24 17:37:08 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168AE07A7 for ; Tue, 24 May 2011 17:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 uWOg7N03L01d for ; Tue, 24 May 2011 17:37:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 79959E06D7 for ; Tue, 24 May 2011 17:37:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5E3820CB2; Wed, 25 May 2011 02:37:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NG8PdA8kF+h5; Wed, 25 May 2011 02:37:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FC0020CB1; Wed, 25 May 2011 02:37:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 215C618B62E3; Wed, 25 May 2011 02:37:05 +0200 (CEST) Date: Wed, 25 May 2011 02:37:05 +0200 From: Juergen Schoenwaelder To: David Reid Message-ID: <20110525003705.GA2231@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20110520231103.GA1710@elstar.local> <201105242105.RAA16781@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105242105.RAA16781@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 00:37:08 -0000 On Tue, May 24, 2011 at 05:05:05PM -0400, David Reid wrote: > > ** Solution #04-04 > > > > Always translate OCTET STRINGS into a choice which contains a > > binary leaf. Add a second string leaf if there is a DISPLAY-HINT. > > This would also apply to objects using an OCTET STRING TC, that is > > in the extreme case (no special rules for well known string types), > > we get for sysDescr: > > > > choice sysDescr-leaf { > > leaf sysDescr-string { > > type string; > > } > > leaf sysDescr-binary { > > type binary; > > } > > } > > > > While this solution is robust wrt. module revisions that add a > > DISPLAY-HINT, the cost of having to support two formats are > > significant. > > > > /js > > I like this solution. I need to think more about the implementation cost. > But at first look, I think it is a quite clever solution. I have one > suggestion: always include both string and binary in the choice whether it > has a DISPLAY-HINT or not and let the server decide which one to use. The > server knows best what the best encoding should be. And if someone did not > want to incur the extra cost, they could use binary in every case. The costs of this solution are on the client side and not on the server side. For every OCTET STRING MIB object, a client now needs to be prepared to handle both a binary (=base64) encoded XML element and a separate string encoded XML element. So yes, for a server, this is kind of attractive. For a client, this is going to be more of a pain (and I fear we will see lots of programs/scripts not handling this correctly). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Tue May 24 17:41:37 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F397E07A9 for ; Tue, 24 May 2011 17:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qgWw79hgJe4i for ; Tue, 24 May 2011 17:41:36 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 95499E07B0 for ; Tue, 24 May 2011 17:41:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 848B24300EA; Tue, 24 May 2011 17:41:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id AB42F4300E5; Tue, 24 May 2011 17:41:35 -0700 (PDT) Message-ID: <4DDC503C.7020406@joelhalpern.com> Date: Tue, 24 May 2011 20:41:32 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ladislav Lhotka References: <4DDBC170.6060309@joelhalpern.com> <03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> In-Reply-To: <03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 00:41:37 -0000 Two comments, brought to the front for clarity. I have retained the whole note for context, although we should probably trim it soon. 1) The difference between virtual router, virtual routing protocol, routing process or routing protocol instance as you intended it is not a big deal. However, you should understand that vendors have used those terms in different ways to represent very different things. 1') More importantly, if you are talking about configuring a routing protocol, you have to get teh granularity right. It is not possible, in BGP, to have different hold times for different address families. The different address families are all using the same TCP exchange over the same ports, managed by the same protocol machinery. So when one tries to configure a routing protocol, if you define that to be a single address family, and to be separate for unicast and multicast, you make it MORE complicated to represent the realities. With regard to the RIBs, what I would recommend is NOT to try to model the per-protocol RIB. Rather, model 1) The central, protocol independent, RIB, ala RIB2 2) The policies and priorities by which things get into the RIB, which can be configured. 3) The individual routing instances. This model should allow for multiple instances of different protocols, but not require it 3a) For each routing protocol instance, the policies by which it extracts information from the common RIB, and the policies by which it adds information to the common RIB 3b) The routing data structure specific to the protocol. For most protocols, these are NOT modifiable. Modification is generally done by policies, not by manipulating the data. For IS-IS and OSPF, we would want to model the link state database. For BGP, we would want to advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP structure needs to include the BGP attributes, like the path, and has to be organized in terms of the NLRI. It has to represent the fact that several NLRI can share the same properties. (This may change in the future, but is currently the case.) I would NOT recommend trying to represent the IS-IS Link State Database using the same parent structure as the BGP RIB. (It is probably not even worth trying to create a common parent for the OSPF and IS-IS LSDB.) And I would not use the same structure for the BGP RIB as for the central RIB. Yours, Joel On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: > Joel, > > I have to apologize, you didn't miss anything. Your comments are quite far-reaching, so I had no quick answer and then had to work on other things. > > On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: > >> I sent a question about this several weeks ago. I apologize if there was a clear answer which I missed. >> >> The document seems to have a major problem of mixing the notions of RIB and routing process. The reality is quite different from the document in several regards. Conceptually, RIB and Routing Process are orthogonal concepts. A routing process may maintain several RIBs. it may manitain only one. It also may pull information from > > There may be a terminological confusion, as Phil already pointed out. A routing process is essentially a "virtual router", so, by definition, its routing information is not shared with other virtual routers. I think that what you call "routing process" is a "routing-protocol-instance" in my terminology. > > On the other hand, each routing-process (= virtual router) is limited to a single address family (AFI+SAFI), in order to make the data model extensible and manageable. From a practical point of view, is it a serious limitation? > >> RIBs beyond the one or ones it maintains. It may work with one address family, or several. It may handle only unicast, only multicast, or both. >> And, conversely, some routing protocols do not operate in terms of maintaining a RIB (although they still have to interact with one or more RIBs at the edge. >> >> I get further confused by the placement of operations like one for deleting routes in the routing protocols. If a routing protocol learns a route, you generally MUST NOT delete it. Depending upon the routing protocol, you may or may not have knobs to > > I think this "MUST NOT" only applies to link-state protocols, otherwise routes learned by other routing protocols can be filtered before they are imported to a routing table. > > In any case, the "delete-route" operation can be removed and other operations/knobs added, this area is open to further discussion. I just wanted to include at least one rpc statement in the module to make people that are not very familiar with YANG aware of the possibility to define new operations. > >> control whether it is used. >> (And there may be separate knobs affecting the way the system uses the RIB output from the routing protocol, but that is a different matter.) >> >> Normally, modeling has concentrated on the central RIB, with its policy and data. Routing protocol configuration has focussed on the individual knobs for the routing protocols. And instances are handled on a case by case basis. >> Better commonality is good. >> Mixing the concepts of RIB and Routing protocol instance is at best VERY confusing, and possibly worse. > > Could you sketch how the data model should be organized? I am not sure that the concept of a central RIB fits existing implementations with policy routing, where sets of routes can be filtered, manipulated and redistributed between routing protocols in many different ways. > > Thanks, Lada > >> >> Yours, >> Joel M. Halpern >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > From ietfc@btconnect.com Thu May 26 10:11:45 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7687C130059 for ; Thu, 26 May 2011 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 4CAZ0sr6qpqa for ; Thu, 26 May 2011 10:11:42 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0C590130057 for ; Thu, 26 May 2011 10:11:36 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr09.btconnect.com with SMTP id DAG63881; Thu, 26 May 2011 18:11:32 +0100 (BST) Message-ID: <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joel M. Halpern" , "Ladislav Lhotka" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> Date: Thu, 26 May 2011 18:09:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4DDE89C2.015A, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.26.155414:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, BODY_SIZE_6000_6999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4DDE89C5.0015,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:11:45 -0000 Joel I think that this discussion is premature and on the wrong list:-( I would like to see a routing list, eg routing area WG, discuss what the model of a router should be, and then have this list turn that into Yang (or whatever). I think that the experience of people like Curtis is needed to come up with something that lasts. RFC1213 has not stood the test of time and I would not expect this to. In passing, I do not share your view of routers and routing terminology, and nor do I share Lada's, but do not know if any of us are right. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: "Ladislav Lhotka" Cc: "NETMOD Working Group" Sent: Wednesday, May 25, 2011 2:41 AM Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > Two comments, brought to the front for clarity. I have retained the > whole note for context, although we should probably trim it soon. > > 1) The difference between virtual router, virtual routing protocol, > routing process or routing protocol instance as you intended it is not a > big deal. However, you should understand that vendors have used those > terms in different ways to represent very different things. > > 1') More importantly, if you are talking about configuring a routing > protocol, you have to get teh granularity right. It is not possible, in > BGP, to have different hold times for different address families. The > different address families are all using the same TCP exchange over the > same ports, managed by the same protocol machinery. So when one tries > to configure a routing protocol, if you define that to be a single > address family, and to be separate for unicast and multicast, you make > it MORE complicated to represent the realities. > > With regard to the RIBs, what I would recommend is NOT to try to model > the per-protocol RIB. Rather, model > 1) The central, protocol independent, RIB, ala RIB2 > 2) The policies and priorities by which things get into the RIB, which > can be configured. > 3) The individual routing instances. This model should allow for > multiple instances of different protocols, but not require it > 3a) For each routing protocol instance, the policies by which it > extracts information from the common RIB, and the policies by which it > adds information to the common RIB > 3b) The routing data structure specific to the protocol. For most > protocols, these are NOT modifiable. Modification is generally done by > policies, not by manipulating the data. For IS-IS and OSPF, we would > want to model the link state database. For BGP, we would want to > advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP > structure needs to include the BGP attributes, like the path, and has to > be organized in terms of the NLRI. It has to represent the fact that > several NLRI can share the same properties. (This may change in the > future, but is currently the case.) I would NOT recommend trying to > represent the IS-IS Link State Database using the same parent structure > as the BGP RIB. (It is probably not even worth trying to create a > common parent for the OSPF and IS-IS LSDB.) And I would not use the > same structure for the BGP RIB as for the central RIB. > > Yours, > Joel > > On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: > > Joel, > > > > I have to apologize, you didn't miss anything. Your comments are quite far-reaching, so I had no quick answer and then had to work on other things. > > > > On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: > > > >> I sent a question about this several weeks ago. I apologize if there was a clear answer which I missed. > >> > >> The document seems to have a major problem of mixing the notions of RIB and routing process. The reality is quite different from the document in several regards. Conceptually, RIB and Routing Process are orthogonal concepts. A routing process may maintain several RIBs. it may manitain only one. It also may pull information from > > > > There may be a terminological confusion, as Phil already pointed out. A routing process is essentially a "virtual router", so, by definition, its routing information is not shared with other virtual routers. I think that what you call "routing process" is a "routing-protocol-instance" in my terminology. > > > > On the other hand, each routing-process (= virtual router) is limited to a single address family (AFI+SAFI), in order to make the data model extensible and manageable. From a practical point of view, is it a serious limitation? > > > >> RIBs beyond the one or ones it maintains. It may work with one address family, or several. It may handle only unicast, only multicast, or both. > >> And, conversely, some routing protocols do not operate in terms of maintaining a RIB (although they still have to interact with one or more RIBs at the edge. > >> > >> I get further confused by the placement of operations like one for deleting routes in the routing protocols. If a routing protocol learns a route, you generally MUST NOT delete it. Depending upon the routing protocol, you may or may not have knobs to > > > > I think this "MUST NOT" only applies to link-state protocols, otherwise routes learned by other routing protocols can be filtered before they are imported to a routing table. > > > > In any case, the "delete-route" operation can be removed and other operations/knobs added, this area is open to further discussion. I just wanted to include at least one rpc statement in the module to make people that are not very familiar with YANG aware of the possibility to define new operations. > > > >> control whether it is used. > >> (And there may be separate knobs affecting the way the system uses the RIB output from the routing protocol, but that is a different matter.) > >> > >> Normally, modeling has concentrated on the central RIB, with its policy and data. Routing protocol configuration has focussed on the individual knobs for the routing protocols. And instances are handled on a case by case basis. > >> Better commonality is good. > >> Mixing the concepts of RIB and Routing protocol instance is at best VERY confusing, and possibly worse. > > > > Could you sketch how the data model should be organized? I am not sure that the concept of a central RIB fits existing implementations with policy routing, where sets of routes can be filtered, manipulated and redistributed between routing protocols in many different ways. > > > > Thanks, Lada > > > >> > >> Yours, > >> Joel M. Halpern > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CESNET > > PGP Key ID: E74E8C0C From ietf@andybierman.com Thu May 26 11:05:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4417FE06D6 for ; Thu, 26 May 2011 11:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 TL0tURiDX2qr for ; Thu, 26 May 2011 11:05:11 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC8FE0740 for ; Thu, 26 May 2011 11:05:03 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p4QI4vLT020696 for ; Thu, 26 May 2011 14:05:02 -0400 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43702] helo=[192.168.0.22]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8C/CA-05097-9469EDD4; Thu, 26 May 2011 14:04:57 -0400 Message-ID: <4DDE964A.2030209@andybierman.com> Date: Thu, 26 May 2011 11:04:58 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> In-Reply-To: <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 18:05:15 -0000 On 05/26/2011 09:09 AM, t.petch wrote: > Joel > > I think that this discussion is premature and on the wrong list:-( > You have identified one of the key reasons why standard configuration has been so difficult to achieve. The domain experts don't really know the data modeling stuff, and the data modeling experts don't really know the domain stuff. I think our AD already looked into getting us a routing expert to help with early review the YANG models. So that should be the next step. > I would like to see a routing list, eg routing area WG, discuss > what the model of a router should be, and then have this list turn that > into Yang (or whatever). I think that the experience of people like > Curtis is needed to come up with something that lasts. RFC1213 > has not stood the test of time and I would not expect this to. > > In passing, I do not share your view of routers and routing terminology, and > nor do I share Lada's, but do not know if any of us are right. > > Tom Petch > Andy From jmh@joelhalpern.com Thu May 26 18:21:27 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42102E06A5 for ; Thu, 26 May 2011 18:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 2e-CSRQ9rcLR for ; Thu, 26 May 2011 18:21:26 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id F3E11E0697 for ; Thu, 26 May 2011 18:21:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C270F4300F5; Thu, 26 May 2011 18:21:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9D2974300EF; Thu, 26 May 2011 18:21:25 -0700 (PDT) Message-ID: <4DDEFC91.4060405@joelhalpern.com> Date: Thu, 26 May 2011 21:21:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> In-Reply-To: <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 01:21:27 -0000 It would be hard for the discussion to be premature. Waiting until the working group finished with the document, and then raising these issues, when I noticed them early, would be rather rude of me. As for whether it is the right list, this working group is working on the document. Unless the chairs and ADs decide to move it, this is the place to discuss it. (Yes, normally, MIB and other kinds of modeling is done in the subject matter working group. The RTGWG does not have the time to take this as its primary work item :-) As for the view of modeling, I can well believe that there is a better model. Lada reasonably asked me to put a starting alternative on the table. That seemed a fair request, and putting the alternative forward might help folks understand my objection to the WG document. So I sketched something. I tried to make it match the range of routers, routing protocols, and protocol implementations I have worked with over the years. A cleaner model than I suggested would be very helpful. Yours, Joel On 5/26/2011 12:09 PM, t.petch wrote: > Joel > > I think that this discussion is premature and on the wrong list:-( > > I would like to see a routing list, eg routing area WG, discuss > what the model of a router should be, and then have this list turn that > into Yang (or whatever). I think that the experience of people like > Curtis is needed to come up with something that lasts. RFC1213 > has not stood the test of time and I would not expect this to. > > In passing, I do not share your view of routers and routing terminology, and > nor do I share Lada's, but do not know if any of us are right. > > Tom Petch > > ----- Original Message ----- > From: "Joel M. Halpern" > To: "Ladislav Lhotka" > Cc: "NETMOD Working Group" > Sent: Wednesday, May 25, 2011 2:41 AM > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > > >> Two comments, brought to the front for clarity. I have retained the >> whole note for context, although we should probably trim it soon. >> >> 1) The difference between virtual router, virtual routing protocol, >> routing process or routing protocol instance as you intended it is not a >> big deal. However, you should understand that vendors have used those >> terms in different ways to represent very different things. >> >> 1') More importantly, if you are talking about configuring a routing >> protocol, you have to get teh granularity right. It is not possible, in >> BGP, to have different hold times for different address families. The >> different address families are all using the same TCP exchange over the >> same ports, managed by the same protocol machinery. So when one tries >> to configure a routing protocol, if you define that to be a single >> address family, and to be separate for unicast and multicast, you make >> it MORE complicated to represent the realities. >> >> With regard to the RIBs, what I would recommend is NOT to try to model >> the per-protocol RIB. Rather, model >> 1) The central, protocol independent, RIB, ala RIB2 >> 2) The policies and priorities by which things get into the RIB, which >> can be configured. >> 3) The individual routing instances. This model should allow for >> multiple instances of different protocols, but not require it >> 3a) For each routing protocol instance, the policies by which it >> extracts information from the common RIB, and the policies by which it >> adds information to the common RIB >> 3b) The routing data structure specific to the protocol. For most >> protocols, these are NOT modifiable. Modification is generally done by >> policies, not by manipulating the data. For IS-IS and OSPF, we would >> want to model the link state database. For BGP, we would want to >> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP >> structure needs to include the BGP attributes, like the path, and has to >> be organized in terms of the NLRI. It has to represent the fact that >> several NLRI can share the same properties. (This may change in the >> future, but is currently the case.) I would NOT recommend trying to >> represent the IS-IS Link State Database using the same parent structure >> as the BGP RIB. (It is probably not even worth trying to create a >> common parent for the OSPF and IS-IS LSDB.) And I would not use the >> same structure for the BGP RIB as for the central RIB. >> >> Yours, >> Joel >> >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: >>> Joel, >>> >>> I have to apologize, you didn't miss anything. Your comments are quite > far-reaching, so I had no quick answer and then had to work on other things. >>> >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: >>> >>>> I sent a question about this several weeks ago. I apologize if there was a > clear answer which I missed. >>>> >>>> The document seems to have a major problem of mixing the notions of RIB and > routing process. The reality is quite different from the document in several > regards. Conceptually, RIB and Routing Process are orthogonal concepts. A > routing process may maintain several RIBs. it may manitain only one. It also > may pull information from >>> >>> There may be a terminological confusion, as Phil already pointed out. A > routing process is essentially a "virtual router", so, by definition, its > routing information is not shared with other virtual routers. I think that what > you call "routing process" is a "routing-protocol-instance" in my terminology. >>> >>> On the other hand, each routing-process (= virtual router) is limited to a > single address family (AFI+SAFI), in order to make the data model extensible and > manageable. From a practical point of view, is it a serious limitation? >>> >>>> RIBs beyond the one or ones it maintains. It may work with one address > family, or several. It may handle only unicast, only multicast, or both. >>>> And, conversely, some routing protocols do not operate in terms of > maintaining a RIB (although they still have to interact with one or more RIBs at > the edge. >>>> >>>> I get further confused by the placement of operations like one for deleting > routes in the routing protocols. If a routing protocol learns a route, you > generally MUST NOT delete it. Depending upon the routing protocol, you may or > may not have knobs to >>> >>> I think this "MUST NOT" only applies to link-state protocols, otherwise > routes learned by other routing protocols can be filtered before they are > imported to a routing table. >>> >>> In any case, the "delete-route" operation can be removed and other > operations/knobs added, this area is open to further discussion. I just wanted > to include at least one rpc statement in the module to make people that are not > very familiar with YANG aware of the possibility to define new operations. >>> >>>> control whether it is used. >>>> (And there may be separate knobs affecting the way the system uses the RIB > output from the routing protocol, but that is a different matter.) >>>> >>>> Normally, modeling has concentrated on the central RIB, with its policy and > data. Routing protocol configuration has focussed on the individual knobs for > the routing protocols. And instances are handled on a case by case basis. >>>> Better commonality is good. >>>> Mixing the concepts of RIB and Routing protocol instance is at best VERY > confusing, and possibly worse. >>> >>> Could you sketch how the data model should be organized? I am not sure that > the concept of a central RIB fits existing implementations with policy routing, > where sets of routes can be filtered, manipulated and redistributed between > routing protocols in many different ways. >>> >>> Thanks, Lada >>> >>>> >>>> Yours, >>>> Joel M. Halpern >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C > > From lhotka@cesnet.cz Fri May 27 01:02:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B902EE079F for ; Fri, 27 May 2011 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] 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 4AMceW0l5gXL for ; Fri, 27 May 2011 01:02:31 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 10E07E0768 for ; Fri, 27 May 2011 01:02:29 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 23BA82CDE057; Fri, 27 May 2011 10:02:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1--388850954; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> Date: Fri, 27 May 2011 10:02:26 +0200 Message-Id: References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 08:02:31 -0000 --Apple-Mail-1--388850954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, I absolutely agree. In order to get the generic framework right, one has = to know quite precisely the needs of all the various routing protocols = and address families that will be supported, including things like = multicast and MPLS. Routing experts should be heard now, and I hope that by criticizing my = initial data model, they will be able to come up with something better. Lada =20 On May 26, 2011, at 6:09 PM, t.petch wrote: > Joel >=20 > I think that this discussion is premature and on the wrong list:-( >=20 > I would like to see a routing list, eg routing area WG, discuss > what the model of a router should be, and then have this list turn = that > into Yang (or whatever). I think that the experience of people like > Curtis is needed to come up with something that lasts. RFC1213 > has not stood the test of time and I would not expect this to. >=20 > In passing, I do not share your view of routers and routing = terminology, and > nor do I share Lada's, but do not know if any of us are right. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Joel M. Halpern" > To: "Ladislav Lhotka" > Cc: "NETMOD Working Group" > Sent: Wednesday, May 25, 2011 2:41 AM > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt >=20 >=20 >> Two comments, brought to the front for clarity. I have retained the >> whole note for context, although we should probably trim it soon. >>=20 >> 1) The difference between virtual router, virtual routing protocol, >> routing process or routing protocol instance as you intended it is = not a >> big deal. However, you should understand that vendors have used = those >> terms in different ways to represent very different things. >>=20 >> 1') More importantly, if you are talking about configuring a routing >> protocol, you have to get teh granularity right. It is not possible, = in >> BGP, to have different hold times for different address families. = The >> different address families are all using the same TCP exchange over = the >> same ports, managed by the same protocol machinery. So when one = tries >> to configure a routing protocol, if you define that to be a single >> address family, and to be separate for unicast and multicast, you = make >> it MORE complicated to represent the realities. >>=20 >> With regard to the RIBs, what I would recommend is NOT to try to = model >> the per-protocol RIB. Rather, model >> 1) The central, protocol independent, RIB, ala RIB2 >> 2) The policies and priorities by which things get into the RIB, = which >> can be configured. >> 3) The individual routing instances. This model should allow for >> multiple instances of different protocols, but not require it >> 3a) For each routing protocol instance, the policies by which it >> extracts information from the common RIB, and the policies by which = it >> adds information to the common RIB >> 3b) The routing data structure specific to the protocol. For most >> protocols, these are NOT modifiable. Modification is generally done = by >> policies, not by manipulating the data. For IS-IS and OSPF, we would >> want to model the link state database. For BGP, we would want to >> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP >> structure needs to include the BGP attributes, like the path, and has = to >> be organized in terms of the NLRI. It has to represent the fact that >> several NLRI can share the same properties. (This may change in the >> future, but is currently the case.) I would NOT recommend trying to >> represent the IS-IS Link State Database using the same parent = structure >> as the BGP RIB. (It is probably not even worth trying to create a >> common parent for the OSPF and IS-IS LSDB.) And I would not use the >> same structure for the BGP RIB as for the central RIB. >>=20 >> Yours, >> Joel >>=20 >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: >>> Joel, >>>=20 >>> I have to apologize, you didn't miss anything. Your comments are = quite > far-reaching, so I had no quick answer and then had to work on other = things. >>>=20 >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: >>>=20 >>>> I sent a question about this several weeks ago. I apologize if = there was a > clear answer which I missed. >>>>=20 >>>> The document seems to have a major problem of mixing the notions of = RIB and > routing process. The reality is quite different from the document in = several > regards. Conceptually, RIB and Routing Process are orthogonal = concepts. A > routing process may maintain several RIBs. it may manitain only one. = It also > may pull information from >>>=20 >>> There may be a terminological confusion, as Phil already pointed = out. A > routing process is essentially a "virtual router", so, by definition, = its > routing information is not shared with other virtual routers. I think = that what > you call "routing process" is a "routing-protocol-instance" in my = terminology. >>>=20 >>> On the other hand, each routing-process (=3D virtual router) is = limited to a > single address family (AFI+SAFI), in order to make the data model = extensible and > manageable. =46rom a practical point of view, is it a serious = limitation? >>>=20 >>>> RIBs beyond the one or ones it maintains. It may work with one = address > family, or several. It may handle only unicast, only multicast, or = both. >>>> And, conversely, some routing protocols do not operate in terms of > maintaining a RIB (although they still have to interact with one or = more RIBs at > the edge. >>>>=20 >>>> I get further confused by the placement of operations like one for = deleting > routes in the routing protocols. If a routing protocol learns a = route, you > generally MUST NOT delete it. Depending upon the routing protocol, = you may or > may not have knobs to >>>=20 >>> I think this "MUST NOT" only applies to link-state protocols, = otherwise > routes learned by other routing protocols can be filtered before they = are > imported to a routing table. >>>=20 >>> In any case, the "delete-route" operation can be removed and other > operations/knobs added, this area is open to further discussion. I = just wanted > to include at least one rpc statement in the module to make people = that are not > very familiar with YANG aware of the possibility to define new = operations. >>>=20 >>>> control whether it is used. >>>> (And there may be separate knobs affecting the way the system uses = the RIB > output from the routing protocol, but that is a different matter.) >>>>=20 >>>> Normally, modeling has concentrated on the central RIB, with its = policy and > data. Routing protocol configuration has focussed on the individual = knobs for > the routing protocols. And instances are handled on a case by case = basis. >>>> Better commonality is good. >>>> Mixing the concepts of RIB and Routing protocol instance is at best = VERY > confusing, and possibly worse. >>>=20 >>> Could you sketch how the data model should be organized? I am not = sure that > the concept of a central RIB fits existing implementations with policy = routing, > where sets of routes can be filtered, manipulated and redistributed = between > routing protocols in many different ways. >>>=20 >>> Thanks, Lada >>>=20 >>>>=20 >>>> Yours, >>>> Joel M. Halpern >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-1--388850954 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTEwNTI3MDgwMjI3WjAjBgkqhkiG9w0BCQQxFgQUKVvSvQpwMinHhweVXIRuEQySqDAwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAPlP813ZxzeqmmM6/52tn3LOq2 WyIT5cxIyHqtEf1U8cPs5cIeaH+yxngH5IXJzJYI8Ey5nPP5ewYp5kmTLqWOA5FPfrlS6rgLKD2x ppx8b3A78uCk1EEW/sr/1Mjs/t3Hpkh73r3VvLizryJqMMUqZ8HyHSIlqmcwdVOlW1DC8ilbwrfa ldmU6iM9gqaFTnF3jZ76t0ZZUvdVXXEYtBcTc8D12Mc1jyTF4uhZNEhJWtLcG334QyCxBDksny/O AMu8IXzZ2Hk3jsojJ7ODLokMaXiOq1VbrqdRhWYEFyr1Hmja+Ch/t0NAwouA/2gRDB08F7fllpRq mcxYpYN32TIpAAAAAAAA --Apple-Mail-1--388850954-- From ietfc@btconnect.com Fri May 27 10:09:32 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B135E082B for ; Fri, 27 May 2011 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 YIqYhhEXKInz for ; Fri, 27 May 2011 10:09:31 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id A853CE0826 for ; Fri, 27 May 2011 10:09:30 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2bthomr09.btconnect.com with SMTP id DBG86485; Fri, 27 May 2011 18:09:25 +0100 (BST) Message-ID: <010901cc1c88$345c5ca0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ladislav Lhotka" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> Date: Fri, 27 May 2011 18:07:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DDFDAC4.003E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.5.27.163015:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __STOCK_PHRASE_24, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, ECARD_WORD, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4DDFDAC6.00DE,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 17:09:32 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" Cc: "Joel M. Halpern" ; "NETMOD Working Group" Sent: Friday, May 27, 2011 10:02 AM Tom, I absolutely agree. In order to get the generic framework right, one has to know quite precisely the needs of all the various routing protocols and address families that will be supported, including things like multicast and MPLS. Routing experts should be heard now, and I hope that by criticizing my initial data model, they will be able to come up with something better. Lada My starting point is that there are four kinds of routers with different, perhaps incompatible, requirements. - DFZ Gbps routers, with (almost) everything on the line card and most of that is MPLS switching, not routing - CPE routers, probably the most numerous in the world, the simplest (what's a routing protocol?) but because they are CPE in the most need of management - middle of the road, blades in chassis, alongside switch, hub, management etc blades (which is what I am most familiar with) - the host I am using to create this:-) You make mention of MPLS which makes me think you are focussing on the first and while its needs are great, it also has the most skilled staff and support, will be most manufacturer dependent and perhaps with the least need of standardisation by us since the proprietary modules will do everything so much better. I remember well when first I looked at the CISCO MIB for an entry level router; the proprietary modules had 10 times as many objects as the standard MIB would have had and had everything I needed; perhaps it is the last we should focus on. Tom PS my PC says that your e-mail is 'secure' but that the security is faulty:-( Lada On May 26, 2011, at 6:09 PM, t.petch wrote: > Joel > > I think that this discussion is premature and on the wrong list:-( > > I would like to see a routing list, eg routing area WG, discuss > what the model of a router should be, and then have this list turn that > into Yang (or whatever). I think that the experience of people like > Curtis is needed to come up with something that lasts. RFC1213 > has not stood the test of time and I would not expect this to. > > In passing, I do not share your view of routers and routing terminology, and > nor do I share Lada's, but do not know if any of us are right. > > Tom Petch > > ----- Original Message ----- > From: "Joel M. Halpern" > To: "Ladislav Lhotka" > Cc: "NETMOD Working Group" > Sent: Wednesday, May 25, 2011 2:41 AM > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > > >> Two comments, brought to the front for clarity. I have retained the >> whole note for context, although we should probably trim it soon. >> >> 1) The difference between virtual router, virtual routing protocol, >> routing process or routing protocol instance as you intended it is not a >> big deal. However, you should understand that vendors have used those >> terms in different ways to represent very different things. >> >> 1') More importantly, if you are talking about configuring a routing >> protocol, you have to get teh granularity right. It is not possible, in >> BGP, to have different hold times for different address families. The >> different address families are all using the same TCP exchange over the >> same ports, managed by the same protocol machinery. So when one tries >> to configure a routing protocol, if you define that to be a single >> address family, and to be separate for unicast and multicast, you make >> it MORE complicated to represent the realities. >> >> With regard to the RIBs, what I would recommend is NOT to try to model >> the per-protocol RIB. Rather, model >> 1) The central, protocol independent, RIB, ala RIB2 >> 2) The policies and priorities by which things get into the RIB, which >> can be configured. >> 3) The individual routing instances. This model should allow for >> multiple instances of different protocols, but not require it >> 3a) For each routing protocol instance, the policies by which it >> extracts information from the common RIB, and the policies by which it >> adds information to the common RIB >> 3b) The routing data structure specific to the protocol. For most >> protocols, these are NOT modifiable. Modification is generally done by >> policies, not by manipulating the data. For IS-IS and OSPF, we would >> want to model the link state database. For BGP, we would want to >> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP >> structure needs to include the BGP attributes, like the path, and has to >> be organized in terms of the NLRI. It has to represent the fact that >> several NLRI can share the same properties. (This may change in the >> future, but is currently the case.) I would NOT recommend trying to >> represent the IS-IS Link State Database using the same parent structure >> as the BGP RIB. (It is probably not even worth trying to create a >> common parent for the OSPF and IS-IS LSDB.) And I would not use the >> same structure for the BGP RIB as for the central RIB. >> >> Yours, >> Joel >> >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: >>> Joel, >>> >>> I have to apologize, you didn't miss anything. Your comments are quite > far-reaching, so I had no quick answer and then had to work on other things. >>> >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: >>> >>>> I sent a question about this several weeks ago. I apologize if there was a > clear answer which I missed. >>>> >>>> The document seems to have a major problem of mixing the notions of RIB and > routing process. The reality is quite different from the document in several > regards. Conceptually, RIB and Routing Process are orthogonal concepts. A > routing process may maintain several RIBs. it may manitain only one. It also > may pull information from >>> >>> There may be a terminological confusion, as Phil already pointed out. A > routing process is essentially a "virtual router", so, by definition, its > routing information is not shared with other virtual routers. I think that what > you call "routing process" is a "routing-protocol-instance" in my terminology. >>> >>> On the other hand, each routing-process (= virtual router) is limited to a > single address family (AFI+SAFI), in order to make the data model extensible and > manageable. From a practical point of view, is it a serious limitation? >>> >>>> RIBs beyond the one or ones it maintains. It may work with one address > family, or several. It may handle only unicast, only multicast, or both. >>>> And, conversely, some routing protocols do not operate in terms of > maintaining a RIB (although they still have to interact with one or more RIBs at > the edge. >>>> >>>> I get further confused by the placement of operations like one for deleting > routes in the routing protocols. If a routing protocol learns a route, you > generally MUST NOT delete it. Depending upon the routing protocol, you may or > may not have knobs to >>> >>> I think this "MUST NOT" only applies to link-state protocols, otherwise > routes learned by other routing protocols can be filtered before they are > imported to a routing table. >>> >>> In any case, the "delete-route" operation can be removed and other > operations/knobs added, this area is open to further discussion. I just wanted > to include at least one rpc statement in the module to make people that are not > very familiar with YANG aware of the possibility to define new operations. >>> >>>> control whether it is used. >>>> (And there may be separate knobs affecting the way the system uses the RIB > output from the routing protocol, but that is a different matter.) >>>> >>>> Normally, modeling has concentrated on the central RIB, with its policy and > data. Routing protocol configuration has focussed on the individual knobs for > the routing protocols. And instances are handled on a case by case basis. >>>> Better commonality is good. >>>> Mixing the concepts of RIB and Routing protocol instance is at best VERY > confusing, and possibly worse. >>> >>> Could you sketch how the data model should be organized? I am not sure that > the concept of a central RIB fits existing implementations with policy routing, > where sets of routes can be filtered, manipulated and redistributed between > routing protocols in many different ways. >>> >>> Thanks, Lada >>> >>>> >>>> Yours, >>>> Joel M. Halpern >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From dromasca@avaya.com Sun May 29 02:31:32 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCDFE0708 for ; Sun, 29 May 2011 02:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] 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 HxQw8+SpcZsK for ; Sun, 29 May 2011 02:31:31 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8B75BE0651 for ; Sun, 29 May 2011 02:31:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAHoR4k2HCzI1/2dsb2JhbABVl3GOT3eIcaNgApoQhh4ElSqKQQ X-IronPort-AV: E=Sophos;i="4.65,288,1304308800"; d="scan'208";a="190684090" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 May 2011 05:31:30 -0400 X-IronPort-AV: E=Sophos;i="4.65,288,1304308800"; d="scan'208";a="657352153" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 May 2011 05:26:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 May 2011 11:26:26 +0200 Message-ID: In-Reply-To: <4DDEFC91.4060405@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt Thread-Index: AcwcDGkoAF0hIIojTlmNQP0Banj1xwB1JnsQ References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz><4DDC503C.7020406@joelhalpern.com><00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> <4DDEFC91.4060405@joelhalpern.com> From: "Romascanu, Dan (Dan)" To: "Joel M. Halpern" , "t.petch" Cc: adrian@olddog.co.uk, NETMOD Working Group , stbryant@cisco.com Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 09:31:32 -0000 Hi,=20 Speaking from the perspective of the AD and answering different comments made about the placement of this work and the participants.=20 I agree in principle with the point that specialized YANG models should be standardized in the WGs that are responsible with the technology. However, as YANG modelling is at its first steps (and RFCs) we decided to have this first routing module standardized in NETMOD, where all the experts in YANG are, while inviting experts from the routing area to participate in the process. Joel was the first who engaged, now Tom joined the discussions, we hope to have more routing people participating in the discussions - and I am copying the routing ADs with the hope that another plea on this respect will result into a broader participation.=20 Later, as we did with MIBs we want the WGs in the other areas of the IETF and out of the IETF to take over. Now what is important is to get YANG experts and routing experts together to work on this module.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Friday, May 27, 2011 4:21 AM > To: t.petch > Cc: NETMOD Working Group > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt >=20 > It would be hard for the discussion to be premature. Waiting until the > working group finished with the document, and then raising these > issues, > when I noticed them early, would be rather rude of me. > As for whether it is the right list, this working group is working on > the document. Unless the chairs and ADs decide to move it, this is the > place to discuss it. (Yes, normally, MIB and other kinds of modeling > is > done in the subject matter working group. The RTGWG does not have the > time to take this as its primary work item :-) >=20 > As for the view of modeling, I can well believe that there is a better > model. Lada reasonably asked me to put a starting alternative on the > table. That seemed a fair request, and putting the alternative forward > might help folks understand my objection to the WG document. So I > sketched something. I tried to make it match the range of routers, > routing protocols, and protocol implementations I have worked with over > the years. A cleaner model than I suggested would be very helpful. >=20 > Yours, > Joel >=20 > On 5/26/2011 12:09 PM, t.petch wrote: > > Joel > > > > I think that this discussion is premature and on the wrong list:-( > > > > I would like to see a routing list, eg routing area WG, discuss > > what the model of a router should be, and then have this list turn > that > > into Yang (or whatever). I think that the experience of people like > > Curtis is needed to come up with something that lasts. RFC1213 > > has not stood the test of time and I would not expect this to. > > > > In passing, I do not share your view of routers and routing > terminology, and > > nor do I share Lada's, but do not know if any of us are right. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Joel M. Halpern" > > To: "Ladislav Lhotka" > > Cc: "NETMOD Working Group" > > Sent: Wednesday, May 25, 2011 2:41 AM > > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > > > > > >> Two comments, brought to the front for clarity. I have retained the > >> whole note for context, although we should probably trim it soon. > >> > >> 1) The difference between virtual router, virtual routing protocol, > >> routing process or routing protocol instance as you intended it is > not a > >> big deal. However, you should understand that vendors have used > those > >> terms in different ways to represent very different things. > >> > >> 1') More importantly, if you are talking about configuring a routing > >> protocol, you have to get teh granularity right. It is not > possible, in > >> BGP, to have different hold times for different address families. > The > >> different address families are all using the same TCP exchange over > the > >> same ports, managed by the same protocol machinery. So when one > tries > >> to configure a routing protocol, if you define that to be a single > >> address family, and to be separate for unicast and multicast, you > make > >> it MORE complicated to represent the realities. > >> > >> With regard to the RIBs, what I would recommend is NOT to try to > model > >> the per-protocol RIB. Rather, model > >> 1) The central, protocol independent, RIB, ala RIB2 > >> 2) The policies and priorities by which things get into the RIB, > which > >> can be configured. > >> 3) The individual routing instances. This model should allow for > >> multiple instances of different protocols, but not require it > >> 3a) For each routing protocol instance, the policies by which it > >> extracts information from the common RIB, and the policies by which > it > >> adds information to the common RIB > >> 3b) The routing data structure specific to the protocol. For most > >> protocols, these are NOT modifiable. Modification is generally done > by > >> policies, not by manipulating the data. For IS-IS and OSPF, we would > >> want to model the link state database. For BGP, we would want to > >> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The > BGP > >> structure needs to include the BGP attributes, like the path, and > has to > >> be organized in terms of the NLRI. It has to represent the fact > that > >> several NLRI can share the same properties. (This may change in the > >> future, but is currently the case.) I would NOT recommend trying to > >> represent the IS-IS Link State Database using the same parent > structure > >> as the BGP RIB. (It is probably not even worth trying to create a > >> common parent for the OSPF and IS-IS LSDB.) And I would not use > the > >> same structure for the BGP RIB as for the central RIB. > >> > >> Yours, > >> Joel > >> > >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: > >>> Joel, > >>> > >>> I have to apologize, you didn't miss anything. Your comments are > quite > > far-reaching, so I had no quick answer and then had to work on other > things. > >>> > >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: > >>> > >>>> I sent a question about this several weeks ago. I apologize if > there was a > > clear answer which I missed. > >>>> > >>>> The document seems to have a major problem of mixing the notions > of RIB and > > routing process. The reality is quite different from the document in > several > > regards. Conceptually, RIB and Routing Process are orthogonal > concepts. A > > routing process may maintain several RIBs. it may manitain only one. > It also > > may pull information from > >>> > >>> There may be a terminological confusion, as Phil already pointed > out. A > > routing process is essentially a "virtual router", so, by definition, > its > > routing information is not shared with other virtual routers. I think > that what > > you call "routing process" is a "routing-protocol-instance" in my > terminology. > >>> > >>> On the other hand, each routing-process (=3D virtual router) is > limited to a > > single address family (AFI+SAFI), in order to make the data model > extensible and > > manageable. From a practical point of view, is it a serious > limitation? > >>> > >>>> RIBs beyond the one or ones it maintains. It may work with one > address > > family, or several. It may handle only unicast, only multicast, or > both. > >>>> And, conversely, some routing protocols do not operate in terms of > > maintaining a RIB (although they still have to interact with one or > more RIBs at > > the edge. > >>>> > >>>> I get further confused by the placement of operations like one for > deleting > > routes in the routing protocols. If a routing protocol learns a > route, you > > generally MUST NOT delete it. Depending upon the routing protocol, > you may or > > may not have knobs to > >>> > >>> I think this "MUST NOT" only applies to link-state protocols, > otherwise > > routes learned by other routing protocols can be filtered before they > are > > imported to a routing table. > >>> > >>> In any case, the "delete-route" operation can be removed and other > > operations/knobs added, this area is open to further discussion. I > just wanted > > to include at least one rpc statement in the module to make people > that are not > > very familiar with YANG aware of the possibility to define new > operations. > >>> > >>>> control whether it is used. > >>>> (And there may be separate knobs affecting the way the system uses > the RIB > > output from the routing protocol, but that is a different matter.) > >>>> > >>>> Normally, modeling has concentrated on the central RIB, with its > policy and > > data. Routing protocol configuration has focussed on the individual > knobs for > > the routing protocols. And instances are handled on a case by case > basis. > >>>> Better commonality is good. > >>>> Mixing the concepts of RIB and Routing protocol instance is at > best VERY > > confusing, and possibly worse. > >>> > >>> Could you sketch how the data model should be organized? I am not > sure that > > the concept of a central RIB fits existing implementations with > policy routing, > > where sets of routes can be filtered, manipulated and redistributed > between > > routing protocols in many different ways. > >>> > >>> Thanks, Lada > >>> > >>>> > >>>> Yours, > >>>> Joel M. Halpern > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> -- > >>> Ladislav Lhotka, CESNET > >>> PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod