From edc@google.com Fri Nov 1 14:28:07 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A337111E8166 for ; Fri, 1 Nov 2013 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqVlMW3OgmA5 for ; Fri, 1 Nov 2013 14:28:07 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7511E8155 for ; Fri, 1 Nov 2013 14:28:06 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t60so67565wes.26 for ; Fri, 01 Nov 2013 14:28:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=k0FOC73CK8dwoBj0H9jFFkVeUSsZkWobTQSHWPySmNs=; b=Kfqcg1VkVupEMinoExN+9RzVafN4b1jnrB6A9E41734Muk8ytnkydIw7NQt6cBGOzX EqW2bCEm4JjZkoQy+CvIF+er6TgfNWTaitUtZ0LBkC3nRXJIl3zW/oFWYa17lNKQnaM0 CkbLRFs9qcguFIuRxZArKB3HdFm/stXXZbLoTHoem3IECL1iDshxHxdZjpJ6sYu9hl/b SQzXXRMV5tQT+QFGpCXu85GHHViu2jTdEF5wzHb7D8+BNN+34luuWEgxggivOid0tmuA f3tt00fRDKWlJF81SGyt2QfUyr1bNiuhucn2sQui5UlN4krHZxymtyXnOym7oe+3UZod 5U5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=k0FOC73CK8dwoBj0H9jFFkVeUSsZkWobTQSHWPySmNs=; b=KyU2pfZ+mXOUWApZzAaLDbcfEClFmF8E9Di/6+d3aWlHV1GwlTSr9uzsjCMcLrgEvM J/4g/H3QAgHgaxiS1wa2KMuEgnOnOzvdbwcTQGjaEc67PcrmPfR4JeJRgCgyS+8HsD2S lGDzdwoC+N5s+JLnUoxAhFQj9h5rVUJ0EHLGsvAT39ahHvZP9yDimRliQrpMs1dmLm15 KwbNjwTICTCgY2Zo4XX6S7H0pf5FVnD1FbOewVsUWv7cWZAnmBw58x9X/hO+IrEoIHCd Hu0bSx1mmU+WFBQZMmRUO9VE+giTjMYBKOcTnXB/O/aqx31kFpq2sxq5ur4QDPiiOii6 fS+w== X-Gm-Message-State: ALoCoQlAUXRexSNVa/atA68NZtxTpmllEQVxWy4eeQQ+2WExXyGg6wlC/NyLUHZ/GaftOQaKy5YPqWvf+Qqdgo+gmk2e8kCu+YQyrV1hQHEICyktMeYeNCh1JtMOkLHYugiwvcEFeLnkphPOF2kz+Pf3Set8HYn7rRPebZ2kZ6PLslRS5tHku52Mi3ogsAvTqdVdCoVhIX32 X-Received: by 10.180.37.162 with SMTP id z2mr3644678wij.58.1383341286135; Fri, 01 Nov 2013 14:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Fri, 1 Nov 2013 14:27:26 -0700 (PDT) From: Edward Crabbe Date: Fri, 1 Nov 2013 14:27:26 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [i2rs] Agenda Posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 21:28:07 -0000 Hey all; The agenda for the coming working group meeting has been posted. Apologies for our tardiness; Unfortunately, we weren't able to provide slots to everyone this time around. Please take a look at the agenda. Because we're posting this late, we're going to be accepting slides all the way through Tuesday morning. cheers all, -ed From linda.dunbar@huawei.com Fri Nov 1 15:49:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B281B11E813A for ; Fri, 1 Nov 2013 15:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6QQluqkC4mS for ; Fri, 1 Nov 2013 15:49:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CDAF911E8136 for ; Fri, 1 Nov 2013 15:49:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXL71321; Fri, 01 Nov 2013 22:49:32 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 22:49:05 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Nov 2013 22:49:31 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 15:49:21 -0700 From: Linda Dunbar To: "i2rs@ietf.org" , "Jixiaofeng (Steven)" , Zhuangshunwan Thread-Topic: Questions to draft-ji-i2rs-usecases-ccne-service-00 Thread-Index: Ac7XVJxDbsF9exUPTyaNCqe2Lyfcmw== Date: Fri, 1 Nov 2013 22:49:20 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFB79F@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.129] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BFB79Fdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [i2rs] Questions to draft-ji-i2rs-usecases-ccne-service-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 22:49:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BFB79Fdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xiao Feng and ShunWan, draft-ji-i2rs-usecases-ccne-service-00 provides some interesting use cases = for I2RS. For the first case "Controlling Path by RR", are you proposing interfaces t= o RR router? Is it correct? What if the request to RR conflict with what R= R's own computation from all other routers? For the following text (3.1.3): Are you trying to make RR dictate routes wi= thin one AS with explicit commands, but not via changing RIB? "RR can compute the routes for every router and install/distribute the rout= es to corresponding routers" For the second case on PCE, are you suggesting using PCEP to control router= 's FIB? Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645BFB79Fdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xiao Feng and ShunWan,

 

draft-ji-i2rs-usecases-ccne-service-00 provides some= interesting use cases for I2RS.

 

For the first case “Controlling Path by RRR= 21;, are you proposing interfaces to RR router?  Is it correct? What i= f the request to RR conflict with what RR’s own computation from all = other routers?

 

 

For the following text (3.1.3): Are you = trying to make RR dictate routes within one AS with explicit commands, &nbs= p;but not via changing RIB?

“RR can = compute the routes for every router and install/distribute the routes to co= rresponding routers”

 

 

For the second case on PCE, are you suggesting using= PCEP to control router’s FIB?

 

Thanks, Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645BFB79Fdfweml509mbxchi_-- From jclarke@cisco.com Sat Nov 2 16:20:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E518321E811B for ; Sat, 2 Nov 2013 16:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-vC8jMaddSD for ; Sat, 2 Nov 2013 16:20:38 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7311E8241 for ; Sat, 2 Nov 2013 16:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3396; q=dns/txt; s=iport; t=1383434439; x=1384644039; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=MKksbVj9WAMOXNRtx7FrGanK51tVlXQ7gsmrMqMNWzs=; b=PGJN7fFWNPA0qw8ZQLQJB0NyDH0IOlVAY/8PVa1dgNDWtNqEcJS1OBMx AZQn04tHNWKr2QjPMqqJnW+wQZsTPPYqGrP5nt+RliW7PlyjrLW3kpaa1 of6oqt7tmNhh+bxmJym4s1zMRC6XxgDw+DujRZ9KNqPZmM8yW6HDKc1Rj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFAPOHdVKrRDoJ/2dsb2JhbABWA4MHwQmBGxZtB4JkQA8uFhgDAgECAQlCDQYCAQGHfJwXoQwEjguBOSiEHQOYCpIJg0IggTU X-IronPort-AV: E=Sophos;i="4.93,624,1378857600"; d="scan'208";a="96461531" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 02 Nov 2013 23:20:38 +0000 Received: from sjc-vpn6-769.cisco.com (sjc-vpn6-769.cisco.com [10.21.123.1]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA2NKa2J008069 for ; Sat, 2 Nov 2013 23:20:36 GMT Message-ID: <527588C4.5080600@cisco.com> Date: Sat, 02 Nov 2013 19:20:36 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [i2rs] Feedback on draft-rfernando-i2rs-protocol-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 23:20:44 -0000 Thanks for putting this draft together. I have a few comments below. Section 2: Along with Joel, I find the terminology a bit strange given the existing content of I2RS. Is "Server" in this context an I2RS Agent? Or is the Server a bigger thing that can implement, among other things, an I2RS Agent? Or is this more of an abstract thing? I think perhaps in the context of I2RS, existing terminology should be used. Nit: In the definition of Service you have, "...together with the policies that control it's usage." This should be "its usage." Section 3: One HLO for me is serviceability (or traceability). That is, I2RS should be designed in a way so that one can understand what Clients affected what Agent state and when. It would be good to see some of the requirements from draft-clarke-i2rs-traceability folded in on that front (yes, shameless plug). Section 4.1: Here is where Agent should be used over Server to be consistent with existing I2RS terminology. In your GEN requirements, you call out that the client initiates a connection to the server. Okay. However, what about notifications? They should be covered as part of the general protocol requirements. This would reverse the flow of the "connection" (if there is a connection for notifications). I agree with Joel that GEN-3 and TR-4 seem to contradict each other. But I think that the server/Agent can initiate a transport session for notifications. I'm not sure I see where TR-11 fits into I2RS exactly. I don't recall seeing where I2RS needs to deal with dataplane manipulation. Concerning TR-12, there was a lengthy discussion over using a persistent connection. There are other ways to determine if an Agent has failed (which is what was concluded from the thread). However, if you're saying that a participant only needs to be aware if the current, transient connection fails, I agree. A reliable protocol should give you that. ID-8 sounds weird to me. I would imagine this would just happen if the state is associated to a particular client. I'm not sure it needs to be stated. Nit: In ME-6, I think IDL should be defined. In MEP-3, why wouldn't a Server acknowledge a Client request? Are you saying the Server may die or timeout? Nit: In PS-2, "applications responsibility" should be "application's responsibility." PS-4 seems to interfere with ME-9. They don't contradict per se, but it seems like if there SHOULD be a binary protocol, why have a human readable one? I guess what I'm saying is taken with ME-7, maybe a binary protocol isn't needed if a human-readble one can be made to adhere to the spirit of ME-7. PS-11 points to not needing persistent connections. However, how will notifications be done to these clients? This has been the cause of some debate on the list. Perhaps the requirements should spell something out. Maybe the clients register a callback with the agent to receive the fire-and-forget notifications. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From zhuangshunwan@huawei.com Sun Nov 3 18:02:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD7421E80B8 for ; Sun, 3 Nov 2013 18:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giFe15IYSEw8 for ; Sun, 3 Nov 2013 18:02:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9443721E8120 for ; Sun, 3 Nov 2013 18:01:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXM91460; Mon, 04 Nov 2013 02:01:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Nov 2013 02:01:20 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Nov 2013 02:01:51 +0000 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Nov 2013 10:01:37 +0800 From: Zhuangshunwan To: "'Linda Dunbar'" , , "'Jixiaofeng (Steven)'" , , "'Huangtieying'" References: <4A95BA014132FF49AE685FAB4B9F17F645BFB79F@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BFB79F@dfweml509-mbx.china.huawei.com> Date: Mon, 4 Nov 2013 10:01:37 +0800 Message-ID: <000001ced901$cc166ee0$64434ca0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CED944.DA39AEE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7XVJxDbsF9exUPTyaNCqe2LyfcmwBqvtNQ Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Subject: Re: [i2rs] [I2RS] Questions to draft-ji-i2rs-usecases-ccne-service-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 02:02:18 -0000 ------=_NextPart_000_0001_01CED944.DA39AEE0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Linda, =20 Please see inline below. =20 Regards, ShunWan =20 =B7=A2=BC=FE=C8=CB: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C22=C8=D5 6:49 =CA=D5=BC=FE=C8=CB: i2rs@ietf.org; Jixiaofeng (Steven); Zhuangshunwan =D6=F7=CC=E2: Questions to draft-ji-i2rs-usecases-ccne-service-00 =20 Xiao Feng and ShunWan,=20 =20 draft-ji-i2rs-usecases-ccne-service-00 provides some interesting use = cases for I2RS.=20 =20 For the first case =A1=B0Controlling Path by RR=A1=B1, are you proposing = interfaces to RR router? Is it correct? What if the request to RR conflict with = what RR=A1=AFs own computation from all other routers?=20 ShunWan=A3=BA Yes, we=A1=AFre proposing interfaces to RR router. If have conflict, RR = should follow the require from controller. Section 3.1 =A1=AD To assist network operators in addressing this challenge, we present some I2RS RR use case, introduce a set of I2RS programmatic APIs for RR that allows a network operator to flexibly control routing between the traffic ingresses and egresses within an ISP's network. =20 =20 For the following text (3.1.3): Are you trying to make RR dictate routes within one AS with explicit commands, but not via changing RIB? =A1=B0RR can compute the routes for every router and install/distribute = the routes to corresponding routers=A1=B1 =20 ShunWan=A3=BAYes. For example, for a path from Source 1 (S1) to Destination 1 (D1), if the computed path is: S1-A-B-C-D1, then the RR will distribute a route (D1) to C with the nexthop set to D1; a route (D1) to B with the nexthop set to C, and a route (D1) to A with the nexthop set to B, and finally the route (D1) will be distributed to S1 by A. =20 +-------------------+ | APP or Controller | +-------------------+ | [Interface for control ip forward network path] | ---- / \ | RR | \ / /-+-\ / | \ / | \ / +--+-+ \ +--+-+/| | B | +--+-+ Source 1---| A | | +----+ | C |--- Destination 1 \ /+----+ | +----+\ / * +---+----+-------+ * / \+--+-+ | +-+--+/ \ Source 2---| D | +--+-+ | F |--- Destination 2 +----+ | E | +----+ +----+ Figure 2: Route Reflection based Traffic Steering (RRTS) =20 For the second case on PCE, are you suggesting using PCEP to control router=A1=AFs FIB?=20 =20 Thanks, Linda ------=_NextPart_000_0001_01CED944.DA39AEE0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Linda,

 

Please see = inline below.

 

Regards,

ShunWan

 

=B7=A2=BC=FE=C8=CB: Linda Dunbar = [mailto:linda.dunbar@huawei.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2013=C4=EA11=D4=C22=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: i2rs@ietf.org; Jixiaofeng = (Steven); Zhuangshunwan
=D6=F7=CC=E2: Questions to = draft-ji-i2rs-usecases-ccne-service-00

=

 

Xiao Feng and ShunWan,

 

draft-ji-i2rs-usecases-ccne-service-00 provides some = interesting use cases for I2RS.

 

For the first case = =A1=B0Controlling Path by RR=A1=B1, are you proposing interfaces to RR = router?  Is it correct? What if the request to RR conflict with = what RR=A1=AFs own computation from all other routers? =

ShunWan=A3=BA

Yes, = we=A1=AFre proposing interfaces to RR router.  If have conflict, RR = should follow the require from controller.

Section = 3.1

=A1=AD

To assist network operators in addressing this = challenge, we

   present some I2RS RR = use case, introduce a set of I2RS programmatic

   APIs for RR that allows a network = operator to flexibly control

   routing between the traffic = ingresses and egresses within an ISP's

   network.

 

 

For the = following text (3.1.3): Are you trying to make RR dictate routes within = one AS with explicit commands,  but not via changing = RIB?

=A1=B0RR can compute the routes for every router and = install/distribute the routes to corresponding = routers=A1=B1

 

ShunWan=A3=BAYes.

   For example, for a = path from Source 1 (S1) to Destination 1 (D1), = if

   the computed path = is: S1-A-B-C-D1, then the RR will distribute a

   route (D1) to C = with the nexthop set to D1; a route (D1) to B = with

   the nexthop set to = C, and a route (D1) to A with the nexthop set to

   B, and finally the = route (D1) will be distributed to S1 by A.

 

     &n= bsp;           &nb= sp;       = +-------------------+

     &n= bsp;           &nb= sp;       | APP or Controller = |

     &n= bsp;           &nb= sp;       = +-------------------+

     &n= bsp;           &nb= sp;           &nbs= p;    |

     &n= bsp;      [Interface for control ip forward = network path]

     &n= bsp;           &nb= sp;           &nbs= p;    |

     &n= bsp;           &nb= sp;           &nbs= p;   ----

     &n= bsp;           &nb= sp;      =         /    = \

     &n= bsp;           &nb= sp;           &nbs= p; |  RR  |

     &n= bsp;           &nb= sp;           &nbs= p;  \    /

     &n= bsp;           &nb= sp;           &nbs= p;  /-+-\

     &n= bsp;           &nb= sp;           &nbs= p; /  |  \

     &n= bsp;           &nb= sp;            = /   |   \

     &n= bsp;           &nb= sp;           / = +--+-+  \

    =             &= nbsp;     +--+-+/| | B  |   = +--+-+

     &n= bsp;     Source 1---| A  | | +----+   = | C  |--- Destination 1

     &n= bsp;           &nb= sp; \ /+----+ |          = +----+\ /

     &n= bsp;           &nb= sp;  *    +---+----+-------+    = *

     &n= bsp;           &nb= sp; / \+--+-+      |     = +-+--+/ \

     &n= bsp;     Source 2---| D  |   = +--+-+   | F  |--- Destination 2

     &n= bsp;           &nb= sp;    +----+   | E  |   = +----+

     &n= bsp;           &nb= sp;           &nbs= p; +----+

     &n= bsp;     Figure 2: Route Reflection based Traffic = Steering (RRTS)

 

For the second case on PCE, are you = suggesting using PCEP to control router=A1=AFs FIB? =

 

Thanks, Linda

------=_NextPart_000_0001_01CED944.DA39AEE0-- From huangtieying@huawei.com Sun Nov 3 18:10:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8911E8271 for ; Sun, 3 Nov 2013 18:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UILLsAj0xUCk for ; Sun, 3 Nov 2013 18:10:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9597511E826D for ; Sun, 3 Nov 2013 18:10:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZU94201; Mon, 04 Nov 2013 02:10:24 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Nov 2013 02:09:46 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 4 Nov 2013 02:10:22 +0000 Received: from nkgeml510-mbs.china.huawei.com ([169.254.4.85]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 4 Nov 2013 10:10:09 +0800 From: Huangtieying To: Zhuangshunwan , Linda Dunbar , "i2rs@ietf.org" , "Jixiaofeng (Steven)" , Yangang Thread-Topic: [I2RS] Questions to draft-ji-i2rs-usecases-ccne-service-00 Thread-Index: Ac7XVJxDbsF9exUPTyaNCqe2LyfcmwBqvtNQAACiBtg= Date: Mon, 4 Nov 2013 02:10:09 +0000 Message-ID: <79EA23FFD17CE645922E0A1D0E4653793CA96B06@nkgeml510-mbs.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BFB79F@dfweml509-mbx.china.huawei.com>, <000001ced901$cc166ee0$64434ca0$@com> In-Reply-To: <000001ced901$cc166ee0$64434ca0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.59] Content-Type: multipart/alternative; boundary="_000_79EA23FFD17CE645922E0A1D0E4653793CA96B06nkgeml510mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [i2rs] =?gb2312?b?tPC4tDogW0kyUlNdIFF1ZXN0aW9ucyB0byBkcmFmdC1q?= =?gb2312?b?aS1pMnJzLXVzZWNhc2VzLWNjbmUtc2VydmljZS0wMA==?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 02:10:52 -0000 --_000_79EA23FFD17CE645922E0A1D0E4653793CA96B06nkgeml510mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGluZGEsDQoNCiAgICBGb3IgUENFIGNhc2UsIFBDRVAgcHJvdG9jb2wgaXMgdXNlZCBmb3Ig Y29tbXVuaWNhdGlvbnMgYmV0d2VlbiBhIFBDQyBhbmQgYSBQQ0UsIG9yIGJldHdlZW4gdHdvIFBD RXMsIGluIG9tcGxpYW5jZSB3aXRoIFJGQyA0NjU3LCBTdWNoIGludGVyYWN0aW9ucyBpbmNsdWRl IHBhdGggY29tcHV0YXRpb24gcmVxdWVzdHMgYW5kIHBhdGggY29tcHV0YXRpb24gcmVwbGllcyBh cyB3ZWxsIGFzIG5vdGlmaWNhdGlvbnMgb2Ygc3BlY2lmaWMgc3RhdGVzIHJlbGF0ZWQgdG8gdGhl IHVzZSBvZiBhIFBDRSBpbiBNUExTIGFuZCBHTVBMUyBURS4NCg0KUmVnYXJkcywNClRpZVlpbmcN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCreivP7IyzogWmh1YW5nc2h1bndh bg0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MI0yNUgMTA6MDENCsrVvP7IyzogTGluZGEgRHVuYmFyOyBp MnJzQGlldGYub3JnOyBKaXhpYW9mZW5nIChTdGV2ZW4pOyBZYW5nYW5nOyBIdWFuZ3RpZXlpbmcN Ctb3zOI6IFJlOiBbSTJSU10gUXVlc3Rpb25zIHRvIGRyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2Nu ZS1zZXJ2aWNlLTAwDQoNCkxpbmRhLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBiZWxvdy4NCg0KDQpS ZWdhcmRzLA0KDQpTaHVuV2FuDQoNCreivP7IyzogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEu ZHVuYmFyQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjLI1SA2OjQ5DQrK1bz+yMs6 IGkycnNAaWV0Zi5vcmc7IEppeGlhb2ZlbmcgKFN0ZXZlbik7IFpodWFuZ3NodW53YW4NCtb3zOI6 IFF1ZXN0aW9ucyB0byBkcmFmdC1qaS1pMnJzLXVzZWNhc2VzLWNjbmUtc2VydmljZS0wMA0KDQpY aWFvIEZlbmcgYW5kIFNodW5XYW4sDQoNCmRyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2NuZS1zZXJ2 aWNlLTAwIHByb3ZpZGVzIHNvbWUgaW50ZXJlc3RpbmcgdXNlIGNhc2VzIGZvciBJMlJTLg0KDQpG b3IgdGhlIGZpcnN0IGNhc2UgobBDb250cm9sbGluZyBQYXRoIGJ5IFJSobEsIGFyZSB5b3UgcHJv cG9zaW5nIGludGVyZmFjZXMgdG8gUlIgcm91dGVyPyAgSXMgaXQgY29ycmVjdD8gV2hhdCBpZiB0 aGUgcmVxdWVzdCB0byBSUiBjb25mbGljdCB3aXRoIHdoYXQgUlKhr3Mgb3duIGNvbXB1dGF0aW9u IGZyb20gYWxsIG90aGVyIHJvdXRlcnM/DQpTaHVuV2Fuo7oNClllcywgd2Whr3JlIHByb3Bvc2lu ZyBpbnRlcmZhY2VzIHRvIFJSIHJvdXRlci4gIElmIGhhdmUgY29uZmxpY3QsIFJSIHNob3VsZCBm b2xsb3cgdGhlIHJlcXVpcmUgZnJvbSBjb250cm9sbGVyLg0KU2VjdGlvbiAzLjENCqGtDQpUbyBh c3Npc3QgbmV0d29yayBvcGVyYXRvcnMgaW4gYWRkcmVzc2luZyB0aGlzIGNoYWxsZW5nZSwgd2UN CiAgIHByZXNlbnQgc29tZSBJMlJTIFJSIHVzZSBjYXNlLCBpbnRyb2R1Y2UgYSBzZXQgb2YgSTJS UyBwcm9ncmFtbWF0aWMNCiAgIEFQSXMgZm9yIFJSIHRoYXQgYWxsb3dzIGEgbmV0d29yayBvcGVy YXRvciB0byBmbGV4aWJseSBjb250cm9sDQogICByb3V0aW5nIGJldHdlZW4gdGhlIHRyYWZmaWMg aW5ncmVzc2VzIGFuZCBlZ3Jlc3NlcyB3aXRoaW4gYW4gSVNQJ3MNCiAgIG5ldHdvcmsuDQoNCg0K Rm9yIHRoZSBmb2xsb3dpbmcgdGV4dCAoMy4xLjMpOiBBcmUgeW91IHRyeWluZyB0byBtYWtlIFJS IGRpY3RhdGUgcm91dGVzIHdpdGhpbiBvbmUgQVMgd2l0aCBleHBsaWNpdCBjb21tYW5kcywgIGJ1 dCBub3QgdmlhIGNoYW5naW5nIFJJQj8NCqGwUlIgY2FuIGNvbXB1dGUgdGhlIHJvdXRlcyBmb3Ig ZXZlcnkgcm91dGVyIGFuZCBpbnN0YWxsL2Rpc3RyaWJ1dGUgdGhlIHJvdXRlcyB0byBjb3JyZXNw b25kaW5nIHJvdXRlcnOhsQ0KDQpTaHVuV2Fuo7pZZXMuDQogICBGb3IgZXhhbXBsZSwgZm9yIGEg cGF0aCBmcm9tIFNvdXJjZSAxIChTMSkgdG8gRGVzdGluYXRpb24gMSAoRDEpLCBpZg0KICAgdGhl IGNvbXB1dGVkIHBhdGggaXM6IFMxLUEtQi1DLUQxLCB0aGVuIHRoZSBSUiB3aWxsIGRpc3RyaWJ1 dGUgYQ0KICAgcm91dGUgKEQxKSB0byBDIHdpdGggdGhlIG5leHRob3Agc2V0IHRvIEQxOyBhIHJv dXRlIChEMSkgdG8gQiB3aXRoDQogICB0aGUgbmV4dGhvcCBzZXQgdG8gQywgYW5kIGEgcm91dGUg KEQxKSB0byBBIHdpdGggdGhlIG5leHRob3Agc2V0IHRvDQogICBCLCBhbmQgZmluYWxseSB0aGUg cm91dGUgKEQxKSB3aWxsIGJlIGRpc3RyaWJ1dGVkIHRvIFMxIGJ5IEEuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgICB8IEFQUCBvciBDb250cm9sbGVyIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgICAgICAgICBbSW50ZXJmYWNlIGZvciBjb250cm9sIGlwIGZvcndhcmQgbmV0d29yayBwYXRo XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tLS0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyAg ICBcDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgUlIgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgXCAgICAvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8tKy1cDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyAgfCAgXA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLyAgIHwgICBcDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC8gKy0tKy0rICBcDQogICAgICAgICAgICAgICAgICAgICAgKy0tKy0rL3wgfCBCICB8 ICAgKy0tKy0rDQogICAgICAgICAgIFNvdXJjZSAxLS0tfCBBICB8IHwgKy0tLS0rICAgfCBDICB8 LS0tIERlc3RpbmF0aW9uIDENCiAgICAgICAgICAgICAgICAgICBcIC8rLS0tLSsgfCAgICAgICAg ICArLS0tLStcIC8NCiAgICAgICAgICAgICAgICAgICAgKiAgICArLS0tKy0tLS0rLS0tLS0tLSsg ICAgKg0KICAgICAgICAgICAgICAgICAgIC8gXCstLSstKyAgICAgIHwgICAgICstKy0tKy8gXA0K ICAgICAgICAgICBTb3VyY2UgMi0tLXwgRCAgfCAgICstLSstKyAgIHwgRiAgfC0tLSBEZXN0aW5h dGlvbiAyDQogICAgICAgICAgICAgICAgICAgICAgKy0tLS0rICAgfCBFICB8ICAgKy0tLS0rDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0rDQogICAgICAgICAgIEZpZ3VyZSAy OiBSb3V0ZSBSZWZsZWN0aW9uIGJhc2VkIFRyYWZmaWMgU3RlZXJpbmcgKFJSVFMpDQoNCkZvciB0 aGUgc2Vjb25kIGNhc2Ugb24gUENFLCBhcmUgeW91IHN1Z2dlc3RpbmcgdXNpbmcgUENFUCB0byBj b250cm9sIHJvdXRlcqGvcyBGSUI/DQoNClRoYW5rcywgTGluZGENCg== --_000_79EA23FFD17CE645922E0A1D0E4653793CA96B06nkgeml510mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

    For PCE case= , PCEP protocol is used for communications between a PCC and a PCE, or betw= een two PCEs, in ompliance with RFC 4657, Such interactions include path co= mputation requests and path computation replies as well as notifications of specific states related to the use of a PCE in MP= LS and GMPLS TE.

 

Regards,

TieYing

=B7=A2=BC=FE=C8=CB: Zhuangshunwan
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C24=C8=D5 10:01
=CA=D5=BC=FE=C8=CB: Linda Dunbar; i2rs@ietf.org; Jixiaofeng (Steven)= ; Yangang; Huangtieying
=D6=F7=CC=E2: Re: [I2RS] Questions to draft-ji-i2rs-usecases-ccne-se= rvice-00

Linda,=

 

Please= see inline below.

 

Reg= ards,

Shu= nWan

 

=B7=A2=BC=FE=C8=CB: Linda D= unbar [mailto:linda.dunbar@huawei.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C22=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: i2rs@ietf.org; Jixiaofeng (Steven); Zhuangshunwan
=D6=F7=CC=E2: Questions to draft-ji-i2rs-usecases-ccne-service-00

 

Xiao Feng and ShunWan, <= /p>

 

draft-ji-i2rs-usecases-ccne-ser= vice-00 provides some interesting use cases for I2RS.

 

For the first case =A1=B0Contro= lling Path by RR=A1=B1, are you proposing interfaces to RR router?  Is= it correct? What if the request to RR conflict with what RR=A1=AFs own com= putation from all other routers?

ShunWa= n=A3=BA

Yes, w= e=A1=AFre proposing interfaces to RR router.  If have conflict, RR sho= uld follow the require from controller.

Sectio= n 3.1

=A1=AD

To assist network operators in addressing this chall= enge, we

 =   present some I2RS RR use case, introduce a set of I2RS programmatic<= /span>

 =   APIs for RR that allows a network operator to flexibly control

 =   routing between the traffic ingresses and egresses within an ISP's

 =   network.

 

 

For the following text (3.1.3): Are you tryi= ng to make RR dictate routes within one AS with explicit commands,  bu= t not via changing RIB?

=A1= =B0RR can compute the routes for every router and install/distribute the ro= utes to corresponding routers=A1=B1

 

ShunWa= n=A3=BAYes.

   For example, for a path from Source 1 (S1) to Des= tination 1 (D1), if

   the computed path is: S1-A-B-C-D1, then the RR wi= ll distribute a

   route (D1) to C with the nexthop set to D1; a rou= te (D1) to B with

   the nexthop set to C, and a route (D1) to A with = the nexthop set to

   B, and finally the route (D1) will be distributed= to S1 by A.

 

          &n= bsp;            = ;  +-------------------+

          &n= bsp;            = ;  | APP or Controller |

          &n= bsp;            = ;  +-------------------+

          &n= bsp;            = ;           |

          &n= bsp; [Interface for control ip forward network path]

          &n= bsp;            = ;           |

          &n= bsp;            = ;          ----

          &n= bsp;            = ;         /    \

          &n= bsp;            = ;        |  RR  |

          &n= bsp;            = ;         \    /

          &n= bsp;            = ;         /-+-\

          &n= bsp;            = ;        /  |  \

          &n= bsp;            = ;       /   |   \<= /p>

          &n= bsp;            = ;      / +--+-+  \

           &= nbsp;          +--= 3;-+/| | B  |   +--+-+

           S= ource 1---| A  | | +----+   | C  |--- Destinati= on 1

          &n= bsp;        \ /+----+ | &nb= sp;        +----+\ /

          &n= bsp;         *    &#= 43;---+----+-------+    *

          &n= bsp;        / \+--+-+ &= nbsp;    |     +-+--+/ \

           S= ource 2---| D  |   +--+-+   | F  = |--- Destination 2

          &n= bsp;           +----&= #43;   | E  |   +----+

          &n= bsp;            = ;        +----+

           F= igure 2: Route Reflection based Traffic Steering (RRTS)

 

For the second case on PCE, are= you suggesting using PCEP to control router=A1=AFs FIB?

 

Thanks, Linda

--_000_79EA23FFD17CE645922E0A1D0E4653793CA96B06nkgeml510mbschi_-- From akatlas@gmail.com Mon Nov 4 22:22:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8215011E8196 for ; Mon, 4 Nov 2013 22:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CACZAFAFSCM4 for ; Mon, 4 Nov 2013 22:22:18 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 041CD11E8182 for ; Mon, 4 Nov 2013 22:22:10 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so14223501iec.41 for ; Mon, 04 Nov 2013 22:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JP68zaCNfmXgE4EKqlOeU3t3uz+Vh64/ACzrXyMQeT4=; b=NlYtEeLdE9phYOSFHieXRUej5M1wZqS4NbIKBczBLu5X/lZgksuR+9UCK2vOEnBfFu eE/kleqTrGWy4VMdEeZK0WDT8YtOJwHwPICfXbQNPvEs29h3EXKwJ9XDj5wb07+F3CoQ P7LwIOLlCvo6i48eyuB03gdnGrMoGduuRImqnlUbmZJ6L+ldExffKVkKQqSsYT4JrH9L 99Chsz7hTR94NNqnewEkENhP2qz5JPB/RoxTSIo3wofUrfjn2+sIg6yWNTj5YZuHVpuy azW/3kDIeE+1v3a2QgMOaBRB/BrM3PbW/uGqu7F0fIEQGtC2XJI5BqNFMtgbhhvW+GIB Ptwg== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr14309328igh.5.1383632530492; Mon, 04 Nov 2013 22:22:10 -0800 (PST) Received: by 10.64.78.103 with HTTP; Mon, 4 Nov 2013 22:22:10 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Nov 2013 01:22:10 -0500 Message-ID: From: Alia Atlas To: KwangKoog Lee Content-Type: multipart/alternative; boundary=047d7bdc9db27ad50d04ea680d43 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 5: Client Redundancy X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 06:22:19 -0000 --047d7bdc9db27ad50d04ea680d43 Content-Type: text/plain; charset=ISO-8859-1 Hi Kwang-koog, I apologize for the long delay in responding. On Fri, Oct 4, 2013 at 5:14 AM, KwangKoog Lee wrote: > Hi Alia. This is Kwang-koog from KT. > > I checked many opinions from i2rs experts about the client redundancy. > Thanks for very meaningful discussion to more advance i2rs. > > From service provider perspective, active/standby operation of network > elements through dualization is mandatory for reliable operation from any > failure. So, I am welcoming for the addition of the client redundancy part. > Thank you. > > Regarding to this, I ask you something for clarifying the understanding of > the i2rs architecture :-) > > As seen in Figure 1 of the architure document, a network application has > to have a client? Or multiple network applications can attach to a single > client. Referring to Sec. 4, an I2RS client can interact with multiple > network applications. The next question is that network applications and > client can be physically separated? > Yes, the architecture supports both models. Either the network application has the I2RS client as part of itself (basically a library or the like) or the network application could talk via some protocol to an I2RS client. > Additionally, in Sec. 6.5 Connectivity, you state that "There are three > different assumptions that can apply to handling dead clients. The first is > that the network applicaions or management systems will detect a dead > network application and iether restart that network application ....". > Network applications can check the status of other network applications > each other? What is the management system? The first sentence is saying the > handling of dead clients, but the second sentence says the dead network > application. I want to cleary understand those matters. > The idea here is that there is some monitoring capability to determine that a application has failed - that could be the network application with an I2RS client, a network application without an I2RS client, or the standalone I2RS client. This could probably use some clean-up in the text. > Those might be simple questions for you. If so, appologize my lack of > comprehension :p > Not at all! This is how we get a better and clearer draft. Thanks, Alia > Thank you in advance and I also appreciate your efforts for i2rs. > Bye. > > best regards, > Kwang-koog Lee > > > On Thu, Sep 12, 2013 at 11:59 PM, Alia Atlas wrote: > >> In draft-ietf-i2rs-architecture-00 Sec 6.4.1: >> >> "I2RS must support client redundancy. At the simplest, this can be >> >> handled by having a primary and a backup network application that >> both use the same client identity and can successfully authenticate >> as such. Since I2RS does not require a continuous transport >> connection and supports multiple transport sessions, this can provide >> some basic redundancy. However, it does not address concerns for >> >> troubleshooting and accountability about knowing which network >> application is actually active. At a minimum, basic transport >> information about each connection and time can be logged with the >> identity. Further discussion is necessary to determine whether >> additional client identification information is necessary.[[Editor's >> note: This requires more discussion in the working group.]]" >> >> >> I would like to start this discussion. During and after the Berlin IETF, there >> >> was significant discussion on the list. I tried to capture the ideas that were >> >> expressed then. Is what is in the draft now sufficient? How should it be improved >> >> upon? >> >> >> Thanks, >> >> Alia (WG-Chair hat off) >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > --047d7bdc9db27ad50d04ea680d43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kwang-koog,

I apologize for the long= delay in responding.


On Fri, Oct 4, 2013 at 5:14 AM, KwangKoog Lee <kwang= kooglee@gmail.com> wrote:
Hi Alia. This is Kwang= -koog from KT.
=A0
I=A0checked many opinions=A0from i2r= s=A0experts=A0about the client redundancy.
Thanks for very meaningful discussion=A0to more=A0advance=A0i2rs.=A0
=A0
From service provider perspective,=A0active/standby oper= ation of network elements through dualization=A0is=A0mandatory=A0for reliab= le operation from=A0any failure. So,=A0I am welcoming=A0for the=A0addition = of the client redundancy part. Thank you.
=A0
Regarding to this, I=A0ask you something for clarifying = the understanding of the i2rs architecture=A0:-)
=A0
As= seen in Figure 1 of the architure document, a network application=A0has to= have a client?=A0Or multiple=A0network applications can attach=A0to a sing= le client. Referring to Sec. 4, an I2RS client can interact with multiple n= etwork applications.=A0The next question is that=A0network applications and= client can be physically separated?

Yes, the architecture sup= ports both models. =A0Either the network application has the I2RS client as= part of itself (basically a library or the like) or the network applicatio= n could talk via some protocol =A0to an I2RS client.
=A0
=A0Addit= ionally, in Sec. 6.5 Connectivity, you state that=A0"There are three d= ifferent assumptions that can apply to handling dead clients. The first is = that the network applicaions or management systems will detect a dead netwo= rk application and iether restart that network application ....".
Network applications=A0can check the status of other network applicati= ons each other? What is the management system? The first sentence is saying= the handling of dead clients, but the second sentence says the dead networ= k application. I want to cleary understand those matters.

The idea here is that there is some = monitoring capability to determine that a application has failed - that cou= ld be the network application with an I2RS client, a network application wi= thout an I2RS client, or the standalone I2RS client. =A0This could probably= use some clean-up in the text.
=A0
=A0Those might be simple questions for you. If so, appologize my lack = of comprehension :p

Not at all!= =A0This is how we get a better and clearer draft.

Thanks,
Alia
=A0
Thank you in advance and I=A0also appreciate=A0your eff= orts for i2rs.
Bye.
=A0
best regards,
Kwang-koog Lee

=A0
On Thu, Sep 12, 2013 at 11:59 = PM, Alia Atlas <akatlas@gmail.com> wrote:
In draft-ietf-i2rs-architecture-00 Se= c 6.4.1:

"I2RS must support client red= undancy. At the simplest, this can be
   handled by having a primary and a backup network applic=
ation that
   both use the same client identity and can successfully authenticate
   as such.  Since I2RS does not require a continuous transport
   connection and supports multiple transport sessions, this can provide
   some basic redundancy.  However, it does not address concerns for

   troubleshooting and accountability ab=
out knowing which network
   application is actually active.  At a minimum, basic transport
   information about each connection and time can be logged with the
   identity.  Further discussion is necessary to determine whether
   additional client identification information is necessary.[[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion.  During and after the Berlin IETF, there
was significant discussion on the list.  I tried to capture the ideas th=
at were
expressed then.  Is what is in the draft now sufficient?  =
How should it be improved
upon?

Thanks,
Alia (WG-Chair hat off)

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--047d7bdc9db27ad50d04ea680d43-- From akatlas@gmail.com Tue Nov 5 01:08:03 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C0A21E80D3 for ; Tue, 5 Nov 2013 01:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4LR59-bIoqa for ; Tue, 5 Nov 2013 01:07:55 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCD221E809C for ; Tue, 5 Nov 2013 01:07:54 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id ar20so14880547iec.0 for ; Tue, 05 Nov 2013 01:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cG8DyYsDrk3/UEhvmmfP05bCHTRCWKE4vtavCsw8IT4=; b=o+vTTaJiDcgh1Y596qIDgY7u8yrxW9ihS85JvEvTHt/ZEnT0pE7orqn2GIxS7SqSfK 8icdLY1OybcEJNdxEcjyI9T30yNV1aAC2+QV7b+IrLe2MrNBI2mWKI+uYF7aeI+gyQSK 2+qhXV90inJfoTHiWpX66WMAxJASKWR2jbT4eCT3FE/VL3R5XjlXGsxsvxA24cCCTNl5 jOwdWzuRAEe017oALLvIt6XErbXBJ3qW4MysdXP5yx0A3N/Ut4Sk3Fiu1OKcOAAdhoIN xKwbQe1cpeIEacVz5jAq7ZwF37wrLzZWmUAGY2YlD5LKt2nW/kFNEQ36OIIEFbP0ru7p EJnw== MIME-Version: 1.0 X-Received: by 10.42.92.84 with SMTP id s20mr12405icm.63.1383642470542; Tue, 05 Nov 2013 01:07:50 -0800 (PST) Received: by 10.64.78.103 with HTTP; Tue, 5 Nov 2013 01:07:50 -0800 (PST) Date: Tue, 5 Nov 2013 04:07:50 -0500 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" , draft-rfernando-i2rs-protocol-requirements@tools.ietf.org Content-Type: multipart/alternative; boundary=90e6ba614f0ef3fae404ea6a5d94 Subject: [i2rs] some comments on draft-rfernando-i2rs-protocol-requirements-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 09:08:04 -0000 --90e6ba614f0ef3fae404ea6a5d94 Content-Type: text/plain; charset=ISO-8859-1 (WG-chair hat off) Hi Jan, Rex, Ed, and Keyur, " GEN-3: The client and the server communicate using a simple transport connection. The client initiates the transport connection to the server. The server does not know the number and timing of the connections from its clients." I have two comments here. First, I think that the client and agent can communicate over more than one transport connection. Second, the agent can need to initiate a transport connection to the client if one doesn't exist and a notification is required. "GEN-5: The I2RS MUST define a data model to describe the SDMs supported in the server and MUST define a data modeling language to formally describe that data model. I2RS MUST specify the mapping from the service data model to the message data model and subsequently to the client API." This is interesting. We haven't discussed standardizing a client API. I am curious about the motivations and what the opinion of the WG (and our esteemed ADs) is. "TR-4: A client could connect to multiple servers. Similarly, a server could accept connections from multiple clients. Any participant may initiate the transport connection." Doesn't this contradict GEN-3? "TR-7: Point-to-multipoint transports are mainly used to scale the system by avoiding ingress replication when the same message has to be delivered to multiple receivers. P2MP transport would work hand-in-hand with a P2MP MEP. The subject of P2MP transport and P2MP MEP is for future work." The primary use I see for P2MP transport is to support a pub/sub model for information streams. While I understand that it may add complexity, I am interested in the specific reasons that you think it is ok to put it as future work. What gaps would not having cause and when would that work be done? "TR-9: After the transport is established, the participants exchange capabilities and other session parameters before exchanging service related messages." This presupposes that a transport session stays up or that the overhead of exchanging capabilities and such beforehand is low. In the case, say, of an agent sending a notification to a client, that seems very heavyweight. I certainly agree that we need to think about capabilities and other session parameters - but, at a minimum, there should be a very simple, fast and quick way to exchange a "nothing changed" or "capability summary" if this were to be required. "TR-12: For operational reasons, a participant MUST be able to detect a transport connection failure. To satisfy this requirement, transport level keep-alives could be used. If the underlying transport connection does not provide a keep-alive mechanism, it should be provided at the I2RS protocol level. For example, if TCP is used as a transport, TCP keep-alives could be used to detect transport session failures." Why? Transport keep-alives - much less at the I2RS level - just seem to decrease scalability and increase work. I'd much rather see the operational reasons articulated so they can be discussed. " ID-2: The server should use the client's identity to track state provided by the client. State ownership enables multiple clients to edit their shared state. This is useful for troubleshooting and during client death or disconnection when the client's state may have to be purged or delegated to another client that shares the same identity." Can you clarify what you mean by multiple clients having shared state? What use-cases require this? How are different clients identified if not by their identity? " ID-5: A clients ability to operate on a state held by the server is expressed at the granularity of a service. A service could be read-only or read-write by a client possessing a particular identity." This I emphatically disagree with. I understand that it is a lovely simplification - but I don't think that it meets realistic operational policy requirements. For instance, can any client that might want to write a single route into the RIB service be allowed to modify any route?? " ID-7: A client can edit (write, delete) only the state that was injected by it or other clients with the same shared identity. Therefore, two conditions must be met for a client to edit a state through a session. First, the client should receive capability from the server that it has 'edit' permissions for the service in question, and, secondly, the state that it edits should be its own state." This conflicts with the I2RS Architecture where, for error cases, state might be preempted by another client with a higher priority. What is articulated here gives a time-based ownership which can lead to unpredictability. "ID-8: The server retains the client's identity till all of that client's state is purged from the server." I would clarify at least that all the client registrations (i.e. for events and info streams) must also be gone. Also, for faster verification, capability exchanges, etc., there are advantages to holding on to authenticated clients' identities. "MEP-1: I2RS defines three types of messages between the client and the server. First, capabilities need to be exchanged on session establishment. Second, API commands are sent from a client to a server to add, delete, modify and query state. And third, asynchronous notifications are sent from a server to a client when interesting state changes occur." What about information streams? "MEP-4: The response message in a request-response MEP SHOULD indicate that the server has received the message, done some basic sanity checking on its contents and has accepted the message. The arrival of a response does not mean all post processing of the message has completed." Can you please describe the use-case and need for this requirement? A response indicating an error if the message has problems makes sense to me. Otherwise, why not wait until the operations inside have been completed? What issues are caused by delaying the response and having it indicate that meaningful work has completed? " MEP-6: Error codes SHOULD indicate to the client which layer generated that error (transport, message parsing, schema validation, application level failure, etc). The I2RS framework should specify a standard set of error codes." I think this would be in an I2RS protocol data model. " MEP-7: The request-response messages SHOULD be asynchronous. That is, the client should not be required to stop-and-wait for one message to be acknowledged before it transmits the next request. [ed: there must be a method for dependency tracking in the protocol. possibly negotiate as an optional capability?]" I agree we need to do something about dependency tracking. One possibility is to have multiple operations in the same message to be done in that order. My original concept was to have a start triggered by the completion of another operation. That's been removed from the architecture, of course, but we do need a standard solution. " MEP-13: The fire-and-forget MEP does not carry a message-id but it SHOULD carry a cookie that can be set by the sender and processed by the receiver. The cookie could help the receiver of the message to use the message for its intended purpose." I'm not sure why the fire-and-forget MEP doesn't carry a message-id. I can certainly see having it carry one that, for example, matches to the original subscription request. Unless there's a reason for it not to, I'd tone this down. " API-7: All API methods SHOULD support a batched mode for efficiency purposes. In this mode multiple state entries are transmitted in a single message with a single operation such as add, delete, etc. For methods described in A.1 and A.2 which elicit a response, the failure mechanism that is specific to a subset of state in the batch should be devised. The Notify method SHOULD also support a batched mode." Why do you see a single operation (add, delete, etc) as being in the message? I agree that the the I2RS protocol needs a batched mode - and the architecture describes different behaviors that can be requested. " API-8: Since the API methods are primarily oriented towards state transfer between the client and server, there SHOULD be a identifier (or a key) to uniquely identify the state being addressed." Please clarify. Obviously there's the State data model info to identify the data. Do you mean more/different than this? "API-11: Transactions allow a set of operations to be completed atomically (all or nothing) and that the end result is consistent. Transactions MAY be required for some network applications. [ed: i'd like to remove this for the the first version. it's a bit of a canard']" Are you picturing more than the mechanisms specified in the architecture? I think we'd need pretty strong use-cases and reasoning to support multi-message transactions and the associated complexity. "SVC-8: For every service that it wishes to expose to a client, the server SHOULD send capabilities that indicate the existence and identity of the service data model, as well as valid states and parameter ranges, any exceptions to it and the optional features of the data model that it supports." This doesn't sound particularly lightweight to do frequently. I'm not sure I see the arguments for valid states and parameter ranges - but I'd presume that those are part of the policy authorization. " SVC-17: The server SHOULD indicate to the client the availability of infrastructure to manage the state that it maintains. This includes but is not limited to the availability of persistent store, the availability of timer to clean up state after a specified timeout, the ability to clean up state on the occurrence of an event, etc. Equipped with this information, the client is responsible for the lifetime of the state." Please reread the architecture draft and determine if you are adding persistent store back in. I recall that we'd discussed having an optional timer to clean up state after a specified timeout - but that was when we had an end-time per operation instead of continuing forever. IF that is still needed, then please capture the reasoning and we can discuss it on the mailing list to see if the Architecture needs to add this particular case back in. " SEC-2: Every client MUST have an authorized role whereby only certain state can be accessed and only certain operations can be performed by that client. To keep the model simple and applications portable, authorization MUST be at a per service level and not on individual state element level." I am not convinced that this trivial authorization is sufficient to be used. Obviously, I'd encourage others to provide their perspectives - but I don't see security as something we can just add on later. " SEC-3: The framework MUST provide for information confidentiality and information integrity as options." Do you mean in the default transport connection and the mandatory-to-implement transport? Please clarify - and if not, then how would it be securely added? " PS-6: The transport protocol MUST provide for message prioritization." Could you please explain the reasoning and cases that need this? " PS-8: The server MUST be kept stateless with respect to the number and location of each client." Do you mean that it shouldn't be told about the clients beforehand or that it shouldn't store state about them?? The latter is what I'd interpret stateless to mean - but that makes no sense to me. " PS-10: An efficient synchronization mechanism between a client and a server SHOULD be provided that avoids transferring all the state between them." Please describe the specific scenarios where this exchange is expected to occur??? Then we can see if there are implications to the architecture (if there's agreement on those scenarios). General comment in Sec 4.9: What about, say, not requiring that the agent operate on all messages in order? What about the agent operating on messages from multiple clients at the same time? Those are mechanisms that can improve performance and scale - by taking advantage of multi-threading and so on. I'd like to see more thought and details here, because without requirements like those, I think performance issues are likely. " HA-1: A 'superuser' identity SHOULD be provided that is capable of changing security policies, clearing state and perform actions that override client initiated actions in the system." Hmm, this is interesting. I think that some of this is configuration of policies and data-models. I.e., if we define a data-model for the security policies, then a client with write-scope for that service could modify it. For clearing state and such, the architecture does define a priority to be used as a tie-breaker, but that is considered an error-condition. Is this a sufficiently strong reason that shouldn't be an error condition? There was a strong consensus for the current state. Obviously, one could delete or modify client-initiated actions via non-I2RS mechanisms. " PGM-2: The application once written to certain requirements should be portable to other identical environments. The framework should not have fine grained data access controls as this would lead to a poorly written application with portability issues." I'm confused by why the existence of fine-grained data access controls would lead to portability issues? Can you clarify? General comment on Sec 4.12: I'm delighted to see operational requirements - though some of these seem to be not so much requirements on the protocol (detailed workflow) as specifying the need to do work to think through these aspects (I smell more drafts) so that the protocol and data-model aspects are clearer. Finally, PLEASE do reread draft-ietf-i2rs-architecture, align terminology (or discuss why you loathe it on the list), and consider what should be done about requirements that you have that depended on features in the architecture that have been simplified out. I'm happy to see the updated draft is much improved. Regards, Alia --90e6ba614f0ef3fae404ea6a5d94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(WG-chair hat off)

Hi Jan, Rex, Ed, and= Keyur,

" GEN-3: The client and the server communicate using a = simple transport connection. The client initiates the transport connection = to the server. The server does not know the number and timing of the connec= tions from its clients."

I have two comments here. =A0First, I think that the client and agent c= an communicate over more than one transport connection. =A0Second, the agen= t can need to initiate a transport connection to the client if one doesn= 9;t exist and a notification is required. =A0

"GEN-5: The I2RS MUST define a data model to describe the SDMs sup= ported in the server and MUST define a data modeling language to formally d= escribe that data model. I2RS MUST specify the mapping from the service dat= a model to the message data model and subsequently to the client API."=

This is interesting. =A0We haven't discussed standardizing a client= API. =A0I am curious about the motivations and what the opinion of the WG = (and our esteemed ADs) is.

"TR-4: =A0 A client could connect to= multiple servers. =A0Similarly, a server could accept connections from mul= tiple clients. =A0Any participant may initiate the transport connection.&qu= ot;

Doesn't this contradict GEN-3?

"TR-7: =A0 Point-to-mult= ipoint transports are mainly used to scale the system by avoiding ingress r= eplication when the same message has to be delivered to multiple receivers.= =A0P2MP transport would work hand-in-hand with a P2MP MEP. =A0The subject = of P2MP transport and P2MP MEP is for future work."

The primary use I see for P2MP transport is to support a pub/sub model = for information streams. =A0While I understand that it may add complexity, = I am interested in the specific reasons that you think it is ok to put it a= s future work. =A0What gaps would not having cause and when would that work= be done?

"TR-9: =A0 After the transport is established, the participants ex= change
=A0 =A0 =A0 capabilities and other session parameters before exch= anging
=A0 =A0 =A0 service related messages."


This presu= pposes that a transport session stays up or that the overhead of exchanging= capabilities and such beforehand is low. =A0In the case, say, of an agent = sending a notification to a client, that seems very heavyweight. =A0I certa= inly agree that we need to think about capabilities and other session param= eters - but, at a minimum, there should be a very simple, fast and quick wa= y to exchange a "nothing changed" or "capability summary&quo= t; if this were to be required.


"TR-12: =A0For operational reasons, a participant MUST be able= to detect

=A0 =A0 =A0 a transport connection failure. =A0To satisfy= this requirement,
=A0 =A0 =A0 transport level keep-alives could be used= . =A0If the underlying
=A0 =A0 =A0 transport connection does not provide a keep-alive mechanism, i= t
=A0 =A0 =A0 should be provided at the I2RS protocol level. =A0For exam= ple, if
=A0 =A0 =A0 TCP is used as a transport, TCP keep-alives could be= used to
=A0 =A0 =A0 detect transport session failures."


Why? =A0Transport keep-alives - much less at the I2RS level - just = seem to decrease scalability and increase work. =A0I'd much rather see = the operational reasons articulated so they can be discussed.


&q= uot; =A0 ID-2: =A0The server should use the client's identity to track = state

=A0 =A0 =A0 provided by the client. =A0State ownership enables multiple= clients
=A0 =A0 =A0 to edit their shared state. =A0This is useful for t= roubleshooting
=A0 =A0 =A0 and during client death or disconnection when= the client's state
=A0 =A0 =A0 may have to be purged or delegated to another client that share= s
=A0 =A0 =A0 the same identity."


Can you clarify what y= ou mean by multiple clients having shared state? What use-cases require thi= s? =A0How are different clients identified if not by their identity?


" =A0 ID-5: =A0A clients ability to operate on a state held by= the server is

=A0 =A0 =A0 expressed at the granularity of a service= . =A0A service could be
=A0 =A0 =A0 read-only or read-write by a client = possessing a particular
=A0 =A0 =A0 identity."


This I emphatically disagree with. = =A0I understand that it is a lovely simplification - but I don't think = that it meets realistic operational policy requirements. =A0For instance, c= an any client that might want to write a single route into the RIB service = be allowed to modify any route??


" =A0 ID-7: =A0A client can edit (write, delete) only the stat= e that was

=A0 =A0 =A0 injected by it or other clients with the same= shared identity.
=A0 =A0 =A0 Therefore, two conditions must be met for = a client to edit a state
=A0 =A0 =A0 through a session. =A0First, the client should receive capabili= ty
=A0 =A0 =A0 from the server that it has 'edit' permissions fo= r the service in
=A0 =A0 =A0 question, and, secondly, the state that it = edits should be its own
=A0 =A0 =A0 state."


This conflicts with the I2RS Architectu= re where, for error cases, state might be preempted by another client with = a higher priority. =A0What is articulated here gives a time-based ownership= which can lead to unpredictability.

"ID-8: =A0The server retains the client's identity till all of= that
=A0 =A0 =A0 client's state is purged from the server."

I would clarify at least that all the client registrations (i.e. f= or events and info streams) must also be gone. =A0Also, for faster verifica= tion, capability exchanges, etc., there are advantages to holding on to aut= henticated clients' identities.


"MEP-1: =A0 I2RS defines three types of messages between the c= lient and

=A0 =A0 =A0 the server. =A0First, capabilities need to be = exchanged on session
=A0 =A0 =A0 establishment. =A0Second, API commands = are sent from a client to a
=A0 =A0 =A0 server to add, delete, modify and query state. =A0And third,=A0 =A0 =A0 asynchronous notifications are sent from a server to a client = when
=A0 =A0 =A0 interesting state changes occur."


What = about information streams?


"MEP-4: =A0 The response message in a request-response MEP SHO= ULD
=A0 =A0 =A0 indicate that the server has received the message, done = some basic
=A0 =A0 =A0 sanity checking on its contents and has accepted = the message. =A0The
=A0 =A0 =A0 arrival of a response does not mean all post processing of the<= br>=A0 =A0 =A0 message has completed."


Can you please descr= ibe the use-case and need for this requirement? =A0A response indicating an= error if the message has problems makes sense to me. =A0Otherwise, why not= wait until the operations inside have been completed? =A0What issues are c= aused by delaying the response and having it indicate that meaningful work = has completed?


" =A0 MEP-6: =A0 Error codes SHOULD indicate to the client whi= ch layer

=A0 =A0 =A0 generated that error (transport, message parsin= g, schema
=A0 =A0 =A0 validation, application level failure, etc). =A0Th= e I2RS framework
=A0 =A0 =A0 should specify a standard set of error codes."


= I think this would be in an I2RS protocol data model.


" =A0= MEP-7: =A0 The request-response messages SHOULD be asynchronous. =A0That
=A0 =A0 =A0 is, the client should not be required to stop-and-wait fo= r one
=A0 =A0 =A0 message to be acknowledged before it transmits the next request= .
=A0 =A0 =A0 [ed: there must be a method for dependency tracking in the=
=A0 =A0 =A0 protocol. =A0possibly negotiate as an optional capability?]= "


I agree we need to do something about dependency tracking. =A0One possibili= ty is to have multiple operations in the same message to be done in that or= der. =A0My original concept was to have a start triggered by the completion= of another operation. That's been removed from the architecture, of co= urse, but we do need a standard solution.


" =A0 MEP-13: =A0The fire-and-forget MEP does not carry a mess= age-id but it
=A0 =A0 =A0 SHOULD carry a cookie that can be set by the s= ender and processed
=A0 =A0 =A0 by the receiver. =A0The cookie could hel= p the receiver of the
=A0 =A0 =A0 message to use the message for its intended purpose."
<= br>
I'm not sure why the fire-and-forget MEP doesn't carry a mes= sage-id. =A0I can certainly see having it carry one that, for example, matc= hes to the original subscription request. =A0Unless there's a reason fo= r it not to, I'd tone this down.


" =A0 API-7: =A0 All API methods SHOULD support a batched mode= for efficiency

=A0 =A0 =A0 purposes. =A0In this mode multiple state= entries are transmitted in
=A0 =A0 =A0 a single message with a single o= peration such as add, delete, etc.
=A0 =A0 =A0 For methods described in A.1 and A.2 which elicit a response, t= he
=A0 =A0 =A0 failure mechanism that is specific to a subset of state i= n the
=A0 =A0 =A0 batch should be devised. =A0The Notify method SHOULD a= lso support a
=A0 =A0 =A0 batched mode."


Why do you see a single operatio= n (add, delete, etc) as being in the message? =A0I agree that the the I2RS = protocol needs a batched mode - and the architecture describes different be= haviors that can be requested. =A0


" =A0 API-8: =A0 Since the API methods are primarily oriented = towards state

=A0 =A0 =A0 transfer between the client and server, th= ere SHOULD be a
=A0 =A0 =A0 identifier (or a key) to uniquely identify t= he state being
=A0 =A0 =A0 addressed."


Please clarify. =A0 Obviously there= 's the State data model info to identify the data. =A0Do you mean more/= different than this?


"API-11: =A0Transactions allow a set o= f operations to be completed

=A0 =A0 =A0 atomically (all or nothing) and that the end result is cons= istent.
=A0 =A0 =A0 Transactions MAY be required for some network applic= ations. =A0[ed:
=A0 =A0 =A0 i'd like to remove this for the the firs= t version. =A0it's a bit of
=A0 =A0 =A0 a canard']"


Are you picturing more than the= mechanisms specified in the architecture? =A0I think we'd need pretty = strong use-cases and reasoning to support multi-message transactions and th= e associated complexity.


"SVC-8: =A0 For every service that it wishes to expose to a cl= ient, the

=A0 =A0 =A0 server SHOULD send capabilities that indicate = the existence and
=A0 =A0 =A0 identity of the service data model, as wel= l as valid states and
=A0 =A0 =A0 parameter ranges, any exceptions to it and the optional feature= s
=A0 =A0 =A0 of the data model that it supports."


This = doesn't sound particularly lightweight to do frequently. =A0I'm not= sure I see the arguments for valid states and parameter ranges - but I'= ;d presume that those are part of the policy authorization.



" =A0 SVC-17: =A0The server SHOULD indicate to the client = the availability of

=A0 =A0 =A0 infrastructure to manage the state t= hat it maintains. =A0This
=A0 =A0 =A0 includes but is not limited to the= availability of persistent
=A0 =A0 =A0 store, the availability of timer to clean up state after a
= =A0 =A0 =A0 specified timeout, the ability to clean up state on the occurre= nce
=A0 =A0 =A0 of an event, etc. =A0Equipped with this information, the= client is
=A0 =A0 =A0 responsible for the lifetime of the state."<= br>

Please reread the architecture draft and determine if you are addin= g persistent store back in. =A0I recall that we'd discussed having an o= ptional timer to clean up state after a specified timeout - but that was wh= en we had an end-time per operation instead of continuing forever. =A0IF th= at is still needed, then please capture the reasoning and we can discuss it= on the mailing list to see if the Architecture needs to add this particula= r case back in.


" =A0 SEC-2: =A0Every client MUST have an authorized role wher= eby only
=A0 =A0 =A0 certain state can be accessed and only certain oper= ations can be

=A0 =A0 =A0 performed by that client. =A0To keep the m= odel simple and
=A0 =A0 =A0 applications portable, authorization MUST be at a per service=A0 =A0 =A0 level and not on individual state element level."

I am not convinced that this trivial authorization is sufficient to be= used. =A0Obviously, I'd encourage others to provide their perspectives= - but I don't see security as something we can just add on later.


" =A0 SEC-3: =A0The framework MUST provide for information con= fidentiality

=A0 =A0 =A0 and information integrity as options."=


Do you mean in the default transport connection and the mandato= ry-to-implement transport? =A0Please clarify - and if not, then how would i= t be securely added? =A0


" =A0 PS-6: =A0 The transport protocol MUST provide for messag= e

=A0 =A0 =A0 prioritization."


Could you please expl= ain the reasoning and cases that need this?


" =A0 PS-8: =A0= The server MUST be kept stateless with respect to the number

=A0 =A0 =A0 and location of each client."


Do you mean t= hat it shouldn't be told about the clients beforehand or that it should= n't store state about them?? =A0The latter is what I'd interpret st= ateless to mean - but that makes no sense to me.


" =A0 PS-10: =A0An efficient synchronization mechanism between= a client and a

=A0 =A0 =A0 server SHOULD be provided that avoids tr= ansferring all the state
=A0 =A0 =A0 between them."


Plea= se describe the specific scenarios where this exchange is expected to occur= ??? =A0Then we can see if there are implications to the architecture (if th= ere's agreement on those scenarios).


General comment in Sec 4.9: =A0What about, say, not requiring that = the agent operate on all messages in order? =A0What about the agent operati= ng on messages from multiple clients at the same time? =A0 Those are mechan= isms that can improve performance and scale - by taking advantage of multi-= threading and so on. =A0I'd like to see more thought and details here, = because without requirements like those, I think performance issues are lik= ely.


" =A0 HA-1: =A0A 'superuser' identity SHOULD be provid= ed that is capable of

=A0 =A0 =A0 changing security policies, cleari= ng state and perform actions
=A0 =A0 =A0 that override client initiated = actions in the system."


Hmm, this is interesting. =A0I think that some of this is configura= tion of policies and data-models. =A0I.e., if we define a data-model for th= e security policies, then a client with write-scope for that service could = modify it. =A0For clearing state and such, the architecture does define a p= riority to be used as a tie-breaker, but that is considered an error-condit= ion. =A0Is this a sufficiently strong reason that shouldn't be an error= condition? =A0There was a strong consensus for the current state. =A0 Obvi= ously, one could delete or modify client-initiated actions via non-I2RS mec= hanisms.


" =A0 PGM-2: =A0The application once written to certain requir= ements should

=A0 =A0 =A0 be portable to other identical environment= s. =A0The framework should
=A0 =A0 =A0 not have fine grained data access= controls as this would lead to a
=A0 =A0 =A0 poorly written application with portability issues."

I'm confused by why the existence of fine-grained data access con= trols would lead to portability issues? =A0Can you clarify?


Gene= ral comment on Sec 4.12: =A0I'm delighted to see operational requiremen= ts - though some of these seem to be not so much requirements on the protoc= ol (detailed workflow) as specifying the need to do work to think through t= hese aspects (I smell more drafts) so that the protocol and data-model aspe= cts are clearer.


Finally, PLEASE do reread draft-ietf-i2rs-architecture, align termi= nology (or discuss why you loathe it on the list), and consider what should= be done about requirements that you have that depended on features in the = architecture that have been simplified out.


I'm happy to see the updated draft is much improved.

Regards,

Alia
--90e6ba614f0ef3fae404ea6a5d94-- From akatlas@gmail.com Tue Nov 5 10:14:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD91B21F9E95 for ; Tue, 5 Nov 2013 10:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxueaG+g+Zi1 for ; Tue, 5 Nov 2013 10:14:02 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF5521F9991 for ; Tue, 5 Nov 2013 10:14:02 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id u16so15266663iet.21 for ; Tue, 05 Nov 2013 10:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IykwzsQSL+cCm81T+KvXWlTseEjLpPKPZ+ebIPJ8KcY=; b=0TK71MmAw2JozXxN9m7FOrtndmDyfHl50vnQbeFuBEPkVJcDZHsUD2kJaFoEEhYD0C LZa8SkE41kEAy08vXZ3tJc8bkGogHcxqTWqVzY6yNqel5Taq7JLJBvaTStQ9/2dgu900 uEPrz5ab3V+H4EqEIFgZQRqM45JBA7ms59d1VI5eWbVQjlqCVqzYtUq218aAFHX0LnZN ZFMDlF3x/w9o6s59thkPdrF57RLzA9EWQLc8mJ2IAhs8QsI1wSAUf88la8/jqvsAgICU EtAZI+w00L9VUW7DsXt1DaPhkqK8qRp6D+sIVA/Vtxk6ja5oqyg49MiKh/ENJ+4Xe853 TlUw== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr16572643igb.5.1383675241478; Tue, 05 Nov 2013 10:14:01 -0800 (PST) Received: by 10.64.78.103 with HTTP; Tue, 5 Nov 2013 10:14:01 -0800 (PST) Date: Tue, 5 Nov 2013 13:14:01 -0500 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ffbae3f41159b04ea71ff5c Subject: [i2rs] Please send in your slides X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:14:02 -0000 --e89a8ffbae3f41159b04ea71ff5c Content-Type: text/plain; charset=ISO-8859-1 For those of you who have not yet sent in your slides for today's meeting, please do so ASAP. Thanks, Alia --e89a8ffbae3f41159b04ea71ff5c Content-Type: text/html; charset=ISO-8859-1
For those of you who have not yet sent in your slides for today's meeting, please do so ASAP.

Thanks,
Alia
--e89a8ffbae3f41159b04ea71ff5c-- From linda.dunbar@huawei.com Tue Nov 5 10:56:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7221E80B0 for ; Tue, 5 Nov 2013 10:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.411 X-Spam-Level: X-Spam-Status: No, score=-4.411 tagged_above=-999 required=5 tests=[AWL=-2.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwvcVsQn3zxX for ; Tue, 5 Nov 2013 10:56:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9160621F969F for ; Tue, 5 Nov 2013 10:56:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO62793; Tue, 05 Nov 2013 18:56:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:55:33 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 18:56:09 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 10:56:02 -0800 From: Linda Dunbar To: Huangtieying , Zhuangshunwan , "i2rs@ietf.org" , "Jixiaofeng (Steven)" , Yangang Thread-Topic: [I2RS] Questions to draft-ji-i2rs-usecases-ccne-service-00 Thread-Index: Ac7XVJxDbsF9exUPTyaNCqe2LyfcmwBqvtNQAACiBtgAVZKOIA== Date: Tue, 5 Nov 2013 18:56:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFCA8E@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BFB79F@dfweml509-mbx.china.huawei.com>, <000001ced901$cc166ee0$64434ca0$@com> <79EA23FFD17CE645922E0A1D0E4653793CA96B06@nkgeml510-mbs.china.huawei.com> In-Reply-To: <79EA23FFD17CE645922E0A1D0E4653793CA96B06@nkgeml510-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.228] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BFCA8Edfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [i2rs] [I2RS] Questions to draft-ji-i2rs-usecases-ccne-service-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:56:18 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BFCA8Edfweml509mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGllIFlpbmcsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0KDQpQQ0UgaW5kZWVkIGlzIGEgZ29v ZCBjaG9pY2UuDQpkcmFmdC1mYXJya2luZ2VsLXBjZS1hYm5vLWFyY2hpdGVjdHVyZS0wNi50eHQg cHJvdmlkZXMgYSBQQ0UtYmFzZWQgQXJjaGl0ZWN0dXJlIGZvciBBcHBsaWNhdGlvbi1iYXNlZCBO ZXR3b3JrIE9wZXJhdGlvbnMuDQoNCklzIHlvdXIgZHJhZnQgcHJldHR5IG11Y2ggYWxvbmcgdGhl IGxpbmU/DQoNClRoYW5rcywgTGluZGENCg0KDQpGcm9tOiBIdWFuZ3RpZXlpbmcNClNlbnQ6IFN1 bmRheSwgTm92ZW1iZXIgMDMsIDIwMTMgODoxMCBQTQ0KVG86IFpodWFuZ3NodW53YW47IExpbmRh IER1bmJhcjsgaTJyc0BpZXRmLm9yZzsgSml4aWFvZmVuZyAoU3RldmVuKTsgWWFuZ2FuZw0KU3Vi amVjdDogtPC4tDogW0kyUlNdIFF1ZXN0aW9ucyB0byBkcmFmdC1qaS1pMnJzLXVzZWNhc2VzLWNj bmUtc2VydmljZS0wMA0KDQpIaSBMaW5kYSwNCg0KICAgIEZvciBQQ0UgY2FzZSwgUENFUCBwcm90 b2NvbCBpcyB1c2VkIGZvciBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIGEgUENDIGFuZCBhIFBDRSwg b3IgYmV0d2VlbiB0d28gUENFcywgaW4gb21wbGlhbmNlIHdpdGggUkZDIDQ2NTcsIFN1Y2ggaW50 ZXJhY3Rpb25zIGluY2x1ZGUgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0cyBhbmQgcGF0aCBjb21w dXRhdGlvbiByZXBsaWVzIGFzIHdlbGwgYXMgbm90aWZpY2F0aW9ucyBvZiBzcGVjaWZpYyBzdGF0 ZXMgcmVsYXRlZCB0byB0aGUgdXNlIG9mIGEgUENFIGluIE1QTFMgYW5kIEdNUExTIFRFLg0KDQpS ZWdhcmRzLA0KVGllWWluZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogWmh1YW5nc2h1bndhbg0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MI0yNUgMTA6MDENCsrVvP7Iyzog TGluZGEgRHVuYmFyOyBpMnJzQGlldGYub3JnOyBKaXhpYW9mZW5nIChTdGV2ZW4pOyBZYW5nYW5n OyBIdWFuZ3RpZXlpbmcNCtb3zOI6IFJlOiBbSTJSU10gUXVlc3Rpb25zIHRvIGRyYWZ0LWppLWky cnMtdXNlY2FzZXMtY2NuZS1zZXJ2aWNlLTAwDQpMaW5kYSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUg YmVsb3cuDQoNCg0KUmVnYXJkcywNCg0KU2h1bldhbg0KDQq3orz+yMs6IExpbmRhIER1bmJhciBb bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MIyyNUg Njo0OQ0KytW8/sjLOiBpMnJzQGlldGYub3JnOyBKaXhpYW9mZW5nIChTdGV2ZW4pOyBaaHVhbmdz aHVud2FuDQrW98ziOiBRdWVzdGlvbnMgdG8gZHJhZnQtamktaTJycy11c2VjYXNlcy1jY25lLXNl cnZpY2UtMDANCg0KWGlhbyBGZW5nIGFuZCBTaHVuV2FuLA0KDQpkcmFmdC1qaS1pMnJzLXVzZWNh c2VzLWNjbmUtc2VydmljZS0wMCBwcm92aWRlcyBzb21lIGludGVyZXN0aW5nIHVzZSBjYXNlcyBm b3IgSTJSUy4NCg0KRm9yIHRoZSBmaXJzdCBjYXNlIKGwQ29udHJvbGxpbmcgUGF0aCBieSBSUqGx LCBhcmUgeW91IHByb3Bvc2luZyBpbnRlcmZhY2VzIHRvIFJSIHJvdXRlcj8gIElzIGl0IGNvcnJl Y3Q/IFdoYXQgaWYgdGhlIHJlcXVlc3QgdG8gUlIgY29uZmxpY3Qgd2l0aCB3aGF0IFJSoa9zIG93 biBjb21wdXRhdGlvbiBmcm9tIGFsbCBvdGhlciByb3V0ZXJzPw0KU2h1bldhbqO6DQpZZXMsIHdl oa9yZSBwcm9wb3NpbmcgaW50ZXJmYWNlcyB0byBSUiByb3V0ZXIuICBJZiBoYXZlIGNvbmZsaWN0 LCBSUiBzaG91bGQgZm9sbG93IHRoZSByZXF1aXJlIGZyb20gY29udHJvbGxlci4NClNlY3Rpb24g My4xDQqhrQ0KVG8gYXNzaXN0IG5ldHdvcmsgb3BlcmF0b3JzIGluIGFkZHJlc3NpbmcgdGhpcyBj aGFsbGVuZ2UsIHdlDQogICBwcmVzZW50IHNvbWUgSTJSUyBSUiB1c2UgY2FzZSwgaW50cm9kdWNl IGEgc2V0IG9mIEkyUlMgcHJvZ3JhbW1hdGljDQogICBBUElzIGZvciBSUiB0aGF0IGFsbG93cyBh IG5ldHdvcmsgb3BlcmF0b3IgdG8gZmxleGlibHkgY29udHJvbA0KICAgcm91dGluZyBiZXR3ZWVu IHRoZSB0cmFmZmljIGluZ3Jlc3NlcyBhbmQgZWdyZXNzZXMgd2l0aGluIGFuIElTUCdzDQogICBu ZXR3b3JrLg0KDQoNCkZvciB0aGUgZm9sbG93aW5nIHRleHQgKDMuMS4zKTogQXJlIHlvdSB0cnlp bmcgdG8gbWFrZSBSUiBkaWN0YXRlIHJvdXRlcyB3aXRoaW4gb25lIEFTIHdpdGggZXhwbGljaXQg Y29tbWFuZHMsICBidXQgbm90IHZpYSBjaGFuZ2luZyBSSUI/DQqhsFJSIGNhbiBjb21wdXRlIHRo ZSByb3V0ZXMgZm9yIGV2ZXJ5IHJvdXRlciBhbmQgaW5zdGFsbC9kaXN0cmlidXRlIHRoZSByb3V0 ZXMgdG8gY29ycmVzcG9uZGluZyByb3V0ZXJzobENCg0KU2h1bldhbqO6WWVzLg0KICAgRm9yIGV4 YW1wbGUsIGZvciBhIHBhdGggZnJvbSBTb3VyY2UgMSAoUzEpIHRvIERlc3RpbmF0aW9uIDEgKEQx KSwgaWYNCiAgIHRoZSBjb21wdXRlZCBwYXRoIGlzOiBTMS1BLUItQy1EMSwgdGhlbiB0aGUgUlIg d2lsbCBkaXN0cmlidXRlIGENCiAgIHJvdXRlIChEMSkgdG8gQyB3aXRoIHRoZSBuZXh0aG9wIHNl dCB0byBEMTsgYSByb3V0ZSAoRDEpIHRvIEIgd2l0aA0KICAgdGhlIG5leHRob3Agc2V0IHRvIEMs IGFuZCBhIHJvdXRlIChEMSkgdG8gQSB3aXRoIHRoZSBuZXh0aG9wIHNldCB0bw0KICAgQiwgYW5k IGZpbmFsbHkgdGhlIHJvdXRlIChEMSkgd2lsbCBiZSBkaXN0cmlidXRlZCB0byBTMSBieSBBLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAg ICAgICAgICAgICAgICAgICAgfCBBUFAgb3IgQ29udHJvbGxlciB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgW0ludGVyZmFjZSBmb3IgY29udHJvbCBpcCBmb3J3YXJk IG5ldHdvcmsgcGF0aF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC8gICAgXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFJSICB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgLw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvLSstXA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8g IHwgIFwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8gICB8ICAgXA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvICstLSstKyAgXA0KICAgICAgICAgICAgICAgICAgICAgICst LSstKy98IHwgQiAgfCAgICstLSstKw0KICAgICAgICAgICBTb3VyY2UgMS0tLXwgQSAgfCB8ICst LS0tKyAgIHwgQyAgfC0tLSBEZXN0aW5hdGlvbiAxDQogICAgICAgICAgICAgICAgICAgXCAvKy0t LS0rIHwgICAgICAgICAgKy0tLS0rXCAvDQogICAgICAgICAgICAgICAgICAgICogICAgKy0tLSst LS0tKy0tLS0tLS0rICAgICoNCiAgICAgICAgICAgICAgICAgICAvIFwrLS0rLSsgICAgICB8ICAg ICArLSstLSsvIFwNCiAgICAgICAgICAgU291cmNlIDItLS18IEQgIHwgICArLS0rLSsgICB8IEYg IHwtLS0gRGVzdGluYXRpb24gMg0KICAgICAgICAgICAgICAgICAgICAgICstLS0tKyAgIHwgRSAg fCAgICstLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tKw0KICAgICAg ICAgICBGaWd1cmUgMjogUm91dGUgUmVmbGVjdGlvbiBiYXNlZCBUcmFmZmljIFN0ZWVyaW5nIChS UlRTKQ0KDQpGb3IgdGhlIHNlY29uZCBjYXNlIG9uIFBDRSwgYXJlIHlvdSBzdWdnZXN0aW5nIHVz aW5nIFBDRVAgdG8gY29udHJvbCByb3V0ZXKhr3MgRklCPw0KDQpUaGFua3MsIExpbmRhDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F645BFCA8Edfweml509mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Tie Ying, <= /span>

 

Thanks for the reply. =

 

PCE indeed is a good c= hoice.  

draft-farrkingel-pce-abno-architecture-06.txt provides a PCE-based Architecture for = Application-based Network Operations.

 

Is your draft pretty m= uch along the line?

 

Thanks, Linda

 

 

From: Huangtie= ying
Sent: Sunday, November 03, 2013 8:10 PM
To: Zhuangshunwan; Linda Dunbar; i2rs@ietf.org; Jixiaofeng (Steven);= Yangang
Subject: =B4=F0=B8=B4: [I2RS] Questions to d= raft-ji-i2rs-usecases-ccne-service-00

 

Hi Linda,

 =

    For P= CE case, PCEP protocol is used for communications between a PCC and a PCE, = or between two PCEs, in ompliance with RFC 4657, Such interactions include = path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in= MPLS and GMPLS TE.

 =

Regards,

TieYing

=B7=A2= =BC=FE=C8=CB: Zhuangshunwan
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C24=C8=D5 10:01
=CA=D5=BC=FE=C8=CB: Linda Dunbar; i2rs@ietf.org; Jixiaofeng (Steven); Yangang; Huangtieying =D6=F7=CC=E2: Re: [I2RS] Questions to draft-ji-i2rs-usecases-ccne-service-00

Linda,

 =

Please see inline belo= w.

 =

Regards,

ShunWan

 =

=B7=A2=BC=FE=C8=CB:= Lind= a Dunbar [mailto:linda.dunbar@huawei.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C22=C8=D5 6:49
=CA=D5=BC=FE=C8=CB: i2rs@ietf.org; Jixia= ofeng (Steven); Zhuangshunwan
=D6=F7=CC=E2: Questions to draft-ji-i2rs= -usecases-ccne-service-00

 =

Xiao Feng and ShunWan, <= o:p>

 =

draft-ji-i2rs-usecases-c= cne-service-00 provides some interesting use cases for I2RS.

 =

For the first case =A1= =B0Controlling Path by RR=A1=B1, are you proposing interfaces to RR router?=   Is it correct? What if the request to RR conflict with what RR=A1=AF= s own computation from all other routers?

ShunWan=A3=BA=

Yes, we=A1=AFre propos= ing interfaces to RR router.  If have conflict, RR should follow the r= equire from controller.

Section 3.1

=A1=AD

To assist network operators in addressing this challenge, we

   present s= ome I2RS RR use case, introduce a set of I2RS programmatic

   APIs for = RR that allows a network operator to flexibly control

   routing b= etween the traffic ingresses and egresses within an ISP's

   network.<= /span>

 =

 =

For the following text (3.1.= 3): Are you trying to make RR dictate routes within one AS with explicit co= mmands,  but not via changing RIB?<= o:p>

=A1=B0RR can c= ompute the routes for every router and install/distribute the routes to cor= responding routers=A1=B1

 

ShunWan=A3=BA= Yes.<= /o:p>

 = ;  For example, for a path from Source 1 (S1) to Destination 1 (D1), i= f

 = ;  the computed path is: S1-A-B-C-D1, then the RR will distribute a

 = ;  route (D1) to C with the nexthop set to D1; a route (D1) to B with<= /span>

 = ;  the nexthop set to C, and a route (D1) to A with the nexthop set to=

 = ;  B, and finally the route (D1) will be distributed to S1 by A.

 =

 = ;            &n= bsp;           +-----= --------------+

 = ;            &n= bsp;           | APP or C= ontroller |

 = ;            &n= bsp;           +-----= --------------+

 = ;            &n= bsp;            = ;        |

 = ;           [Interface fo= r control ip forward network path]<= /o:p>

 = ;            &n= bsp;            = ;        |

 = ;            &n= bsp;            = ;       ----

 = ;            &n= bsp;            &nbs= p;     /    \

 = ;            &n= bsp;            = ;     |  RR  |

 = ;            &n= bsp;            = ;      \    /

 = ;            &n= bsp;            = ;      /-+-\

 = ;            &n= bsp;            = ;     /  |  \

 = ;            &n= bsp;            = ;    /   |   \

 = ;            &n= bsp;            = ;   / +--+-+  \

 = ;             &= nbsp;       +--+-+/| | B&nbs= p; |   +--+-+=

 = ;          Source 1---| A = ; | | +----+   | C  |--- Destination 1

 = ;            &n= bsp;     \ /+----+ |    &nb= sp;     +----+\ /

 = ;            &n= bsp;      *    +---+----= 3;-------+    *<= /o:p>

 = ;            &n= bsp;     / \+--+-+    &= nbsp; |     +-+--+/ \

 = ;          Source 2---| D = ; |   +--+-+   | F  |--- Destination 2=

 = ;            &n= bsp;        +----+   |= E  |   +----+

 = ;            &n= bsp;            = ;     +----+=

 = ;          Figure 2: Route Ref= lection based Traffic Steering (RRTS)

 =

For the second case on P= CE, are you suggesting using PCEP to control router=A1=AFs FIB?

 =

Thanks, Linda=

--_000_4A95BA014132FF49AE685FAB4B9F17F645BFCA8Edfweml509mbxchi_-- From prvs=80222f09cc=hshah@ciena.com Tue Nov 5 18:08:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7B11E81B2 for ; Tue, 5 Nov 2013 18:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVY5gCVtaut for ; Tue, 5 Nov 2013 18:08:20 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18F11E81A7 for ; Tue, 5 Nov 2013 18:08:20 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id rA624jr7002776 for ; Tue, 5 Nov 2013 21:08:20 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1fy96mggxe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 05 Nov 2013 21:08:20 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 5 Nov 2013 21:08:18 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Tue, 5 Nov 2013 21:07:55 -0500 From: "Shah, Himanshu" To: "i2rs@ietf.org" Date: Tue, 5 Nov 2013 21:07:53 -0500 Thread-Topic: question on I2RS architecture Thread-Index: Ac7alFO4qVZMswW2TqiS1gRfl+CkNQ== Message-ID: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> 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_40746B2300A8FC4AB04EE722A593182B69F0907FONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20270.003 X-TM-AS-Result: No--13.986600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-05_08:2013-11-05, 2013-11-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311050223 Subject: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:08:27 -0000 --_000_40746B2300A8FC4AB04EE722A593182B69F0907FONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the IETF I2RS interim meeting, I raised the concern about conflicting se= t operations by I2RS clients to different I2RS agents, Which may end up causing micro-loop or far-side loop. Is this addressed in the architecture? May be this is responsibility of network orchestrator. If it is not mentioned in the doc, may be some text necessary to explain?? Thanks, himanshu Himanshu Shah Ciena Corp --_000_40746B2300A8FC4AB04EE722A593182B69F0907FONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the IETF I2RS= interim meeting, I raised the concern about conflicting set operations by = I2RS clients to different I2RS agents,

Which may end up causing micro-loop or far-side loop.

 

Is this addressed in the architecture?

If it is not mentioned in the doc,= may be some text necessary to explain??

 

Thanks,<= /o:p>

himanshu

To: "'Shah, Himanshu'" , References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> Date: Wed, 6 Nov 2013 09:49:34 -0500 Message-ID: <072901cedaff$6bc98e50$435caaf0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJi5jBr4PwRStQknEOpd7c8VNPuqJjwMeZQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:49:43 -0000 > At the IETF I2RS interim meeting, I raised the concern about conflicting set > operations by I2RS clients to different I2RS agents, > > Which may end up causing micro-loop or far-side loop. There's no way, in this sort of architecture, to prevent people from tying a noose in the rope. :-) OTOH, the priority of different set operations by different agents, and whether things are strictly time ordered is, I think, still under discussion, and will need to be resolved to get to the protocol stage. Maybe someone else can comment on the current state around this specific piece to clarify (?). :-) Russ From jmh@joelhalpern.com Wed Nov 6 08:54:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8CD21E8082 for ; Wed, 6 Nov 2013 08:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPSfhivVMdgJ for ; Wed, 6 Nov 2013 08:54:34 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C521F9A97 for ; Wed, 6 Nov 2013 08:54:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id BF1863C0A27; Wed, 6 Nov 2013 08:54:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-bcef.meeting.ietf.org (dhcp-bcef.meeting.ietf.org [31.133.188.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 88A073C0A25; Wed, 6 Nov 2013 08:54:33 -0800 (PST) Message-ID: <527A7448.6010108@joelhalpern.com> Date: Wed, 06 Nov 2013 11:54:32 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Shah, Himanshu" , "i2rs@ietf.org" References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:54:39 -0000 If someone wants to create inconsistency using I2RS, we won't stop them. And although there was opne request for very precise timing on operations, that seems to me to be a step too far. Yours, Joel On 11/5/13 9:07 PM, Shah, Himanshu wrote: > /At the IETF I2RS interim meeting, I raised the concern about > conflicting set operations by I2RS clients to different I2RS agents,/ > > /Which may end up causing micro-loop or far-side loop. / > > // > > /Is this addressed in the architecture? / > > /May be this is responsibility of network orchestrator./ > > /If it is not mentioned in the doc, may be some text necessary to explain??/ > > // > > /Thanks,/ > > /himanshu/ > > // > > /Himanshu Shah/ > > /Ciena Corp/ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From prvs=80222f09cc=hshah@ciena.com Wed Nov 6 09:12:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD84221E8147 for ; Wed, 6 Nov 2013 09:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcOvc8iuNOf5 for ; Wed, 6 Nov 2013 09:12:01 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0211E81D1 for ; Wed, 6 Nov 2013 09:12:00 -0800 (PST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by m0002317.ppops.net (8.14.5/8.14.5) with SMTP id rA6H63k8022215; Wed, 6 Nov 2013 09:11:50 -0800 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 1fy7t73byc-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Nov 2013 09:11:50 -0800 Received: from MDWVEXCHHT02.ciena.com (10.4.156.176) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 12:11:49 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWVEXCHHT02.ciena.com (10.4.156.176) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 12:11:48 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 6 Nov 2013 12:11:44 -0500 From: "Shah, Himanshu" To: "Joel M. Halpern" , "i2rs@ietf.org" Date: Wed, 6 Nov 2013 12:11:39 -0500 Thread-Topic: [i2rs] question on I2RS architecture Thread-Index: Ac7bEOTZqRFrQ3ELT5CeXdA4qrSX8QAAbthA Message-ID: <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> In-Reply-To: <527A7448.6010108@joelhalpern.com> 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-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20272.000 X-TM-AS-Result: No--25.746000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-06_04:2013-11-06, 2013-11-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311060120 Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:12:05 -0000 I was not alluding to malicious use but genuine use of I2rs interface in th= e absence of=20 complete view of the latest network topology and/or view of what other I2RS= client are doing or are about to do. There needs to be safeguards. I2RS needs to a= ddress consistency verification aspects.=20 If that is offloaded to some other entity, I2RS arch spec needs to explicit= ly mention that. /himanshu -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, November 06, 2013 11:55 AM To: Shah, Himanshu; i2rs@ietf.org Subject: Re: [i2rs] question on I2RS architecture If someone wants to create inconsistency using I2RS, we won't stop them. And although there was opne request for very precise timing on operations, = that seems to me to be a step too far. Yours, Joel On 11/5/13 9:07 PM, Shah, Himanshu wrote: > /At the IETF I2RS interim meeting, I raised the concern about=20 > conflicting set operations by I2RS clients to different I2RS agents,/ > > /Which may end up causing micro-loop or far-side loop. / > > // > > /Is this addressed in the architecture? / > > /May be this is responsibility of network orchestrator./ > > /If it is not mentioned in the doc, may be some text necessary to=20 > explain??/ > > // > > /Thanks,/ > > /himanshu/ > > // > > /Himanshu Shah/ > > /Ciena Corp/ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From russw@riw.us Wed Nov 6 09:19:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A111E8112 for ; Wed, 6 Nov 2013 09:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2sffnxl6PFS for ; Wed, 6 Nov 2013 09:19:10 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE7211E8132 for ; Wed, 6 Nov 2013 09:19:10 -0800 (PST) Received: from dhcp-a335.meeting.ietf.org ([31.133.163.53]:56996) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Ve6kz-0008EY-BQ; Wed, 06 Nov 2013 17:19:05 +0000 References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> Mime-Version: 1.0 (1.0) In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B511) From: Russ White Date: Wed, 6 Nov 2013 09:19:05 -0800 To: "Shah, Himanshu" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russ@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:19:14 -0000 The problem with enforcing consistency in this environment is it would be ju= st as impossible to attain as it is with a distributed control plane in real= time. It seems, to me, that we can provide an interface, but the controller= /software doing the controlling must do the consistency insurance, just as r= outing protocols do today... :-) Russ <>< russw@riw.us Ericsson > On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" wrote: >=20 > I was not alluding to malicious use but genuine use of I2rs interface in t= he absence of=20 > complete view of the latest network topology and/or view of what other I2R= S client > are doing or are about to do. There needs to be safeguards. I2RS needs to a= ddress > consistency verification aspects.=20 >=20 > If that is offloaded to some other entity, I2RS arch spec needs to explici= tly mention that. >=20 > /himanshu >=20 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 > Sent: Wednesday, November 06, 2013 11:55 AM > To: Shah, Himanshu; i2rs@ietf.org > Subject: Re: [i2rs] question on I2RS architecture >=20 > If someone wants to create inconsistency using I2RS, we won't stop them. > And although there was opne request for very precise timing on operations,= that seems to me to be a step too far. >=20 > Yours, > Joel >=20 >> On 11/5/13 9:07 PM, Shah, Himanshu wrote: >> /At the IETF I2RS interim meeting, I raised the concern about=20 >> conflicting set operations by I2RS clients to different I2RS agents,/ >>=20 >> /Which may end up causing micro-loop or far-side loop. / >>=20 >> // >>=20 >> /Is this addressed in the architecture? / >>=20 >> /May be this is responsibility of network orchestrator./ >>=20 >> /If it is not mentioned in the doc, may be some text necessary to=20 >> explain??/ >>=20 >> // >>=20 >> /Thanks,/ >>=20 >> /himanshu/ >>=20 >> // >>=20 >> /Himanshu Shah/ >>=20 >> /Ciena Corp/ >>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Wed Nov 6 10:30:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFD721F8E8E for ; Wed, 6 Nov 2013 10:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar3Fe2VV0m1s for ; Wed, 6 Nov 2013 10:30:26 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9611E8127 for ; Wed, 6 Nov 2013 10:30:25 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so18063852iet.18 for ; Wed, 06 Nov 2013 10:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Qm07gGiDmJUyxV/LIqQSzGksnP6wjxzWyptN713kfw=; b=MhFLDBzY9hvijT9+PK0eV0unmj2ccGyvwOe+uSWfdRaVUX1h7SVL/JEThEwT5YMyFE n821mgSLZVajWp7VGTL+XkWAj1ksvM9Y+uBsyaJ3srGsbxul86BYriKW/ZebUqjbCNCE L58fRW/S4LNbLGgXrPztiERYL9vZy9W4fj2HurMSG0YqWP0LZAYBvf//NgdAYMBam/cy nObA2hOaPZoysslVFFxxZwuJ6yQ7E4PMiGhytY8C0fAoO8/tyZW48JeJDqtZH0LiBawN UR17ZBqK8uCMo9tl3c+4ccqVlhY8WTqkpUs96M1QSUY4gEM5tKd5gQayORt3SvOgjtx2 NgZw== MIME-Version: 1.0 X-Received: by 10.50.30.42 with SMTP id p10mr3434174igh.5.1383762625353; Wed, 06 Nov 2013 10:30:25 -0800 (PST) Received: by 10.64.78.103 with HTTP; Wed, 6 Nov 2013 10:30:24 -0800 (PST) Received: by 10.64.78.103 with HTTP; Wed, 6 Nov 2013 10:30:24 -0800 (PST) In-Reply-To: References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> Date: Wed, 6 Nov 2013 13:30:24 -0500 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=047d7bdc9db2bd294004ea86577a Cc: i2rs@ietf.org, "Joel M. Halpern" , "Shah, Himanshu" Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:30:27 -0000 --047d7bdc9db2bd294004ea86577a Content-Type: text/plain; charset=ISO-8859-1 This is an aspect of the unexpected interactions problem. There's text in the architecture saying that these can happen. This was offered for discussion on the list to resounding silence. We can't reasonably solve this distributed problem from the vantage of a particular network element, which is what an I2RS agent has. Alia On Nov 6, 2013 9:19 AM, "Russ White" wrote: > > The problem with enforcing consistency in this environment is it would be > just as impossible to attain as it is with a distributed control plane in > real time. It seems, to me, that we can provide an interface, but the > controller/software doing the controlling must do the consistency > insurance, just as routing protocols do today... > > :-) > > Russ > > <>< > russw@riw.us > Ericsson > > > On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" wrote: > > > > I was not alluding to malicious use but genuine use of I2rs interface in > the absence of > > complete view of the latest network topology and/or view of what other > I2RS client > > are doing or are about to do. There needs to be safeguards. I2RS needs > to address > > consistency verification aspects. > > > > If that is offloaded to some other entity, I2RS arch spec needs to > explicitly mention that. > > > > /himanshu > > > > -----Original Message----- > > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Sent: Wednesday, November 06, 2013 11:55 AM > > To: Shah, Himanshu; i2rs@ietf.org > > Subject: Re: [i2rs] question on I2RS architecture > > > > If someone wants to create inconsistency using I2RS, we won't stop them. > > And although there was opne request for very precise timing on > operations, that seems to me to be a step too far. > > > > Yours, > > Joel > > > >> On 11/5/13 9:07 PM, Shah, Himanshu wrote: > >> /At the IETF I2RS interim meeting, I raised the concern about > >> conflicting set operations by I2RS clients to different I2RS agents,/ > >> > >> /Which may end up causing micro-loop or far-side loop. / > >> > >> // > >> > >> /Is this addressed in the architecture? / > >> > >> /May be this is responsibility of network orchestrator./ > >> > >> /If it is not mentioned in the doc, may be some text necessary to > >> explain??/ > >> > >> // > >> > >> /Thanks,/ > >> > >> /himanshu/ > >> > >> // > >> > >> /Himanshu Shah/ > >> > >> /Ciena Corp/ > >> > >> > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7bdc9db2bd294004ea86577a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

This is an aspect of the unexpected interactions problem.=A0= There's text in the architecture saying that these can happen.=A0=A0 T= his was offered for discussion on the list to resounding silence.

We can't reasonably solve this distributed problem from = the vantage of a particular network element, which is what an I2RS agent ha= s.

Alia

On Nov 6, 2013 9:19 AM, "Russ White" &= lt;russw@riw.us> wrote:

The problem with enforcing consistency in this environment is it would be j= ust as impossible to attain as it is with a distributed control plane in re= al time. It seems, to me, that we can provide an interface, but the control= ler/software doing the controlling must do the consistency insurance, just = as routing protocols do today...

:-)

Russ

<><
russw@riw.us
Ericsson

> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" <hshah@ciena.com> wrote:
>
> I was not alluding to malicious use but genuine use of I2rs interface = in the absence of
> complete view of the latest network topology and/or view of what other= I2RS client
> are doing or are about to do. There needs to be safeguards. I2RS needs= to address
> consistency verification aspects.
>
> If that is offloaded to some other entity, I2RS arch spec needs to exp= licitly mention that.
>
> /himanshu
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
> Sent: Wednesday, November 06, 2013 11:55 AM
> To: Shah, Himanshu; i2rs@ietf.org=
> Subject: Re: [i2rs] question on I2RS architecture
>
> If someone wants to create inconsistency using I2RS, we won't stop= them.
> And although there was opne request for very precise timing on operati= ons, that seems to me to be a step too far.
>
> Yours,
> Joel
>
>> On 11/5/13 9:07 PM, Shah, Himanshu wrote:
>> /At the IETF I2RS interim meeting, I raised the concern about
>> conflicting set operations by I2RS clients to different I2RS agent= s,/
>>
>> /Which may end up causing micro-loop or far-side loop. /
>>
>> //
>>
>> /Is this addressed in the architecture? /
>>
>> /May be this is responsibility of network orchestrator./
>>
>> /If it is not mentioned in the doc, may be some text necessary to<= br> >> explain??/
>>
>> //
>>
>> /Thanks,/
>>
>> /himanshu/
>>
>> //
>>
>> /Himanshu Shah/
>>
>> /Ciena Corp/
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
--047d7bdc9db2bd294004ea86577a-- From rraszuk@gmail.com Wed Nov 6 10:34:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3405F11E8115 for ; Wed, 6 Nov 2013 10:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2Ly-DMZ-QUm for ; Wed, 6 Nov 2013 10:34:58 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B111E80F9 for ; Wed, 6 Nov 2013 10:34:58 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so17676517iec.20 for ; Wed, 06 Nov 2013 10:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NA1igFqQXvVg71A1qZPjCzjULoMvx/8EPoNgBuxmSsg=; b=CTFbJKMTqcvMAQhwp4D5WeLV9asJlyk0RB7ogG42nh4zfX/QRAnzogLyEVQQRa4Dd7 6r4y3PiGS1OdE+rK9tgySXBxmrqlv4xwwB9p6Zuap5kNSPTFTi7EyeMKkfRVwufn0aKm l/KTLoewnIfeVURedCEIOvFUFwGH4uh8BBURbbKAhoJlEWOKkczrzd+KciSj74GmXM8C sgoNJw2p5F8JKBWx0rfdogNK3cAh6igPMMXiRxvD4IxDZg3Aqy3kIr6IbmaJpiov3FW9 KlCmi2+hBTwH5i6rrUTO5FOi3VwSZzjbEiRaIHoelRfsTT40oQGbiN8WUO/22tBkrJnJ cm6g== MIME-Version: 1.0 X-Received: by 10.50.55.65 with SMTP id q1mr21145481igp.4.1383762897971; Wed, 06 Nov 2013 10:34:57 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.61.129 with HTTP; Wed, 6 Nov 2013 10:34:57 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Nov 2013 19:34:57 +0100 X-Google-Sender-Auth: RG3lYgmhQKGBIhVRBlbICvrBkGk Message-ID: From: Robert Raszuk To: Scott Whyte Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Kumari , "i2rs@ietf.org" , Marcus Hines Subject: Re: [i2rs] Bulk data collection use cases draft submitted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:34:59 -0000 Hi Scott, As mentioned yesterday it would be helpful to provide reasons why MRT (Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format) http://tools.ietf.org/html/rfc6396 or perhaps it's minor extension would not work for you. Sorry for misstating the "M", but for me everything is multiprotocol :-) And MRT already supports OSPFv2/v3, BGP, ISIS & RIB exports. Thx, R. On Mon, Oct 21, 2013 at 11:02 PM, Scott Whyte wrote: > We've submitted a draft of what we believe to be interesting bulk data > collection use cases for I2RS, and the concomitant functionality > missing from existing solutions. Please read and comment. > > Normative and informative references are still to be added, and the > draft is still rough around the edges. Data model discussions are > deliberately left out, hopefully the scope is sufficient. And of > course other interesting use cases would be welcome. > > Thanks for having a look. > > -Scott > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 21, 2013 at 11:11 AM > Subject: New Version Notification for > draft-swhyte-i2rs-data-collection-system-00.txt > To: Scott Whyte , Marcus Hines , > Warren Kumari > > > > A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt > has been successfully submitted by Scott Whyte and posted to the > IETF repository. > > Filename: draft-swhyte-i2rs-data-collection-system > Revision: 00 > Title: Bulk Network Data Collection System > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-system-00.txt > Status: > http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system > Htmlized: > http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 > > > Abstract: > Collecting large amounts of data from network infrastructure devices > has never been very easy. Existing methods generate CPU and memory > loads that may be unacceptable, the output varies across > implementations and can be difficult to parse, and these methods are > often difficult to scale. I2RS programmatic interfacing with the > routing system may exacerbate this problem: state needs to be > collected from nodes and fed to consumers participating in the > control plane that may not be physically close to the nodes. This > state includes not only control plane information, but elements of > the data plane that have a direct impact on control plane behavior, > like traffic engineering. > > This document outlines a set of use cases requiring a flexible > framework to collect routing system data, and the features and > functionality needed to make such a framework useful for these use > cases. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From jclarke@cisco.com Wed Nov 6 11:35:48 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F3521F9D11 for ; Wed, 6 Nov 2013 11:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uflSSyeJijxF for ; Wed, 6 Nov 2013 11:35:42 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CB65A11E80D9 for ; Wed, 6 Nov 2013 11:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3818; q=dns/txt; s=iport; t=1383766543; x=1384976143; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MWL2UFBctDrhTXMIPf8pGQqXtfZGP+oy9MvWgMRDqe4=; b=BHcqv1D/A7ZFLKFTDuRsfI1/nVqEiWkBeqLA3iT4hIqGck1KniqmDw/3 QTG0NdQ8Xgvyfjr88ILv+kZ+bTmLBhro+Xbl8q/FYBPo4YwKLNQW2nGK0 ZuuKxQr1bxokc2sRhE5FYOyrcG1k2+Ww5MW8TvNc9Z8vQdUkZgnIr4+Vg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAAWZelKrRDoH/2dsb2JhbABXA4MHOMAJgSYWdIIlAQEBBAEBATU2CgEOAgsOAwMBAgEJFg8JAwIBAgEJDCgIBgEMAQUCAQEFEodlDr8gBI4MgTkQBwYLhB8DiUCOTIEvkFuDRB6BLgcXBg X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="96736133" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Nov 2013 19:35:41 +0000 Received: from sjc-vpn2-1186.cisco.com (sjc-vpn2-1186.cisco.com [10.21.116.162]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA6JZco9004642; Wed, 6 Nov 2013 19:35:39 GMT Message-ID: <527A9A0A.8030503@cisco.com> Date: Wed, 06 Nov 2013 14:35:38 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Scott Whyte , i2rs@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Warren Kumari , Marcus Hines Subject: Re: [i2rs] Bulk data collection use cases draft submitted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:35:48 -0000 On 10/21/13, 5:02 PM, Scott Whyte wrote: > We've submitted a draft of what we believe to be interesting bulk data > collection use cases for I2RS, and the concomitant functionality > missing from existing solutions. Please read and comment. > > Normative and informative references are still to be added, and the > draft is still rough around the edges. Data model discussions are > deliberately left out, hopefully the scope is sufficient. And of > course other interesting use cases would be welcome. > > Thanks for having a look. Thanks for raising this, Scott. In terms of the streaming (i.e., live data feeds), I see this as a very valuable thing for our traceability draft as well. I feel there is a good compliment there. Early on I had thought I2RS itself (via notifications) could make logging data available as a "stream." With your idea of bulk information collection and querying/filtering, we can install a filter to collect specific log messages or specific parts of log messages. This would be very beneficial for troubleshooting and consistency validation. Joe > > -Scott > > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 21, 2013 at 11:11 AM > Subject: New Version Notification for > draft-swhyte-i2rs-data-collection-system-00.txt > To: Scott Whyte , Marcus Hines , > Warren Kumari > > > > A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt > has been successfully submitted by Scott Whyte and posted to the > IETF repository. > > Filename: draft-swhyte-i2rs-data-collection-system > Revision: 00 > Title: Bulk Network Data Collection System > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-system-00.txt > Status: > http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system > Htmlized: > http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 > > > Abstract: > Collecting large amounts of data from network infrastructure devices > has never been very easy. Existing methods generate CPU and memory > loads that may be unacceptable, the output varies across > implementations and can be difficult to parse, and these methods are > often difficult to scale. I2RS programmatic interfacing with the > routing system may exacerbate this problem: state needs to be > collected from nodes and fed to consumers participating in the > control plane that may not be physically close to the nodes. This > state includes not only control plane information, but elements of > the data plane that have a direct impact on control plane behavior, > like traffic engineering. > > This document outlines a set of use cases requiring a flexible > framework to collect routing system data, and the features and > functionality needed to make such a framework useful for these use > cases. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From prvs=80222f09cc=hshah@ciena.com Wed Nov 6 11:46:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F511E80F6 for ; Wed, 6 Nov 2013 11:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI0tOHnSch5g for ; Wed, 6 Nov 2013 11:46:40 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 45F6B11E80DE for ; Wed, 6 Nov 2013 11:46:31 -0800 (PST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by m0002317.ppops.net (8.14.5/8.14.5) with SMTP id rA6JiIId027320; Wed, 6 Nov 2013 11:46:20 -0800 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 1fy7t73xkq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Nov 2013 11:46:19 -0800 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 14:46:19 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 6 Nov 2013 14:45:57 -0500 From: "Shah, Himanshu" To: Alia Atlas , Russ White Date: Wed, 6 Nov 2013 14:45:55 -0500 Thread-Topic: [i2rs] question on I2RS architecture Thread-Index: Ac7bHkVPzEGLmWkFTjmzOkEfGp9fOgACUB9w Message-ID: <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> In-Reply-To: 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_40746B2300A8FC4AB04EE722A593182B69F095A8ONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20272.000 X-TM-AS-Result: No--44.858100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-06_05:2013-11-06, 2013-11-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311060157 Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:46:49 -0000 --_000_40746B2300A8FC4AB04EE722A593182B69F095A8ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wouldn't this be a stumbling block for I2RS architecture? (sorry for having= missed the discussion on mailing list on this issue). In distributed control plane, transient inconsistencies are repaired eventu= ally (once every node has updated topo info). I am not sure I2RS mechanisms has built-in detection and/or repair mechanis= m resulting in sustained instability. May be I2RS clients need to get 'permission' from an orchestrator or "an I2= RS-coordinator" before issuing 'set' operations to I2RS agent? /himanshu From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Wednesday, November 06, 2013 1:30 PM To: Russ White Cc: Joel M. Halpern; i2rs@ietf.org; Shah, Himanshu Subject: Re: [i2rs] question on I2RS architecture This is an aspect of the unexpected interactions problem. There's text in = the architecture saying that these can happen. This was offered for discu= ssion on the list to resounding silence. We can't reasonably solve this distributed problem from the vantage of a pa= rticular network element, which is what an I2RS agent has. Alia On Nov 6, 2013 9:19 AM, "Russ White" > wr= ote: The problem with enforcing consistency in this environment is it would be j= ust as impossible to attain as it is with a distributed control plane in re= al time. It seems, to me, that we can provide an interface, but the control= ler/software doing the controlling must do the consistency insurance, just = as routing protocols do today... :-) Russ <>< russw@riw.us Ericsson > On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" > wrote: > > I was not alluding to malicious use but genuine use of I2rs interface in = the absence of > complete view of the latest network topology and/or view of what other I2= RS client > are doing or are about to do. There needs to be safeguards. I2RS needs to= address > consistency verification aspects. > > If that is offloaded to some other entity, I2RS arch spec needs to explic= itly mention that. > > /himanshu > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, November 06, 2013 11:55 AM > To: Shah, Himanshu; i2rs@ietf.org > Subject: Re: [i2rs] question on I2RS architecture > > If someone wants to create inconsistency using I2RS, we won't stop them. > And although there was opne request for very precise timing on operations= , that seems to me to be a step too far. > > Yours, > Joel > >> On 11/5/13 9:07 PM, Shah, Himanshu wrote: >> /At the IETF I2RS interim meeting, I raised the concern about >> conflicting set operations by I2RS clients to different I2RS agents,/ >> >> /Which may end up causing micro-loop or far-side loop. / >> >> // >> >> /Is this addressed in the architecture? / >> >> /May be this is responsibility of network orchestrator./ >> >> /If it is not mentioned in the doc, may be some text necessary to >> explain??/ >> >> // >> >> /Thanks,/ >> >> /himanshu/ >> >> // >> >> /Himanshu Shah/ >> >> /Ciena Corp/ >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_40746B2300A8FC4AB04EE722A593182B69F095A8ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wouldn= 217;t this be a stumbling block for I2RS architecture? (sorry for having mi= ssed the discussion on mailing list on this issue).

In distributed control plane, transient inconsi= stencies are repaired eventually (once every node has updated topo info).

I am not sure I2RS mechan= isms has built-in detection and/or repair mechanism resulting in sustained = instability.

&nbs= p;

May be I2RS clients need t= o get ‘permission’ from an orchestrator or “an I2RS-coord= inator” before issuing ‘set’ operations to I2RS agent?

 

/himanshu

 

<= span style=3D'font-size:11.0pt;font-family:"Cambria","serif";color:#0000CC'= > 

 

From: Alia Atlas [mailto:akatlas@gmail.c= om]
Sent: Wednesday, November 06, 2013 1:30 PM
To: Rus= s White
Cc: Joel M. Halpern; i2rs@ietf.org; Shah, Himanshu
= Subject: Re: [i2rs] question on I2RS architecture

=

 

This is an aspect of the unexp= ected interactions problem.  There's text in the architecture saying t= hat these can happen.   This was offered for discussion on the li= st to resounding silence.

We can't reasonably solve this d= istributed problem from the vantage of a particular network element, which = is what an I2RS agent has.

Alia

On Nov 6, 2013 9:19 AM, "Russ White" <russw@riw.us> wrote:


The problem with enforcing consistency in this environment is= it would be just as impossible to attain as it is with a distributed contr= ol plane in real time. It seems, to me, that we can provide an interface, b= ut the controller/software doing the controlling must do the consistency in= surance, just as routing protocols do today...

:-)

Russ
<><
russw@riw.us
Erics= son

> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" <= hshah@ciena.com> wrote:
>> I was not alluding to malicious use but genuine use of I2rs interfac= e in the absence of
> complete view of the latest network topology an= d/or view of what other I2RS client
> are doing or are about to do. T= here needs to be safeguards. I2RS needs to address
> consistency veri= fication aspects.
>
> If that is offloaded to some other entity= , I2RS arch spec needs to explicitly mention that.
>
> /himansh= u
>
> -----Original Message-----
> From: Joel M. Halpern = [mailto:jmh@joelhalpern.com]
= > Sent: Wednesday, November 06, 2013 11:55 AM
> To: Shah, Himanshu= ; i2rs@ietf.org
> Subject: Re: [= i2rs] question on I2RS architecture
>
> If someone wants to cre= ate inconsistency using I2RS, we won't stop them.
> And although ther= e was opne request for very precise timing on operations, that seems to me = to be a step too far.
>
> Yours,
> Joel
>
>&g= t; On 11/5/13 9:07 PM, Shah, Himanshu wrote:
>> /At the IETF I2RS = interim meeting, I raised the concern about
>> conflicting set ope= rations by I2RS clients to different I2RS agents,/
>>
>> = /Which may end up causing micro-loop or far-side loop. /
>>
>= ;> //
>>
>> /Is this addressed in the architecture? /<= br>>>
>> /May be this is responsibility of network orchestra= tor./
>>
>> /If it is not mentioned in the doc, may be so= me text necessary to
>> explain??/
>>
>> //
&= gt;>
>> /Thanks,/
>>
>> /himanshu/
>>= ;
>> //
>>
>> /Himanshu Shah/
>>
>= ;> /Ciena Corp/
>>
>>
>>
>> ________= _______________________________________
>> i2rs mailing list
&g= t;> i2rs@ietf.org
>> https:/= /www.ietf.org/mailman/listinfo/i2rs
> ___________________________= ____________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/= i2rs
_______________________________________________
i2rs mailing= list
i2rs@ietf.org
https://www.ie= tf.org/mailman/listinfo/i2rs

= --_000_40746B2300A8FC4AB04EE722A593182B69F095A8ONWVEXCHMB04cie_-- From sriganeshkini@gmail.com Wed Nov 6 12:43:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00621E8193 for ; Wed, 6 Nov 2013 12:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52BzTnPhbKm4 for ; Wed, 6 Nov 2013 12:43:16 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43321E81A9 for ; Wed, 6 Nov 2013 12:43:16 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id q10so37990pdj.28 for ; Wed, 06 Nov 2013 12:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=UxlViVbLQeQgA+a8rFiLO2i05EKQ6MqMYdQ9mnqZyIM=; b=0g59uTISOe0ZEnfoiIC6u0LjnoAjz3Qbz64MlOFmlPuINNp0rXehgTQ1UlKQiig+Ni 2VrEGL6nujMMkmGZzHM79eNGFUgY3Tvnmf/vy1QbgdNcFc+9rK0GHbLF9tkgwZ4ojv2F BA7OvXPUQwCNwcWzGeR4QK84TLRO6kRCarS98TXPShhXirF+HT6VJ8dnbUbhvoVsQKTc qO/+4DcIveXFeHS4+84VGdqaldfNdTCK5KYqsGBhyRzhF8o6EdGIkmMxaShHtINPvf4J 4OeMhYpujcoHQ6XDqVOu7S1LSuU1PHHHsMhX3Lq5hfchMz1nnmhU/XPW1tW3iW/KwDW2 P/Pg== X-Received: by 10.66.118.204 with SMTP id ko12mr3728117pab.184.1383770594946; Wed, 06 Nov 2013 12:43:14 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Wed, 6 Nov 2013 12:42:42 -0800 (PST) In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> From: Sriganesh Kini Date: Wed, 6 Nov 2013 12:42:42 -0800 X-Google-Sender-Auth: 6mCAooFf_l7yV8eIPKRVjY0XPd0 Message-ID: To: "Shah, Himanshu" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:43:18 -0000 Himanshu, It seems like you are comparing apples to oranges when you compare a distributed routing protocol to the interface to the routing system. If it helps any, take a look at Fig 1. of draft-ietf-i2rs-rib-info-model. The distributed routing protocol would be a client. The I2RS agent (not shown in that Fig) would provide the interface from the client towards the Routing System (in the context of this draft, this is the RIB). Just as a routing-protocol may have an eventual-consistency model, any new client using the I2RS interface would have to design its own consistency model. The client can use mechanisms such as transactions (sec 6.9 of draft-ietf-i2rs-architecture) towards that. - Sri On Wed, Nov 6, 2013 at 11:45 AM, Shah, Himanshu wrote: > Wouldn=E2=80=99t this be a stumbling block for I2RS architecture? (sorry = for having > missed the discussion on mailing list on this issue). > > In distributed control plane, transient inconsistencies are repaired > eventually (once every node has updated topo info). > > I am not sure I2RS mechanisms has built-in detection and/or repair mechan= ism > resulting in sustained instability. > > > > May be I2RS clients need to get =E2=80=98permission=E2=80=99 from an orch= estrator or =E2=80=9Can > I2RS-coordinator=E2=80=9D before issuing =E2=80=98set=E2=80=99 operations= to I2RS agent? > > > > /himanshu > > > > > > > > From: Alia Atlas [mailto:akatlas@gmail.com] > Sent: Wednesday, November 06, 2013 1:30 PM > To: Russ White > Cc: Joel M. Halpern; i2rs@ietf.org; Shah, Himanshu > > > Subject: Re: [i2rs] question on I2RS architecture > > > > This is an aspect of the unexpected interactions problem. There's text i= n > the architecture saying that these can happen. This was offered for > discussion on the list to resounding silence. > > We can't reasonably solve this distributed problem from the vantage of a > particular network element, which is what an I2RS agent has. > > Alia > > On Nov 6, 2013 9:19 AM, "Russ White" wrote: > > > The problem with enforcing consistency in this environment is it would be > just as impossible to attain as it is with a distributed control plane in > real time. It seems, to me, that we can provide an interface, but the > controller/software doing the controlling must do the consistency insuran= ce, > just as routing protocols do today... > > :-) > > Russ > > <>< > russw@riw.us > Ericsson > >> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" wrote: >> >> I was not alluding to malicious use but genuine use of I2rs interface in >> the absence of >> complete view of the latest network topology and/or view of what other >> I2RS client >> are doing or are about to do. There needs to be safeguards. I2RS needs t= o >> address >> consistency verification aspects. >> >> If that is offloaded to some other entity, I2RS arch spec needs to >> explicitly mention that. >> >> /himanshu >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, November 06, 2013 11:55 AM >> To: Shah, Himanshu; i2rs@ietf.org >> Subject: Re: [i2rs] question on I2RS architecture >> >> If someone wants to create inconsistency using I2RS, we won't stop them. >> And although there was opne request for very precise timing on operation= s, >> that seems to me to be a step too far. >> >> Yours, >> Joel >> >>> On 11/5/13 9:07 PM, Shah, Himanshu wrote: >>> /At the IETF I2RS interim meeting, I raised the concern about >>> conflicting set operations by I2RS clients to different I2RS agents,/ >>> >>> /Which may end up causing micro-loop or far-side loop. / >>> >>> // >>> >>> /Is this addressed in the architecture? / >>> >>> /May be this is responsibility of network orchestrator./ >>> >>> /If it is not mentioned in the doc, may be some text necessary to >>> explain??/ >>> >>> // >>> >>> /Thanks,/ >>> >>> /himanshu/ >>> >>> // >>> >>> /Himanshu Shah/ >>> >>> /Ciena Corp/ >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From prvs=80222f09cc=hshah@ciena.com Wed Nov 6 13:07:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE89521F9985 for ; Wed, 6 Nov 2013 13:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMni61G3HH+x for ; Wed, 6 Nov 2013 13:06:47 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id E793B21E81A2 for ; Wed, 6 Nov 2013 13:06:42 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id rA6L4cOK017115; Wed, 6 Nov 2013 16:06:38 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1fye5538n7-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Nov 2013 16:06:38 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 6 Nov 2013 16:06:36 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 6 Nov 2013 16:06:30 -0500 From: "Shah, Himanshu" To: Sriganesh Kini Date: Wed, 6 Nov 2013 16:06:27 -0500 Thread-Topic: [i2rs] question on I2RS architecture Thread-Index: Ac7bMNckWbk/13HlTcCWoeNm4qk0BwAAl+RQ Message-ID: <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20274.000 X-TM-AS-Result: No--36.697200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-06_05:2013-11-06, 2013-11-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311060174 Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:07:07 -0000 SSBkb24ndCB0aGluayBzbyAoYXBwbGVzIHZzIG9yYW5nZXMpLg0KTm90IHN1cmUgaWYgeW91IGdv dCB0aGUgcG9pbnQgSSBtYWRlLg0KSXQgaXMgbm90IGFib3V0IGNsaWVudCA8LT4gYWdlbnQgdHJh bnNhY3Rpb24gaW50ZWdyaXR5Lg0KSXQgaXMgYWJvdXQgZGlmZmVyZW50IGNsaWVudHMgdGFsa2lu ZyB0byBkaWZmZXJlbnQgYWdlbnRzIGFuZCBtYWtpbmcgc3VyZSBhYm91dCB0aGUgbmV0d29yayB3 aWRlIGNvbnNpc3RlbmN5Lg0KSWYgdGhlcmUgaXMgb25seSBvbmUgY2xpZW50IHRhbGtpbmcgdG8g YWxsIGFnZW50cywgdGhlbiB5b3VyIHBvaW50IHN0YW5kcywgYnV0IHRoYXQgaXMgbm90IHdoYXQg SSB3YXMgZGlzY3Vzc2luZy4NCg0KL2hpbWFuc2h1DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHNyaWdhbmVzaGtpbmlAZ21haWwuY29tIFttYWlsdG86c3JpZ2FuZXNoa2lu aUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBTcmlnYW5lc2ggS2luaQ0KU2VudDogV2VkbmVzZGF5 LCBOb3ZlbWJlciAwNiwgMjAxMyAzOjQzIFBNDQpUbzogU2hhaCwgSGltYW5zaHUNCkNjOiBBbGlh IEF0bGFzOyBSdXNzIFdoaXRlOyBpMnJzQGlldGYub3JnOyBKb2VsIE0uIEhhbHBlcm4NClN1Ympl Y3Q6IFJlOiBbaTJyc10gcXVlc3Rpb24gb24gSTJSUyBhcmNoaXRlY3R1cmUNCg0KSGltYW5zaHUs DQoNCkl0IHNlZW1zIGxpa2UgeW91IGFyZSBjb21wYXJpbmcgYXBwbGVzIHRvIG9yYW5nZXMgd2hl biB5b3UgY29tcGFyZSBhIGRpc3RyaWJ1dGVkIHJvdXRpbmcgcHJvdG9jb2wgdG8gdGhlIGludGVy ZmFjZSB0byB0aGUgcm91dGluZyBzeXN0ZW0uDQoNCklmIGl0IGhlbHBzIGFueSwgdGFrZSBhIGxv b2sgYXQgRmlnIDEuIG9mIGRyYWZ0LWlldGYtaTJycy1yaWItaW5mby1tb2RlbC4gVGhlIGRpc3Ry aWJ1dGVkIHJvdXRpbmcgcHJvdG9jb2wgd291bGQgYmUgYSBjbGllbnQuIFRoZSBJMlJTIGFnZW50 IChub3Qgc2hvd24gaW4gdGhhdCBGaWcpIHdvdWxkIHByb3ZpZGUgdGhlIGludGVyZmFjZSBmcm9t IHRoZSBjbGllbnQgdG93YXJkcyB0aGUgUm91dGluZyBTeXN0ZW0gKGluIHRoZSBjb250ZXh0IG9m IHRoaXMgZHJhZnQsIHRoaXMgaXMgdGhlIFJJQikuIEp1c3QgYXMgYSByb3V0aW5nLXByb3RvY29s IG1heSBoYXZlIGFuIGV2ZW50dWFsLWNvbnNpc3RlbmN5IG1vZGVsLCBhbnkgbmV3IGNsaWVudCB1 c2luZyB0aGUgSTJSUyBpbnRlcmZhY2Ugd291bGQgaGF2ZSB0byBkZXNpZ24gaXRzIG93biBjb25z aXN0ZW5jeSBtb2RlbC4gVGhlIGNsaWVudCBjYW4gdXNlIG1lY2hhbmlzbXMgc3VjaCBhcyB0cmFu c2FjdGlvbnMgKHNlYyA2Ljkgb2YNCmRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUpIHRvd2Fy ZHMgdGhhdC4NCg0KLSBTcmkNCg0KDQpPbiBXZWQsIE5vdiA2LCAyMDEzIGF0IDExOjQ1IEFNLCBT aGFoLCBIaW1hbnNodSA8aHNoYWhAY2llbmEuY29tPiB3cm90ZToNCj4gV291bGRu4oCZdCB0aGlz IGJlIGEgc3R1bWJsaW5nIGJsb2NrIGZvciBJMlJTIGFyY2hpdGVjdHVyZT8gKHNvcnJ5IGZvciAN Cj4gaGF2aW5nIG1pc3NlZCB0aGUgZGlzY3Vzc2lvbiBvbiBtYWlsaW5nIGxpc3Qgb24gdGhpcyBp c3N1ZSkuDQo+DQo+IEluIGRpc3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHRyYW5zaWVudCBpbmNv bnNpc3RlbmNpZXMgYXJlIHJlcGFpcmVkIA0KPiBldmVudHVhbGx5IChvbmNlIGV2ZXJ5IG5vZGUg aGFzIHVwZGF0ZWQgdG9wbyBpbmZvKS4NCj4NCj4gSSBhbSBub3Qgc3VyZSBJMlJTIG1lY2hhbmlz bXMgaGFzIGJ1aWx0LWluIGRldGVjdGlvbiBhbmQvb3IgcmVwYWlyIA0KPiBtZWNoYW5pc20gcmVz dWx0aW5nIGluIHN1c3RhaW5lZCBpbnN0YWJpbGl0eS4NCj4NCj4NCj4NCj4gTWF5IGJlIEkyUlMg Y2xpZW50cyBuZWVkIHRvIGdldCDigJhwZXJtaXNzaW9u4oCZIGZyb20gYW4gb3JjaGVzdHJhdG9y IG9yIA0KPiDigJxhbiBJMlJTLWNvb3JkaW5hdG9y4oCdIGJlZm9yZSBpc3N1aW5nIOKAmHNldOKA mSBvcGVyYXRpb25zIHRvIEkyUlMgYWdlbnQ/DQo+DQo+DQo+DQo+IC9oaW1hbnNodQ0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KPiBGcm9tOiBBbGlhIEF0bGFzIFttYWlsdG86YWthdGxhc0BnbWFpbC5j b21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMTozMCBQTQ0KPiBUbzog UnVzcyBXaGl0ZQ0KPiBDYzogSm9lbCBNLiBIYWxwZXJuOyBpMnJzQGlldGYub3JnOyBTaGFoLCBI aW1hbnNodQ0KPg0KPg0KPiBTdWJqZWN0OiBSZTogW2kycnNdIHF1ZXN0aW9uIG9uIEkyUlMgYXJj aGl0ZWN0dXJlDQo+DQo+DQo+DQo+IFRoaXMgaXMgYW4gYXNwZWN0IG9mIHRoZSB1bmV4cGVjdGVk IGludGVyYWN0aW9ucyBwcm9ibGVtLiAgVGhlcmUncyB0ZXh0IGluDQo+IHRoZSBhcmNoaXRlY3R1 cmUgc2F5aW5nIHRoYXQgdGhlc2UgY2FuIGhhcHBlbi4gICBUaGlzIHdhcyBvZmZlcmVkIGZvcg0K PiBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IHRvIHJlc291bmRpbmcgc2lsZW5jZS4NCj4NCj4gV2Ug Y2FuJ3QgcmVhc29uYWJseSBzb2x2ZSB0aGlzIGRpc3RyaWJ1dGVkIHByb2JsZW0gZnJvbSB0aGUg dmFudGFnZSBvZiANCj4gYSBwYXJ0aWN1bGFyIG5ldHdvcmsgZWxlbWVudCwgd2hpY2ggaXMgd2hh dCBhbiBJMlJTIGFnZW50IGhhcy4NCj4NCj4gQWxpYQ0KPg0KPiBPbiBOb3YgNiwgMjAxMyA5OjE5 IEFNLCAiUnVzcyBXaGl0ZSIgPHJ1c3N3QHJpdy51cz4gd3JvdGU6DQo+DQo+DQo+IFRoZSBwcm9i bGVtIHdpdGggZW5mb3JjaW5nIGNvbnNpc3RlbmN5IGluIHRoaXMgZW52aXJvbm1lbnQgaXMgaXQg d291bGQgDQo+IGJlIGp1c3QgYXMgaW1wb3NzaWJsZSB0byBhdHRhaW4gYXMgaXQgaXMgd2l0aCBh IGRpc3RyaWJ1dGVkIGNvbnRyb2wgDQo+IHBsYW5lIGluIHJlYWwgdGltZS4gSXQgc2VlbXMsIHRv IG1lLCB0aGF0IHdlIGNhbiBwcm92aWRlIGFuIGludGVyZmFjZSwgDQo+IGJ1dCB0aGUgY29udHJv bGxlci9zb2Z0d2FyZSBkb2luZyB0aGUgY29udHJvbGxpbmcgbXVzdCBkbyB0aGUgDQo+IGNvbnNp c3RlbmN5IGluc3VyYW5jZSwganVzdCBhcyByb3V0aW5nIHByb3RvY29scyBkbyB0b2RheS4uLg0K Pg0KPiA6LSkNCj4NCj4gUnVzcw0KPg0KPiA8PjwNCj4gcnVzc3dAcml3LnVzDQo+IEVyaWNzc29u DQo+DQo+PiBPbiBOb3YgNiwgMjAxMywgYXQgOToxMSBBTSwgIlNoYWgsIEhpbWFuc2h1IiA8aHNo YWhAY2llbmEuY29tPiB3cm90ZToNCj4+DQo+PiBJIHdhcyBub3QgYWxsdWRpbmcgdG8gbWFsaWNp b3VzIHVzZSBidXQgZ2VudWluZSB1c2Ugb2YgSTJycyBpbnRlcmZhY2UgDQo+PiBpbiB0aGUgYWJz ZW5jZSBvZiBjb21wbGV0ZSB2aWV3IG9mIHRoZSBsYXRlc3QgbmV0d29yayB0b3BvbG9neSBhbmQv b3IgDQo+PiB2aWV3IG9mIHdoYXQgb3RoZXIgSTJSUyBjbGllbnQgYXJlIGRvaW5nIG9yIGFyZSBh Ym91dCB0byBkby4gVGhlcmUgDQo+PiBuZWVkcyB0byBiZSBzYWZlZ3VhcmRzLiBJMlJTIG5lZWRz IHRvIGFkZHJlc3MgY29uc2lzdGVuY3kgDQo+PiB2ZXJpZmljYXRpb24gYXNwZWN0cy4NCj4+DQo+ PiBJZiB0aGF0IGlzIG9mZmxvYWRlZCB0byBzb21lIG90aGVyIGVudGl0eSwgSTJSUyBhcmNoIHNw ZWMgbmVlZHMgdG8gDQo+PiBleHBsaWNpdGx5IG1lbnRpb24gdGhhdC4NCj4+DQo+PiAvaGltYW5z aHUNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogSm9lbCBNLiBI YWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+IFNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgMDYsIDIwMTMgMTE6NTUgQU0NCj4+IFRvOiBTaGFoLCBIaW1hbnNodTsgaTJyc0Bp ZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtpMnJzXSBxdWVzdGlvbiBvbiBJMlJTIGFyY2hpdGVj dHVyZQ0KPj4NCj4+IElmIHNvbWVvbmUgd2FudHMgdG8gY3JlYXRlIGluY29uc2lzdGVuY3kgdXNp bmcgSTJSUywgd2Ugd29uJ3Qgc3RvcCB0aGVtLg0KPj4gQW5kIGFsdGhvdWdoIHRoZXJlIHdhcyBv cG5lIHJlcXVlc3QgZm9yIHZlcnkgcHJlY2lzZSB0aW1pbmcgb24gDQo+PiBvcGVyYXRpb25zLCB0 aGF0IHNlZW1zIHRvIG1lIHRvIGJlIGEgc3RlcCB0b28gZmFyLg0KPj4NCj4+IFlvdXJzLA0KPj4g Sm9lbA0KPj4NCj4+PiBPbiAxMS81LzEzIDk6MDcgUE0sIFNoYWgsIEhpbWFuc2h1IHdyb3RlOg0K Pj4+IC9BdCB0aGUgSUVURiBJMlJTIGludGVyaW0gbWVldGluZywgSSByYWlzZWQgdGhlIGNvbmNl cm4gYWJvdXQgDQo+Pj4gY29uZmxpY3Rpbmcgc2V0IG9wZXJhdGlvbnMgYnkgSTJSUyBjbGllbnRz IHRvIGRpZmZlcmVudCBJMlJTIA0KPj4+IGFnZW50cywvDQo+Pj4NCj4+PiAvV2hpY2ggbWF5IGVu ZCB1cCBjYXVzaW5nIG1pY3JvLWxvb3Agb3IgZmFyLXNpZGUgbG9vcC4gLw0KPj4+DQo+Pj4gLy8N Cj4+Pg0KPj4+IC9JcyB0aGlzIGFkZHJlc3NlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlPyAvDQo+Pj4N Cj4+PiAvTWF5IGJlIHRoaXMgaXMgcmVzcG9uc2liaWxpdHkgb2YgbmV0d29yayBvcmNoZXN0cmF0 b3IuLw0KPj4+DQo+Pj4gL0lmIGl0IGlzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRvYywgbWF5IGJl IHNvbWUgdGV4dCBuZWNlc3NhcnkgdG8gDQo+Pj4gZXhwbGFpbj8/Lw0KPj4+DQo+Pj4gLy8NCj4+ Pg0KPj4+IC9UaGFua3MsLw0KPj4+DQo+Pj4gL2hpbWFuc2h1Lw0KPj4+DQo+Pj4gLy8NCj4+Pg0K Pj4+IC9IaW1hbnNodSBTaGFoLw0KPj4+DQo+Pj4gL0NpZW5hIENvcnAvDQo+Pj4NCj4+Pg0KPj4+ DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+IGkycnNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4gaTJyc0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGkycnMg bWFpbGluZyBsaXN0DQo+IGkycnNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMnJzDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGkycnMgbWFpbGluZyBsaXN0DQo+IGkycnNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+DQo= From sriganeshkini@gmail.com Wed Nov 6 13:35:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A2F21E8198 for ; Wed, 6 Nov 2013 13:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgSZwA6-06i5 for ; Wed, 6 Nov 2013 13:35:52 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5677421E81A7 for ; Wed, 6 Nov 2013 13:35:52 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so97009pbb.29 for ; Wed, 06 Nov 2013 13:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=FZfGf6AYvcpleyys8Jeie2JczRYZBEgx6TxlF8d2XiE=; b=FJfM5WUL6PPXe/lkprDwFDFSYrY1Borh4VTuvdjdlzgMAggF2Zqf4pFQ+pv86xswwu f6P7naY6gKsFkEdxBZtYDYfz0lvHoxo8VqzTrZsPi17kaYrEBP+kmWmhmTrqB2hBZKgz KRYjWcvc3THE+BB0aXhVs10Bgwgy0M/QsUvLZsGeMFixa4ZL3CY4SrJc00/Yaut3DDdN VGUSG1HZ8EZ0IL9u0uyBz/4uny595lCKKFxAVTia65jPUHtgyL5qa/DkcG7b0sQblKMj U7BarvFqB5nt9q0jYfNtzxA6bCSgc2DOHDKd1IQ0yDLroRtRYEVlma6ktLf/1AO7res1 CvTA== X-Received: by 10.69.20.10 with SMTP id gy10mr3419176pbd.201.1383773751820; Wed, 06 Nov 2013 13:35:51 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Wed, 6 Nov 2013 13:35:21 -0800 (PST) In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> From: Sriganesh Kini Date: Wed, 6 Nov 2013 13:35:21 -0800 X-Google-Sender-Auth: 0odN-inmnS0ryRopsBdaSJHVtu4 Message-ID: To: "Shah, Himanshu" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:35:53 -0000 I2RS does not provide a single transaction spanning multiple I2RS agents. Though a client may use I2RS to read state from an I2RS-agent that was installed by another client via I2RS, ensuring consistency of that state network-wide is completely up to the clients and is outside the scope of I2RS architecture. On Wed, Nov 6, 2013 at 1:06 PM, Shah, Himanshu wrote: > I don't think so (apples vs oranges). > Not sure if you got the point I made. > It is not about client <-> agent transaction integrity. > It is about different clients talking to different agents and making sure= about the network wide consistency. > If there is only one client talking to all agents, then your point stands= , but that is not what I was discussing. > > /himanshu > > > -----Original Message----- > From: sriganeshkini@gmail.com [mailto:sriganeshkini@gmail.com] On Behalf = Of Sriganesh Kini > Sent: Wednesday, November 06, 2013 3:43 PM > To: Shah, Himanshu > Cc: Alia Atlas; Russ White; i2rs@ietf.org; Joel M. Halpern > Subject: Re: [i2rs] question on I2RS architecture > > Himanshu, > > It seems like you are comparing apples to oranges when you compare a dist= ributed routing protocol to the interface to the routing system. > > If it helps any, take a look at Fig 1. of draft-ietf-i2rs-rib-info-model.= The distributed routing protocol would be a client. The I2RS agent (not sh= own in that Fig) would provide the interface from the client towards the Ro= uting System (in the context of this draft, this is the RIB). Just as a rou= ting-protocol may have an eventual-consistency model, any new client using = the I2RS interface would have to design its own consistency model. The clie= nt can use mechanisms such as transactions (sec 6.9 of > draft-ietf-i2rs-architecture) towards that. > > - Sri > > > On Wed, Nov 6, 2013 at 11:45 AM, Shah, Himanshu wrote: >> Wouldn=E2=80=99t this be a stumbling block for I2RS architecture? (sorry= for >> having missed the discussion on mailing list on this issue). >> >> In distributed control plane, transient inconsistencies are repaired >> eventually (once every node has updated topo info). >> >> I am not sure I2RS mechanisms has built-in detection and/or repair >> mechanism resulting in sustained instability. >> >> >> >> May be I2RS clients need to get =E2=80=98permission=E2=80=99 from an orc= hestrator or >> =E2=80=9Can I2RS-coordinator=E2=80=9D before issuing =E2=80=98set=E2=80= =99 operations to I2RS agent? >> >> >> >> /himanshu >> >> >> >> >> >> >> >> From: Alia Atlas [mailto:akatlas@gmail.com] >> Sent: Wednesday, November 06, 2013 1:30 PM >> To: Russ White >> Cc: Joel M. Halpern; i2rs@ietf.org; Shah, Himanshu >> >> >> Subject: Re: [i2rs] question on I2RS architecture >> >> >> >> This is an aspect of the unexpected interactions problem. There's text = in >> the architecture saying that these can happen. This was offered for >> discussion on the list to resounding silence. >> >> We can't reasonably solve this distributed problem from the vantage of >> a particular network element, which is what an I2RS agent has. >> >> Alia >> >> On Nov 6, 2013 9:19 AM, "Russ White" wrote: >> >> >> The problem with enforcing consistency in this environment is it would >> be just as impossible to attain as it is with a distributed control >> plane in real time. It seems, to me, that we can provide an interface, >> but the controller/software doing the controlling must do the >> consistency insurance, just as routing protocols do today... >> >> :-) >> >> Russ >> >> <>< >> russw@riw.us >> Ericsson >> >>> On Nov 6, 2013, at 9:11 AM, "Shah, Himanshu" wrote: >>> >>> I was not alluding to malicious use but genuine use of I2rs interface >>> in the absence of complete view of the latest network topology and/or >>> view of what other I2RS client are doing or are about to do. There >>> needs to be safeguards. I2RS needs to address consistency >>> verification aspects. >>> >>> If that is offloaded to some other entity, I2RS arch spec needs to >>> explicitly mention that. >>> >>> /himanshu >>> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Wednesday, November 06, 2013 11:55 AM >>> To: Shah, Himanshu; i2rs@ietf.org >>> Subject: Re: [i2rs] question on I2RS architecture >>> >>> If someone wants to create inconsistency using I2RS, we won't stop them= . >>> And although there was opne request for very precise timing on >>> operations, that seems to me to be a step too far. >>> >>> Yours, >>> Joel >>> >>>> On 11/5/13 9:07 PM, Shah, Himanshu wrote: >>>> /At the IETF I2RS interim meeting, I raised the concern about >>>> conflicting set operations by I2RS clients to different I2RS >>>> agents,/ >>>> >>>> /Which may end up causing micro-loop or far-side loop. / >>>> >>>> // >>>> >>>> /Is this addressed in the architecture? / >>>> >>>> /May be this is responsibility of network orchestrator./ >>>> >>>> /If it is not mentioned in the doc, may be some text necessary to >>>> explain??/ >>>> >>>> // >>>> >>>> /Thanks,/ >>>> >>>> /himanshu/ >>>> >>>> // >>>> >>>> /Himanshu Shah/ >>>> >>>> /Ciena Corp/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Wed Nov 6 13:48:37 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87B421E81A3 for ; Wed, 6 Nov 2013 13:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnOHlz493i+X for ; Wed, 6 Nov 2013 13:48:26 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0A06C21E811C for ; Wed, 6 Nov 2013 13:48:20 -0800 (PST) Received: from [64.114.24.114] (port=51773 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VeAxV-0002F1-Lt; Wed, 06 Nov 2013 21:48:18 +0000 From: "Russ White" To: "'Sriganesh Kini'" , "'Shah, Himanshu'" References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> In-Reply-To: Date: Wed, 6 Nov 2013 16:48:22 -0500 Message-ID: <01dd01cedb39$eb5e2ec0$c21a8c40$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJi5jBr4PwRStQknEOpd7c8VNPuqAJTA2vtAiJkXIwBLcwT0wJC1kgoAsMU46EBfhjyBwGpiXKeAaEL+IGYdRXucA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , 'Alia Atlas' Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:48:38 -0000 > May be I2RS clients need to get =E2=80=98permission=E2=80=99 from an = orchestrator or > =E2=80=9Can I2RS-coordinator=E2=80=9D before issuing = =E2=80=98set=E2=80=99 operations to I2RS agent? Backing up a little in the thread --this, specifically, is what we want = to avoid. We don't want a "lock/release," or a transaction oriented = protocol to ensure referential integrity across all devices in the I2RS = domain.=20 Maybe an illustration would help: Does the OSPF to RIB interface ensure = referential integrity among all the routers within a single OSPF = flooding domain? No... the forwarding plane on each device counts on = OSPF to ensure integrity (and, BTW, OSPF doesn't ensure perfect real = time integrity -- take a look at the work going on in fast reroute and = ordered FIB as examples of narrowing the window of time during which the = link state topology and the real world topology are not congruent). In = the same way, the integrity or loopfreeness of the routes calculated by = the control plane -- some process residing on the client -- is not = something the interface between the client and the agent can, or should, = handle. It's up to the creator of the protocol running in that process = to ensure things are being forwarded correctly, etc. If you're trying to prevent order of operation issues, again this is no = different than the problem of microloops in any link state protocol, or = the BGP hunt convergence, or BGP flipping back and forth between two = different routes. The protocols can be fixed to stop this sort of stuff, = but that's a protocol level problem, not a problem to be addressed by = making all BGP processes check with a central process before installing = a route in a local RIB. So no, there's protection against such things with the I2RS charter, or = any of the drafts (that I know of) so far. And I, for one, would = actually object to such a thing -- because it adds a level of complexity = into I2RS that should rightfully live someplace else in the system -- = specifically within the control plane(s) driving I2RS. HTH :-) Russ From eosborne@cisco.com Wed Nov 6 14:45:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993DA21F9C72 for ; Wed, 6 Nov 2013 14:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc98fgkkWlYX for ; Wed, 6 Nov 2013 14:45:44 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 612FD21F9F9D for ; Wed, 6 Nov 2013 14:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8688; q=dns/txt; s=iport; t=1383777944; x=1384987544; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AEO8A776jXQtxjafBe3KKedRjDwOLSps1iQuMZ9OgDg=; b=cMPTsXWvS/opFnJs/WICNJ9UgwW4Xiq+XYVVZQtkAuvMvd7a/uT9CHPv 3geLqnHLlU3m511jK/bFrv/KGSk1yd/icKYDYy940jQWy2jIHbUT3j/ms Q4ac7WlgVSFwuInuzJganPO+ZG+QYgy2L+7P55Mt/BmPLg6Gkl06XdLLx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJHFelKtJV2b/2dsb2JhbABbgwc4U4MIvCUYgQ8WdIIlAQEBBAEBASAEDToLDAQCAQgRAQMBAQECAgYdAwICAh8GCxQBAgYIAgQBDQUIh2cDDw2sS4hFDYlnBIEpiz6CQRYbBwaCZTWBEAOWIY49hTiDJoIq X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="278666240" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 06 Nov 2013 22:45:43 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA6MjhrQ031522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 22:45:43 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 16:45:43 -0600 From: "Eric Osborne (eosborne)" To: "Shah, Himanshu" , Sriganesh Kini Thread-Topic: [i2rs] question on I2RS architecture Thread-Index: Ac7alFO4qVZMswW2TqiS1gRfl+CkNQArtQ8AAACZCYAAAEJ1gAACfZ8AAAKjLIAAAfuvAAAA1FeAAAkvzlA= Date: Wed, 6 Nov 2013 22:45:42 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210456B92@xmb-rcd-x09.cisco.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:45:49 -0000 aTJycyBpcyBiYXNpY2FsbHkgYW4gQVBJIGludG8gdGhlIHJvdXRlci4gIEkgdGhpbmsgd2hhdCB5 b3UncmUgbG9va2luZyBmb3IgaXMgYW4gYXBpIGludG8gdGhlIG5ldHdvcmsgYXMgYSB3aG9sZS4g IEkgaGF2ZSB5ZXQgdG8gZ3JvayBhbGwgdGhlIGkycnMgZG9jcyBidXQgc29tZXRoaW5nIGxpa2Ug dGhhdCBzZWVtcyB2ZXJ5IGNsZWFybHkgU29tZWJvZHkgRWxzZSdzIFByb2JsZW0gLSB0aGF0IGlz LCBvdXQgb2Ygc2NvcGUuDQoNCg0KDQoNCmVyaWMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpMnJzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppMnJzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBTaGFoLCBIaW1hbnNodQ0KPiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDA2LCAyMDEzIDE6MDYgUE0NCj4gVG86IFNyaWdhbmVzaCBLaW5pDQo+IENj OiBSdXNzIFdoaXRlOyBpMnJzQGlldGYub3JnOyBKb2VsIE0uIEhhbHBlcm47IEFsaWEgQXRsYXMN Cj4gU3ViamVjdDogUmU6IFtpMnJzXSBxdWVzdGlvbiBvbiBJMlJTIGFyY2hpdGVjdHVyZQ0KPiAN Cj4gSSBkb24ndCB0aGluayBzbyAoYXBwbGVzIHZzIG9yYW5nZXMpLg0KPiBOb3Qgc3VyZSBpZiB5 b3UgZ290IHRoZSBwb2ludCBJIG1hZGUuDQo+IEl0IGlzIG5vdCBhYm91dCBjbGllbnQgPC0+IGFn ZW50IHRyYW5zYWN0aW9uIGludGVncml0eS4NCj4gSXQgaXMgYWJvdXQgZGlmZmVyZW50IGNsaWVu dHMgdGFsa2luZyB0byBkaWZmZXJlbnQgYWdlbnRzIGFuZCBtYWtpbmcNCj4gc3VyZSBhYm91dCB0 aGUgbmV0d29yayB3aWRlIGNvbnNpc3RlbmN5Lg0KPiBJZiB0aGVyZSBpcyBvbmx5IG9uZSBjbGll bnQgdGFsa2luZyB0byBhbGwgYWdlbnRzLCB0aGVuIHlvdXIgcG9pbnQNCj4gc3RhbmRzLCBidXQg dGhhdCBpcyBub3Qgd2hhdCBJIHdhcyBkaXNjdXNzaW5nLg0KPiANCj4gL2hpbWFuc2h1DQo+IA0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc3JpZ2FuZXNoa2luaUBn bWFpbC5jb20gW21haWx0bzpzcmlnYW5lc2hraW5pQGdtYWlsLmNvbV0gT24gQmVoYWxmDQo+IE9m IFNyaWdhbmVzaCBLaW5pDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMzo0 MyBQTQ0KPiBUbzogU2hhaCwgSGltYW5zaHUNCj4gQ2M6IEFsaWEgQXRsYXM7IFJ1c3MgV2hpdGU7 IGkycnNAaWV0Zi5vcmc7IEpvZWwgTS4gSGFscGVybg0KPiBTdWJqZWN0OiBSZTogW2kycnNdIHF1 ZXN0aW9uIG9uIEkyUlMgYXJjaGl0ZWN0dXJlDQo+IA0KPiBIaW1hbnNodSwNCj4gDQo+IEl0IHNl ZW1zIGxpa2UgeW91IGFyZSBjb21wYXJpbmcgYXBwbGVzIHRvIG9yYW5nZXMgd2hlbiB5b3UgY29t cGFyZSBhDQo+IGRpc3RyaWJ1dGVkIHJvdXRpbmcgcHJvdG9jb2wgdG8gdGhlIGludGVyZmFjZSB0 byB0aGUgcm91dGluZyBzeXN0ZW0uDQo+IA0KPiBJZiBpdCBoZWxwcyBhbnksIHRha2UgYSBsb29r IGF0IEZpZyAxLiBvZiBkcmFmdC1pZXRmLWkycnMtcmliLWluZm8tDQo+IG1vZGVsLiBUaGUgZGlz dHJpYnV0ZWQgcm91dGluZyBwcm90b2NvbCB3b3VsZCBiZSBhIGNsaWVudC4gVGhlIEkyUlMNCj4g YWdlbnQgKG5vdCBzaG93biBpbiB0aGF0IEZpZykgd291bGQgcHJvdmlkZSB0aGUgaW50ZXJmYWNl IGZyb20gdGhlDQo+IGNsaWVudCB0b3dhcmRzIHRoZSBSb3V0aW5nIFN5c3RlbSAoaW4gdGhlIGNv bnRleHQgb2YgdGhpcyBkcmFmdCwgdGhpcyBpcw0KPiB0aGUgUklCKS4gSnVzdCBhcyBhIHJvdXRp bmctcHJvdG9jb2wgbWF5IGhhdmUgYW4gZXZlbnR1YWwtY29uc2lzdGVuY3kNCj4gbW9kZWwsIGFu eSBuZXcgY2xpZW50IHVzaW5nIHRoZSBJMlJTIGludGVyZmFjZSB3b3VsZCBoYXZlIHRvIGRlc2ln biBpdHMNCj4gb3duIGNvbnNpc3RlbmN5IG1vZGVsLiBUaGUgY2xpZW50IGNhbiB1c2UgbWVjaGFu aXNtcyBzdWNoIGFzDQo+IHRyYW5zYWN0aW9ucyAoc2VjIDYuOSBvZg0KPiBkcmFmdC1pZXRmLWky cnMtYXJjaGl0ZWN0dXJlKSB0b3dhcmRzIHRoYXQuDQo+IA0KPiAtIFNyaQ0KPiANCj4gDQo+IE9u IFdlZCwgTm92IDYsIDIwMTMgYXQgMTE6NDUgQU0sIFNoYWgsIEhpbWFuc2h1IDxoc2hhaEBjaWVu YS5jb20+IHdyb3RlOg0KPiA+IFdvdWxkbuKAmXQgdGhpcyBiZSBhIHN0dW1ibGluZyBibG9jayBm b3IgSTJSUyBhcmNoaXRlY3R1cmU/IChzb3JyeSBmb3INCj4gPiBoYXZpbmcgbWlzc2VkIHRoZSBk aXNjdXNzaW9uIG9uIG1haWxpbmcgbGlzdCBvbiB0aGlzIGlzc3VlKS4NCj4gPg0KPiA+IEluIGRp c3RyaWJ1dGVkIGNvbnRyb2wgcGxhbmUsIHRyYW5zaWVudCBpbmNvbnNpc3RlbmNpZXMgYXJlIHJl cGFpcmVkDQo+ID4gZXZlbnR1YWxseSAob25jZSBldmVyeSBub2RlIGhhcyB1cGRhdGVkIHRvcG8g aW5mbykuDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJlIEkyUlMgbWVjaGFuaXNtcyBoYXMgYnVpbHQt aW4gZGV0ZWN0aW9uIGFuZC9vciByZXBhaXINCj4gPiBtZWNoYW5pc20gcmVzdWx0aW5nIGluIHN1 c3RhaW5lZCBpbnN0YWJpbGl0eS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBNYXkgYmUgSTJSUyBjbGll bnRzIG5lZWQgdG8gZ2V0IOKAmHBlcm1pc3Npb27igJkgZnJvbSBhbiBvcmNoZXN0cmF0b3Igb3IN Cj4gPiDigJxhbiBJMlJTLWNvb3JkaW5hdG9y4oCdIGJlZm9yZSBpc3N1aW5nIOKAmHNldOKAmSBv cGVyYXRpb25zIHRvIEkyUlMgYWdlbnQ/DQo+ID4NCj4gPg0KPiA+DQo+ID4gL2hpbWFuc2h1DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBGcm9tOiBBbGlhIEF0bGFzIFtt YWlsdG86YWthdGxhc0BnbWFpbC5jb21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAw NiwgMjAxMyAxOjMwIFBNDQo+ID4gVG86IFJ1c3MgV2hpdGUNCj4gPiBDYzogSm9lbCBNLiBIYWxw ZXJuOyBpMnJzQGlldGYub3JnOyBTaGFoLCBIaW1hbnNodQ0KPiA+DQo+ID4NCj4gPiBTdWJqZWN0 OiBSZTogW2kycnNdIHF1ZXN0aW9uIG9uIEkyUlMgYXJjaGl0ZWN0dXJlDQo+ID4NCj4gPg0KPiA+ DQo+ID4gVGhpcyBpcyBhbiBhc3BlY3Qgb2YgdGhlIHVuZXhwZWN0ZWQgaW50ZXJhY3Rpb25zIHBy b2JsZW0uICBUaGVyZSdzDQo+IHRleHQgaW4NCj4gPiB0aGUgYXJjaGl0ZWN0dXJlIHNheWluZyB0 aGF0IHRoZXNlIGNhbiBoYXBwZW4uICAgVGhpcyB3YXMgb2ZmZXJlZCBmb3INCj4gPiBkaXNjdXNz aW9uIG9uIHRoZSBsaXN0IHRvIHJlc291bmRpbmcgc2lsZW5jZS4NCj4gPg0KPiA+IFdlIGNhbid0 IHJlYXNvbmFibHkgc29sdmUgdGhpcyBkaXN0cmlidXRlZCBwcm9ibGVtIGZyb20gdGhlIHZhbnRh Z2Ugb2YNCj4gPiBhIHBhcnRpY3VsYXIgbmV0d29yayBlbGVtZW50LCB3aGljaCBpcyB3aGF0IGFu IEkyUlMgYWdlbnQgaGFzLg0KPiA+DQo+ID4gQWxpYQ0KPiA+DQo+ID4gT24gTm92IDYsIDIwMTMg OToxOSBBTSwgIlJ1c3MgV2hpdGUiIDxydXNzd0ByaXcudXM+IHdyb3RlOg0KPiA+DQo+ID4NCj4g PiBUaGUgcHJvYmxlbSB3aXRoIGVuZm9yY2luZyBjb25zaXN0ZW5jeSBpbiB0aGlzIGVudmlyb25t ZW50IGlzIGl0IHdvdWxkDQo+ID4gYmUganVzdCBhcyBpbXBvc3NpYmxlIHRvIGF0dGFpbiBhcyBp dCBpcyB3aXRoIGEgZGlzdHJpYnV0ZWQgY29udHJvbA0KPiA+IHBsYW5lIGluIHJlYWwgdGltZS4g SXQgc2VlbXMsIHRvIG1lLCB0aGF0IHdlIGNhbiBwcm92aWRlIGFuIGludGVyZmFjZSwNCj4gPiBi dXQgdGhlIGNvbnRyb2xsZXIvc29mdHdhcmUgZG9pbmcgdGhlIGNvbnRyb2xsaW5nIG11c3QgZG8g dGhlDQo+ID4gY29uc2lzdGVuY3kgaW5zdXJhbmNlLCBqdXN0IGFzIHJvdXRpbmcgcHJvdG9jb2xz IGRvIHRvZGF5Li4uDQo+ID4NCj4gPiA6LSkNCj4gPg0KPiA+IFJ1c3MNCj4gPg0KPiA+IDw+PA0K PiA+IHJ1c3N3QHJpdy51cw0KPiA+IEVyaWNzc29uDQo+ID4NCj4gPj4gT24gTm92IDYsIDIwMTMs IGF0IDk6MTEgQU0sICJTaGFoLCBIaW1hbnNodSIgPGhzaGFoQGNpZW5hLmNvbT4gd3JvdGU6DQo+ ID4+DQo+ID4+IEkgd2FzIG5vdCBhbGx1ZGluZyB0byBtYWxpY2lvdXMgdXNlIGJ1dCBnZW51aW5l IHVzZSBvZiBJMnJzIGludGVyZmFjZQ0KPiA+PiBpbiB0aGUgYWJzZW5jZSBvZiBjb21wbGV0ZSB2 aWV3IG9mIHRoZSBsYXRlc3QgbmV0d29yayB0b3BvbG9neSBhbmQvb3INCj4gPj4gdmlldyBvZiB3 aGF0IG90aGVyIEkyUlMgY2xpZW50IGFyZSBkb2luZyBvciBhcmUgYWJvdXQgdG8gZG8uIFRoZXJl DQo+ID4+IG5lZWRzIHRvIGJlIHNhZmVndWFyZHMuIEkyUlMgbmVlZHMgdG8gYWRkcmVzcyBjb25z aXN0ZW5jeQ0KPiA+PiB2ZXJpZmljYXRpb24gYXNwZWN0cy4NCj4gPj4NCj4gPj4gSWYgdGhhdCBp cyBvZmZsb2FkZWQgdG8gc29tZSBvdGhlciBlbnRpdHksIEkyUlMgYXJjaCBzcGVjIG5lZWRzIHRv DQo+ID4+IGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0Lg0KPiA+Pg0KPiA+PiAvaGltYW5zaHUNCj4g Pj4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogSm9lbCBNLiBI YWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5 LCBOb3ZlbWJlciAwNiwgMjAxMyAxMTo1NSBBTQ0KPiA+PiBUbzogU2hhaCwgSGltYW5zaHU7IGky cnNAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtpMnJzXSBxdWVzdGlvbiBvbiBJMlJTIGFy Y2hpdGVjdHVyZQ0KPiA+Pg0KPiA+PiBJZiBzb21lb25lIHdhbnRzIHRvIGNyZWF0ZSBpbmNvbnNp c3RlbmN5IHVzaW5nIEkyUlMsIHdlIHdvbid0IHN0b3ANCj4gdGhlbS4NCj4gPj4gQW5kIGFsdGhv dWdoIHRoZXJlIHdhcyBvcG5lIHJlcXVlc3QgZm9yIHZlcnkgcHJlY2lzZSB0aW1pbmcgb24NCj4g Pj4gb3BlcmF0aW9ucywgdGhhdCBzZWVtcyB0byBtZSB0byBiZSBhIHN0ZXAgdG9vIGZhci4NCj4g Pj4NCj4gPj4gWW91cnMsDQo+ID4+IEpvZWwNCj4gPj4NCj4gPj4+IE9uIDExLzUvMTMgOTowNyBQ TSwgU2hhaCwgSGltYW5zaHUgd3JvdGU6DQo+ID4+PiAvQXQgdGhlIElFVEYgSTJSUyBpbnRlcmlt IG1lZXRpbmcsIEkgcmFpc2VkIHRoZSBjb25jZXJuIGFib3V0DQo+ID4+PiBjb25mbGljdGluZyBz ZXQgb3BlcmF0aW9ucyBieSBJMlJTIGNsaWVudHMgdG8gZGlmZmVyZW50IEkyUlMNCj4gPj4+IGFn ZW50cywvDQo+ID4+Pg0KPiA+Pj4gL1doaWNoIG1heSBlbmQgdXAgY2F1c2luZyBtaWNyby1sb29w IG9yIGZhci1zaWRlIGxvb3AuIC8NCj4gPj4+DQo+ID4+PiAvLw0KPiA+Pj4NCj4gPj4+IC9JcyB0 aGlzIGFkZHJlc3NlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlPyAvDQo+ID4+Pg0KPiA+Pj4gL01heSBi ZSB0aGlzIGlzIHJlc3BvbnNpYmlsaXR5IG9mIG5ldHdvcmsgb3JjaGVzdHJhdG9yLi8NCj4gPj4+ DQo+ID4+PiAvSWYgaXQgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgZG9jLCBtYXkgYmUgc29tZSB0 ZXh0IG5lY2Vzc2FyeSB0bw0KPiA+Pj4gZXhwbGFpbj8/Lw0KPiA+Pj4NCj4gPj4+IC8vDQo+ID4+ Pg0KPiA+Pj4gL1RoYW5rcywvDQo+ID4+Pg0KPiA+Pj4gL2hpbWFuc2h1Lw0KPiA+Pj4NCj4gPj4+ IC8vDQo+ID4+Pg0KPiA+Pj4gL0hpbWFuc2h1IFNoYWgvDQo+ID4+Pg0KPiA+Pj4gL0NpZW5hIENv cnAvDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gaTJycyBtYWlsaW5nIGxpc3QNCj4gPj4+IGky cnNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aTJycw0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiBpMnJzIG1haWxpbmcgbGlzdA0KPiA+PiBpMnJzQGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaTJycyBtYWlsaW5nIGxpc3QN Cj4gPiBpMnJzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pMnJzDQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gaTJycyBtYWlsaW5nIGxpc3QNCj4gPiBpMnJzQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+ID4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaTJycyBt YWlsaW5nIGxpc3QNCj4gaTJyc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2kycnMNCg== From linda.dunbar@huawei.com Wed Nov 6 17:11:51 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3C11E8209 for ; Wed, 6 Nov 2013 17:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MflrnFLwAuq7 for ; Wed, 6 Nov 2013 17:11:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2211E81D4 for ; Wed, 6 Nov 2013 17:11:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZY74506; Thu, 07 Nov 2013 01:11:41 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 01:10:53 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 01:11:37 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 17:11:25 -0800 From: Linda Dunbar To: Scott Whyte Thread-Topic: Filtering to draft-swhyte-i2rs-data-collection-system Thread-Index: Ac7bVkqynxZykwJdStSTdtSIP7MfzQ== Date: Thu, 7 Nov 2013 01:11:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BFDEBD@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.72] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645BFDEBDdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" , "Jixiaofeng \(Steven\)" , Yangang Subject: [i2rs] Filtering to draft-swhyte-i2rs-data-collection-system X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:11:51 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645BFDEBDdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, In addition RIB, there are much more data on router. "draft-jxf-i2rs-im-arc= hitecture-01" has identified many layers of information on routers, as show= n below. Do you need to get data on every layer? P-------------------------------------------------------------------- | Network Service Plane | L--------------------------------------------------------------- | | Network Service Layer | L--------------------------------------------------------------- | | Network Protocol Layer | L--------------------------------------------------------------- | | Network Resource Layer | L--------------------------------------------------------------- | | Network Policy Layer | L--------------------------------------------------------------- | | Network Container Layer | +--------------------------------------------------------------- P ------------------------------------------------------------------- | Infrastructure Plane | L--------------------------------------------------------------- | | System Management Layer | L--------------------------------------------------------------- | | System Inventory Objects Layer (Software and Hardware) | +--------------------------------------------------------------- | ------------------------------------------------------------------- Thanks, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645BFDEBDdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott,

 

In addition RIB, there= are much more data on router. “draft-jxf-i2rs-im-architecture-01R= 21; has identified many layers of information on routers, as shown below. D= o you need to get data on every layer?

 

 

P-------------------------------------------= -------------------------

| Network Service Plane

| L-----------------------------------------= ----------------------

| | Network Service Layer<= /p>

| L-----------------------------------------= ----------------------

| | Network Protocol Layer=

| L-----------------------------------------= ----------------------

| | Network Resource Layer=

| L-----------------------------------------= ----------------------

| | Network Policy Layer

| L-----------------------------------------= ----------------------

| | Network Container Layer

| +-------------------------------------= --------------------------

P ------------------------------------------= -------------------------

| Infrastructure Plane

| L-----------------------------------------= ----------------------

| | System Management Layer

| L-----------------------------------------= ----------------------

| | System Inventory Objects Layer (Software= and Hardware)

| +-------------------------------------= --------------------------

| ------------------------------------------= -------------------------

 

 

Thanks, Linda

--_000_4A95BA014132FF49AE685FAB4B9F17F645BFDEBDdfweml509mbxchi_-- From akatlas@gmail.com Wed Nov 6 18:23:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5514C11E81A7 for ; Wed, 6 Nov 2013 18:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGpz97pcIvO0 for ; Wed, 6 Nov 2013 18:23:18 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E20F111E8199 for ; Wed, 6 Nov 2013 18:23:17 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so663534iej.11 for ; Wed, 06 Nov 2013 18:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t4xS1y7y2xvdk6qq3a4uhRYMD8XudNqXp96pnwIBUDs=; b=zELJekK0dS+Gl6EwS2BA3Pb9KElV0hHgQ2dlP0QKAyRMEO3+pc7Ik+23CqOnSbJVqV J4gMYVaxVqSWbczxBbn5fWp5Tb0jT3F6MkLJm9Rry+hz88PamtF1wa4qHnnW7iczirRV 2mG/l0YS4Pd1i36sZnU+G2qNZRZnhx83yllMntV6RDPQzflRhzoCEJQpPo+O9wnWEH8m wKzZnamc8keRZrRASOxhHPKrpPtySoPHl3bTntSY4aeGDe1YDjIHOHKInYYELFpMcvJA QsMpMfvb2lDOln5T5+BheDmY8SgK97DB/hyIh1KqrIeARdXLuwWoz6L4Zib+X7NuZQaL SdOQ== MIME-Version: 1.0 X-Received: by 10.42.35.5 with SMTP id o5mr4163413icd.8.1383790997182; Wed, 06 Nov 2013 18:23:17 -0800 (PST) Received: by 10.64.78.103 with HTTP; Wed, 6 Nov 2013 18:23:17 -0800 (PST) Date: Wed, 6 Nov 2013 21:23:17 -0500 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba5bbabdd4f9c504ea8cf275 Subject: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 02:23:20 -0000 --90e6ba5bbabdd4f9c504ea8cf275 Content-Type: text/plain; charset=ISO-8859-1 I'd really like to start a conversation about the differences between a topology IM model that is network-centric vs. device-centric. Clearly the WG has strong and different opinions about it. Since many people are here in Vancouver, focused on IETF and not their day-jobs, this seems like a good time to get it rolling... Alia --90e6ba5bbabdd4f9c504ea8cf275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd really like to start a conversation about the diff= erences between a topology IM model that is network-centric vs. device-cent= ric. =A0Clearly the WG has strong and different opinions about it.=A0
<= br>
Since many people are here in Vancouver, focused on IETF and not= their day-jobs, this seems like a good time to get it rolling...

Alia
--90e6ba5bbabdd4f9c504ea8cf275-- From eosborne@cisco.com Wed Nov 6 21:11:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E594611E8243 for ; Wed, 6 Nov 2013 21:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HW9B2K+XapNg for ; Wed, 6 Nov 2013 21:11:41 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 162B411E8172 for ; Wed, 6 Nov 2013 21:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1628; q=dns/txt; s=iport; t=1383801101; x=1385010701; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0nxPtuFJ01lAq+cOjlXzKZiapP9raaIz+gi07y0n2dg=; b=CIxJ5y8hqBkT2s27TUQzLNJoDN538yu124YZJQbFuRcFTR3iDhT3fkv5 ygbEiGiiYJUc2yC6Uxa7JuORgXkGdoaUKmXZBF3UrFs6mswMJ6++ZsVGs 8VupNJMWIMPSEbVR7a+g8d04mUfWBnA2PArkwpxu6Rt/KCZKPbqpM92Ep c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAMEfe1KtJXG+/2dsb2JhbABZgweBC78cgSkWdIIlAQEBAwE6RAcEAgEIDgMEAQELFAkHMhQJCAIEARIIh3MGvmyPKDgGgxqBEAOiXoc4gWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,649,1378857600"; d="scan'208";a="281563855" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2013 05:11:40 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA75BePc030859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 05:11:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 23:11:40 -0600 From: "Eric Osborne (eosborne)" To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO22BfjXVgSCqIVkWy1YdjiTTe+ZoZNw3A Date: Thu, 7 Nov 2013 05:11:39 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 05:11:47 -0000 > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Wednesday, November 06, 2013 6:23 PM > To: i2rs@ietf.org > Subject: [i2rs] topology info model - what makes it a "network" model > vs. a "device" model >=20 > I'd really like to start a conversation=20 ...ok...so go ahead. :) > about the differences between a > topology IM model that is network-centric vs. device-centric. =20 > Clearly > the WG has strong and different opinions about it. Are there really differences of opinion about what the difference is betwee= n a network model and a device model? A network is a plurality of devices,= and a network model is something which deals with a system resulting from = the use of more than one device. (ok, yes, a network of one node is a corn= er case blah blah handwave...). I don't see how there could be any real de= bate around this, but if there is I'm quite interested in what it might be. It feels like the real question is whether i2rs should have network models = in scope. =20 If Yes: ok, cool. But between link properties (that is, at least some kind= of topology view), counter dumps, debugs, routing, MPLS, and LAG member re= balancing, show me what's *not* in scope. =20 If Not: what problems arise that would be solved by having a network model,= do we need one, and where would it come from if not i2rs? =20 eric >=20 > Since many people are here in Vancouver, focused on IETF and not their > day-jobs, this seems like a good time to get it rolling... >=20 > Alia From russw@riw.us Wed Nov 6 22:16:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F1411E8151 for ; Wed, 6 Nov 2013 22:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFvsDmh3MuMZ for ; Wed, 6 Nov 2013 22:16:15 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5C35D11E8167 for ; Wed, 6 Nov 2013 22:16:15 -0800 (PST) Received: from [64.114.24.114] (port=63240 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VeIt2-00014c-QW; Thu, 07 Nov 2013 06:16:13 +0000 From: "Russ White" To: "'Eric Osborne \(eosborne\)'" , "'Alia Atlas'" , References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> Date: Thu, 7 Nov 2013 01:16:12 -0500 Message-ID: <002701cedb80$e0285700$a0790500$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFjCaXgA/khqN8XiklzqYpMrvs7iAFTQ9z3muZQRVA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 06:16:21 -0000 > Are there really differences of opinion about what the difference is between > a network model and a device model? A network is a plurality of devices, > and a network model is something which deals with a system resulting from > the use of more than one device. (ok, yes, a network of one node is a corner > case blah blah handwave...). I don't see how there could be any real debate > around this, but if there is I'm quite interested in what it might be. Agreed--both seem necessary, but different beasts (see the discussion on sdnrg right now --same problem, different names). > It feels like the real question is whether i2rs should have network models in > scope. Right... I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network model cares about that a device model isn't going to care about. In other words, if we only look at protocol level use cases, we might miss some pieces of information we'll eventually need for building network topologies, or that sort of thing. > If Yes: ok, cool. But between link properties (that is, at least some kind of > topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope. This is the problem on the other end, however... It's better, IMHO, to start with a single small set of problems and solve them in a way that specifically allows extensions to solve other problems. If we try to model every possible problem, to make certain we have accounted for every possible situation, well, we'll never actually do anything but describe problems. I'm pretty familiar with the "describing problems all the time" process, as I have kids... :-) (Oh, I'm glad they don't read this list, because they'd really be mad at me about now!). So I think it's valuable to describe these network models, and think about them. OTOH, I'm really concerned we're going to get bogged down in them, and take up a lot of time reading and accounting for them, which could well divert us (even more!) from picking a small set of well-defined problems and solving them in an extensible way. I think that's the point Joel was trying to make at the mic today, btw... :-) Russ From n.milovanov@gmail.com Wed Nov 6 23:17:58 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6A11E820D for ; Wed, 6 Nov 2013 23:17:58 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZwVCDQzgV3I for ; Wed, 6 Nov 2013 23:17:57 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0676611E81D3 for ; Wed, 6 Nov 2013 23:17:56 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hv10so97990vcb.15 for ; Wed, 06 Nov 2013 23:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FYw17NrjVfrMB6MXwG/ixpVV5V8/8GnnJ6mHCiS5Q+A=; b=Oy/HPS9yK2vhSoKcpruwqw3SP9gIcLYp6n+tePD53bcgsGHwrh18wUS7tn1zsT4oT7 ROYzu2hL9mJXo6nuUukmMrbUmVljAaGO4ucjSgnfuAL3CpdZDm1rEbI/Ojh6Pma4U8sh tHPsLYsSW7ss2kQtRIdSw4axseh/RA0vWIhRzjwQNpq6yeSzbUV1Rq2S9CWZZ5dBHeDb KZWpPXG0eSUinHctmyI9QN3E2Ol/LcjGbSE+BF6ROvQRVb72T6Se28NoiUpTM0unKFdq 50HenzMbQnWtFPuyTOnyaeD8dmHwyxCh1AQuIsmQLt7mNDJFKtdrBuwKH6R7Fu/viX9m btyg== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr5554054vcb.16.1383808672493; Wed, 06 Nov 2013 23:17:52 -0800 (PST) Received: by 10.58.252.138 with HTTP; Wed, 6 Nov 2013 23:17:52 -0800 (PST) In-Reply-To: <002701cedb80$e0285700$a0790500$@riw.us> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> Date: Thu, 7 Nov 2013 09:17:52 +0200 Message-ID: From: Nikolay Milovanov To: Russ White Content-Type: multipart/alternative; boundary=047d7b5db26a5c791604ea911021 Cc: i2rs@ietf.org, "Eric Osborne \(eosborne\)" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:17:58 -0000 --047d7b5db26a5c791604ea911021 Content-Type: text/plain; charset=ISO-8859-1 Hi, I might be completely wrong but from a brief overview of the Topology API Use Cases my guess would be. The topology data model will be an undirected graph with nodes, edges with certain properties representing part of the network topology and the device centric model will be something hierarchical with a root object the network device its interfaces, their IPs, the protocols working on them and the neighbor devices learned dynamically by those protocols. Most likely the network-centric topology models coming from each of the devices will have to be merged by the network topology manager in order the rest of the applications to be able to benefit from a complete model of the entire network topology. In my opinion either of the models will be extremely useful for all kinds of OSS applications related to network service provisioning and fulfillment. Currently is quite difficult to build any of them by means such as CLI parsing and SNMP. Netconf is not bad but still an API will be much better :) BR, Nikolay Milovanov Network Engineer n.milovanov@gmail.com On Thu, Nov 7, 2013 at 8:16 AM, Russ White wrote: > > > Are there really differences of opinion about what the difference is > between > > a network model and a device model? A network is a plurality of devices, > > and a network model is something which deals with a system resulting from > > the use of more than one device. (ok, yes, a network of one node is a > corner > > case blah blah handwave...). I don't see how there could be any real > debate > > around this, but if there is I'm quite interested in what it might be. > > Agreed--both seem necessary, but different beasts (see the discussion on > sdnrg right now --same problem, different names). > > > It feels like the real question is whether i2rs should have network > models > in > > scope. > > Right... > > I think network models at this point in the game might be useful to make > certain we are getting all the information we need from the models at the > protocol and device levels... In other words, there are things the network > model cares about that a device model isn't going to care about. In other > words, if we only look at protocol level use cases, we might miss some > pieces of information we'll eventually need for building network > topologies, > or that sort of thing. > > > If Yes: ok, cool. But between link properties (that is, at least some > kind of > > topology view), counter dumps, debugs, routing, MPLS, and LAG member > > rebalancing, show me what's *not* in scope. > > This is the problem on the other end, however... It's better, IMHO, to > start > with a single small set of problems and solve them in a way that > specifically allows extensions to solve other problems. If we try to model > every possible problem, to make certain we have accounted for every > possible > situation, well, we'll never actually do anything but describe problems. > I'm > pretty familiar with the "describing problems all the time" process, as I > have kids... :-) (Oh, I'm glad they don't read this list, because they'd > really be mad at me about now!). > > So I think it's valuable to describe these network models, and think about > them. OTOH, I'm really concerned we're going to get bogged down in them, > and > take up a lot of time reading and accounting for them, which could well > divert us (even more!) from picking a small set of well-defined problems > and > solving them in an extensible way. I think that's the point Joel was trying > to make at the mic today, btw... > > :-) > > Russ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- BR, Nikolay Milovanov Network Engineer Email: n.milovanov@gmail.com --047d7b5db26a5c791604ea911021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I might be completely wr= ong but from a brief overview of the=A0Topology API Use Cases my guess woul= d be.=A0

The topology data model will be an undirected = graph with nodes, edges with certain properties representing part of the ne= twork topology =A0and the device centric model will be something hierarchic= al with a root object the network device its interfaces, their IPs, the pro= tocols working on them and the neighbor devices learned dynamically by thos= e protocols. =A0=A0

Most likely the network-centric topology models coming from = each of the devices will have to be merged by the network topology manager = in order the rest of the applications to be able to benefit from a complete= model of the entire network topology.=A0

In my opinion either of the models will be extremely us= eful for all kinds of OSS applications related to network service provision= ing and fulfillment. Currently is quite difficult to build any of them by m= eans such as CLI parsing and SNMP. Netconf is not bad but still an API will= be much better :)

=A0
BR,=A0
Nikolay Milovanov
<= div>
Network Engineer




On Thu, Nov 7= , 2013 at 8:16 AM, Russ White <russw@riw.us> wrote:

> Are there really differences of opinion about what the difference is between
> a network model and a device model? =A0A network is a plurality of dev= ices,
> and a network model is something which deals with a system resulting f= rom
> the use of more than one device. =A0(ok, yes, a network of one node is= a
corner
> case blah blah handwave...). =A0I don't see how there could be any= real
debate
> around this, but if there is I'm quite interested in what it might= be.

Agreed--both seem necessary, but different beasts (see the discussion= on
sdnrg right now --same problem, different names).

> It feels like the real question is whether i2rs should have network mo= dels
in
> scope.

Right...

I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network<= br> model cares about that a device model isn't going to care about. In oth= er
words, if we only look at protocol level use cases, we might miss some
pieces of information we'll eventually need for building network topolo= gies,
or that sort of thing.

> If Yes: ok, cool. =A0But between link properties (that is, at least so= me
kind of
> topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope.

This is the problem on the other end, however... It's better, IMH= O, to start
with a single small set of problems and solve them in a way that
specifically allows extensions to solve other problems. If we try to model<= br> every possible problem, to make certain we have accounted for every possibl= e
situation, well, we'll never actually do anything but describe problems= . I'm
pretty familiar with the "describing problems all the time" proce= ss, as I
have kids... :-) (Oh, I'm glad they don't read this list, because t= hey'd
really be mad at me about now!).

So I think it's valuable to describe these network models, and think ab= out
them. OTOH, I'm really concerned we're going to get bogged down in = them, and
take up a lot of time reading and accounting for them, which could well
divert us (even more!) from picking a small set of well-defined problems an= d
solving them in an extensible way. I think that's the point Joel was tr= ying
to make at the mic today, btw...

:-)

Russ



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--
= BR,

Nikolay Milovanov
Network Engineer
Email: n.milovanov@gmail.com
--047d7b5db26a5c791604ea911021-- From akatlas@gmail.com Wed Nov 6 23:59:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EAB11E818A for ; Wed, 6 Nov 2013 23:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OD5Qzsdk0c for ; Wed, 6 Nov 2013 23:59:21 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F115111E824D for ; Wed, 6 Nov 2013 23:59:15 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so266810iet.18 for ; Wed, 06 Nov 2013 23:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LodnZvjTRrBkK3VfV506qHpe1U3BpfroPC2fpxPNe8=; b=mSfJvcthDGPUoboF9VKfm2OhEHQrqA2H6mCNNRfpbtRO8C/igM7qpcIjziWcwJ+6QY qr6tca4bpPUX1jkq6viAd9F3nfB/R7pf/6vQClIws4uCGCCHC2wUfKgpAArn33N79feN dUnOdiuawzxBr8NLdeHyHcIV8h/nuBOGCYBZoyZrsqZy6hPhc76M97ara8QibE4Y/AWh JvCbo7T1NhuLz2EOchnP3UglW9GgqPFQ5UfSLoUsPsp3Z/Z6sNwkALW+T6uWTae1L3pM vk8L5yiuUTpkiTL9miBRmdj33X3B6uw8qEkEj7dxHVn7/BwaOhijzZqUt3jYFrdesc69 pCCg== MIME-Version: 1.0 X-Received: by 10.50.4.9 with SMTP id g9mr1135629igg.22.1383811155452; Wed, 06 Nov 2013 23:59:15 -0800 (PST) Received: by 10.64.78.103 with HTTP; Wed, 6 Nov 2013 23:59:15 -0800 (PST) In-Reply-To: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> Date: Thu, 7 Nov 2013 02:59:15 -0500 Message-ID: From: Alia Atlas To: Nikolay Milovanov Content-Type: multipart/alternative; boundary=001a11c3184e5bb72204ea91a4d3 Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:59:26 -0000 --001a11c3184e5bb72204ea91a4d3 Content-Type: text/plain; charset=ISO-8859-1 Hi, Yes - so what I'm really trying to do is elicit what the points of concern and different options are as far as modeling the topology information from a device. draft-medved-i2rs-topology-im has changed only minimally since last IETF - and in ways that don't seem to address any of the disagreements or concerns. We need to be sure to bite off the right-sized first chunk to do. If we have a device-centric model showing interfaces and so on, then there's not a good way to express the learned IGP topology. Would we then need a different IM - perhaps as part of an IGP-specific IM - to communicate the topology learned via the IGP? Would that be preferable? Given that the active IGP topology can be learned via BGP-LS, are we better off focusing on an interface-focused IM (whether that is a device model or an interfaces model or...)? I'd really like to make significant progress in understanding the perspectives and thoughts of the WG on this. I understand that all these things may be useful but in our usual ocean-boiling-avoidance method, we've got to prioritize. I'm also not comfortable on having only one IM for basing all our requirements off of. So - more thoughts? Alia On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov wrote: > Hi, > > I might be completely wrong but from a brief overview of the Topology API > Use Cases my guess would be. > > The topology data model will be an undirected graph with nodes, edges with > certain properties representing part of the network topology and the > device centric model will be something hierarchical with a root object the > network device its interfaces, their IPs, the protocols working on them and > the neighbor devices learned dynamically by those protocols. > > Most likely the network-centric topology models coming from each of the > devices will have to be merged by the network topology manager in order the > rest of the applications to be able to benefit from a complete model of the > entire network topology. > > In my opinion either of the models will be extremely useful for all kinds > of OSS applications related to network service provisioning and > fulfillment. Currently is quite difficult to build any of them by means > such as CLI parsing and SNMP. Netconf is not bad but still an API will be > much better :) > > > BR, > Nikolay Milovanov > > Network Engineer > n.milovanov@gmail.com > > > > > On Thu, Nov 7, 2013 at 8:16 AM, Russ White wrote: > >> >> > Are there really differences of opinion about what the difference is >> between >> > a network model and a device model? A network is a plurality of >> devices, >> > and a network model is something which deals with a system resulting >> from >> > the use of more than one device. (ok, yes, a network of one node is a >> corner >> > case blah blah handwave...). I don't see how there could be any real >> debate >> > around this, but if there is I'm quite interested in what it might be. >> >> Agreed--both seem necessary, but different beasts (see the discussion on >> sdnrg right now --same problem, different names). >> >> > It feels like the real question is whether i2rs should have network >> models >> in >> > scope. >> >> Right... >> >> I think network models at this point in the game might be useful to make >> certain we are getting all the information we need from the models at the >> protocol and device levels... In other words, there are things the network >> model cares about that a device model isn't going to care about. In other >> words, if we only look at protocol level use cases, we might miss some >> pieces of information we'll eventually need for building network >> topologies, >> or that sort of thing. >> >> > If Yes: ok, cool. But between link properties (that is, at least some >> kind of >> > topology view), counter dumps, debugs, routing, MPLS, and LAG member >> > rebalancing, show me what's *not* in scope. >> >> This is the problem on the other end, however... It's better, IMHO, to >> start >> with a single small set of problems and solve them in a way that >> specifically allows extensions to solve other problems. If we try to model >> every possible problem, to make certain we have accounted for every >> possible >> situation, well, we'll never actually do anything but describe problems. >> I'm >> pretty familiar with the "describing problems all the time" process, as I >> have kids... :-) (Oh, I'm glad they don't read this list, because they'd >> really be mad at me about now!). >> >> So I think it's valuable to describe these network models, and think about >> them. OTOH, I'm really concerned we're going to get bogged down in them, >> and >> take up a lot of time reading and accounting for them, which could well >> divert us (even more!) from picking a small set of well-defined problems >> and >> solving them in an extensible way. I think that's the point Joel was >> trying >> to make at the mic today, btw... >> >> :-) >> >> Russ >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > > -- > BR, > > Nikolay Milovanov > Network Engineer > Email: n.milovanov@gmail.com > --001a11c3184e5bb72204ea91a4d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Yes - so what I'm really trying= to do is elicit what the points of concern and different options are as fa= r as modeling the topology information from a device. =A0 draft-medved-i2rs= -topology-im has changed only minimally since last IETF - and in ways that = don't seem to address any of the disagreements or concerns.

We need to be sure to bite off the right-siz= ed first chunk to do.

If we have a device-centric model showing interfaces and s= o on, then there's not a good way to express the learned IGP topology. = =A0Would we then need a different IM - perhaps as part of an IGP-specific I= M - to communicate the topology learned via the IGP? =A0Would that be prefe= rable?

Given that = the active IGP topology can be learned via BGP-LS, are we better off focusi= ng on an interface-focused IM (whether that is a device model or an interfa= ces model or...)?

I'd rea= lly like to make significant progress in understanding the perspectives and= thoughts of the WG on this. =A0 I understand that all these things may be = useful but in our usual ocean-boiling-avoidance method, we've got to pr= ioritize. =A0

I'm als= o not comfortable on having only one IM for basing all our requirements off= of.

S= o - more thoughts?

Alia
<= div class=3D"gmail_extra">
On Thu, Nov 7, 201= 3 at 2:17 AM, Nikolay Milovanov <n.milovanov@gmail.com> = wrote:
Hi,

I might be completely wrong but from a brief overview of the=A0Topol= ogy API Use Cases my guess would be.=A0

The topology data model will be an undirected graph with nod= es, edges with certain properties representing part of the network topology= =A0and the device centric model will be something hierarchical with a root= object the network device its interfaces, their IPs, the protocols working= on them and the neighbor devices learned dynamically by those protocols. = =A0=A0

Most likely the network-centric topology models coming from = each of the devices will have to be merged by the network topology manager = in order the rest of the applications to be able to benefit from a complete= model of the entire network topology.=A0

In my opinion either of the models will be extremely us= eful for all kinds of OSS applications related to network service provision= ing and fulfillment. Currently is quite difficult to build any of them by m= eans such as CLI parsing and SNMP. Netconf is not bad but still an API will= be much better :)

=A0
BR,=A0
Nikolay Milovanov
<= div>
Network Engineer




On Thu, Nov 7, 2013 at 8:16 AM, Russ White <= russw@riw.us> wrote:

> Are there really differences of opinion about what the difference is between
> a network model and a device model? =A0A network is a plurality of dev= ices,
> and a network model is something which deals with a system resulting f= rom
> the use of more than one device. =A0(ok, yes, a network of one node is= a
corner
> case blah blah handwave...). =A0I don't see how there could be any= real
debate
> around this, but if there is I'm quite interested in what it might= be.

Agreed--both seem necessary, but different beasts (see the discussion= on
sdnrg right now --same problem, different names).

> It feels like the real question is whether i2rs should have network mo= dels
in
> scope.

Right...

I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network<= br> model cares about that a device model isn't going to care about. In oth= er
words, if we only look at protocol level use cases, we might miss some
pieces of information we'll eventually need for building network topolo= gies,
or that sort of thing.

> If Yes: ok, cool. =A0But between link properties (that is, at least so= me
kind of
> topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope.

This is the problem on the other end, however... It's better, IMH= O, to start
with a single small set of problems and solve them in a way that
specifically allows extensions to solve other problems. If we try to model<= br> every possible problem, to make certain we have accounted for every possibl= e
situation, well, we'll never actually do anything but describe problems= . I'm
pretty familiar with the "describing problems all the time" proce= ss, as I
have kids... :-) (Oh, I'm glad they don't read this list, because t= hey'd
really be mad at me about now!).

So I think it's valuable to describe these network models, and think ab= out
them. OTOH, I'm really concerned we're going to get bogged down in = them, and
take up a lot of time reading and accounting for them, which could well
divert us (even more!) from picking a small set of well-defined problems an= d
solving them in an extensible way. I think that's the point Joel was tr= ying
to make at the mic today, btw...

:-)

Russ



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--
BR,

Nikolay Mi= lovanov
Network Engineer
Email: n.milovanov@gmail.com

--001a11c3184e5bb72204ea91a4d3-- From jmedved@cisco.com Thu Nov 7 00:05:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792B211E824D for ; Thu, 7 Nov 2013 00:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByO8UH1q-2rh for ; Thu, 7 Nov 2013 00:05:00 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 827E411E8242 for ; Thu, 7 Nov 2013 00:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7241; q=dns/txt; s=iport; t=1383811500; x=1385021100; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=xFZPRkYpEixL4OlK387bXgtjtrKUbiPKGqZKGWAlq2Y=; b=hwnX3QVr++T8ee06W02andoWfKY7QZ0gQAG+S2BrffDYLdXIOJLit6mx XFs6wgeYwhYVGR34KXIOmls0cMDcJrsNSTajqPvo2iHOdYjW4Ntkdtib/ i4n6bRH/3iBrmEHKFxJkIbSF0E8IXOT8yAg7hjUJ7avkjrMrBtsfvhWXu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAlJe1KtJV2a/2dsb2JhbABZgkNEgQu/DYEjFnSCJQECBIELAQgOAwMBAigoERQJCAIEARKHbwMPtAANiWuMZ4EzgS4YhDADliGBa4pSggCFOIFogT6BaEI X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208,217";a="281614084" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2013 08:04:59 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA784xRk020157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 08:04:59 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.189]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 02:04:59 -0600 From: "Jan Medved (jmedved)" To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO25AN0rwFsUfZ3UOruirIzHEAGw== Date: Thu, 7 Nov 2013 08:04:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.145.194] Content-Type: multipart/alternative; boundary="_000_CEA08184264A1jmedvedciscocom_" MIME-Version: 1.0 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:05:06 -0000 --_000_CEA08184264A1jmedvedciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alia, Thanks for starting the conversation :-) IMO, the lines between 'network-centric' and 'device-centric' are a little = blurred. For the sake of argument, let me agree with Joel that the I2RS WG'= s scope should be limited to a single routing system. Let me ask a few ques= tions then: * Is an OSPF router or an IS-IS router a 'routing system', as defined i= n the WG charter? If yes, would its LSDB be considered 'topology informatio= n' as defined in the WG charter? And if the the answer to the latter quest= ion is yes, would reading the LSDB information from the router via a tbd. I= 2RS protocol be considered 'extraction of information about topology from t= he network', as defined in the WG charter? * Is a BGP Router Reflector a routing system, as defined in the WG char= ter of the WG? If yes, would the LSDB information (potentially collected fr= om multiple IGP areas) in RR's BGP-RIB be considered 'topology information'= as defined in the WG charter? And if the the answer to the latter question= is yes, would reading the LSDB information from the RR be considered 'extr= action of information about topology from the network', as defined in the W= G charter? And if the BGP RR implements BGP-LS, would extracting the LSDB i= nformation from the RR be in scope of the WG? Could BGP-LS actually be cons= idered a candidate for an I2RS protocol that would be 'extracting informa= tion about topology from the network'? Thanks, Jan From: Alia Atlas > Date: Wednesday, November 6, 2013 6:23 PM To: "i2rs@ietf.org" > Subject: [i2rs] topology info model - what makes it a "network" model vs. a= "device" model I'd really like to start a conversation about the differences between a top= ology IM model that is network-centric vs. device-centric. Clearly the WG = has strong and different opinions about it. Since many people are here in Vancouver, focused on IETF and not their day-= jobs, this seems like a good time to get it rolling... Alia --_000_CEA08184264A1jmedvedciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <875A5D24AB8D814B977A764309FFA84F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Alia,=

Thanks f= or starting the conversation :-)

IMO, the= lines between 'network-centric' and 'device-centric' are a little blurred.= For the sake of argument, let me agree with Joel that the I2RS WG's scope = should be limited to a single routing system. Let me ask a few questions then:
  • Is an OSP= F router or an IS-IS router a 'routing system', as defined in the WG charte= r? If yes, would its LSDB be considered 'topology information' as defined i= n the WG charter?  And if the the answer to the latter question is yes, would reading the LSDB information f= rom the router via a tbd. I2RS protocol be considered 'extraction of info= rmation about topology from the network', as defined in the WG charter?
  • Is a BGP Router Reflecto= r a routing system, as defined in the WG charter of the WG? If yes, wo= uld the LSDB information (potentially collected from multiple IGP areas) in= RR's BGP-RIB be considered 'topology information' as defined in the WG charter? And if the the answer to t= he latter question is yes, would reading the LSDB information from the RR b= e considered 'extraction of information about topology from the network', as defined in the WG= charter? And if the BGP RR implements BGP-LS, would extracting the = LSDB information from the RR be in scope of the WG? Could BGP-LS actually be considered a candidate for an I2RS pro= tocol  that would  be 'extrac= ting information about topology from the network'?

Thanks,<= /div>
Jan


From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, November 6, 2013 6= :23 PM
To: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: [i2rs] topology info model= - what makes it a "network" model vs. a "device" model=

I'd really like to start a conversation about the differen= ces between a topology IM model that is network-centric vs. device-centric.=  Clearly the WG has strong and different opinions about it. 

Since many people are here in Vancouver, focused on IETF and not their= day-jobs, this seems like a good time to get it rolling...

Alia
 --_000_CEA08184264A1jmedvedciscocom_-- From jmedved@cisco.com Thu Nov 7 00:51:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BDF21E8113 for ; Thu, 7 Nov 2013 00:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6edUfO5HHbCI for ; Thu, 7 Nov 2013 00:51:09 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57321E819F for ; Thu, 7 Nov 2013 00:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21710; q=dns/txt; s=iport; t=1383814265; x=1385023865; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=pHFmP1KPfzGM64T41s2zMcFIjs1vsb1c7AY2w+zp6D0=; b=G0MlSemifvtdcQJkIHA0pPH7TujxBnO11kMkxrrOm8I5vLZ4lL8hxr7O PghfxZU7nHxdVYSKGkFwynloSXehuTNBUwgUCjmUFGteWV49Q1OK0Vhpf AcmUp7C5csLFBANDOtHKBRCn+DX/aofJmVPoiD1F4u+5Rh7dfuir5VuB8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJFTe1KtJXG//2dsb2JhbABZgkNEOFO/DoEkFnSCJQEBAQMBAQEBawsFDQEIDgMDAQIoKAYLFAkIAgQBDQWHbwMJBg2zXQ2JZwSMZ4EpgTgNBAeEMAOLSohigXWBa4pSggCFOIFogT6BcTk X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208,217";a="281627917" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 07 Nov 2013 08:51:04 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA78p4Lw028330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 08:51:04 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.189]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 02:51:03 -0600 From: "Jan Medved (jmedved)" To: Alia Atlas , Nikolay Milovanov Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO24mAj6q1nafGMEmQ4638sgBDc5oZzAOA//+IWoA= Date: Thu, 7 Nov 2013 08:51:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.145.194] Content-Type: multipart/alternative; boundary="_000_CEA08A13264F3jmedvedciscocom_" MIME-Version: 1.0 Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:51:14 -0000 --_000_CEA08A13264F3jmedvedciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Alia Atlas > Date: Wednesday, November 6, 2013 11:59 PM To: Nikolay Milovanov > Cc: Russ White >, "i2rs@ietf.org" >, "Eric Osborne (eosbor= ne)" > Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model Hi, Yes - so what I'm really trying to do is elicit what the points of concern = and different options are as far as modeling the topology information from = a device. draft-medved-i2rs-topology-im has changed only minimally since = last IETF - and in ways that don't seem to address any of the disagreements= or concerns. We need to be sure to bite off the right-sized first chunk to do. If we have a device-centric model showing interfaces and so on, then there'= s not a good way to express the learned IGP topology. Would we then need a= different IM - perhaps as part of an IGP-specific IM - to communicate the = topology learned via the IGP? Would that be preferable? If we decide that topology learned via the IGP is indeed in scope WG to go,= then the IGP-specific IMs are already defined in draft-medved-i2rs-topolog= y-im. Given that the active IGP topology can be learned via BGP-LS, are we better= off focusing on an interface-focused IM (whether that is a device model or= an interfaces model or...)? The same topology I'm model would apply to BGP-LS and to IGPs. I'd really like to make significant progress in understanding the perspecti= ves and thoughts of the WG on this. I understand that all these things ma= y be useful but in our usual ocean-boiling-avoidance method, we've got to p= rioritize. IMHO, it is actually easier to define the base network topology IM than the= device IMs from which a network topology can be 'stitched together'. The b= ase network topology IM is simple: it's a directed graph with nodes, links = and termination points. The base network topology IM can be easily augmente= d (extended) to cover L1-L3 networks, VPNs, etc. On the other hand, there i= s a variety of information (in devices and in other systems) that can (must= be) be used to 'stitch' together a network topology: dynamically learned n= eighbor info (LLDP for example for L2, IGP neighbor info for L3, for exampl= e), statically configured neighbor info in device configurations, IGP LSDB,= IGP configurations, inventory systems, interface data (interface type, spe= ed, =85), LAGs, etc. Trying to model all of this can turn out to be quite a= chunk to bite off. I'm also not comfortable on having only one IM for basing all our requireme= nts off of. I don't understand what you mean - can you please explain? So - more thoughts? The charter does not say anything about 'device-centric' or 'network-centri= c' IMs - it talks merely about 'topology information'. Can you define what = 'device-centric' and 'network-centric' is? Would 'device-centric' be infor= mation that a client could get from a single routing system device, without= a third party data aggregator, such as the Topology Manager or a Controlle= r? Or would 'device-centric' be strictly information about the device, in w= hich case an LSDB (or even neighbor info) would not be in scope? How would = you define 'network-centric'? Could we also consider IM criteria such as useful/useless, easy-to-model/di= fficult-to-model, easy-to-use/difficult-to-use, easy-to-extract/difficult-t= o-extract? IOW, what kind of topology IM would be most useful to apps, rela= tively easy to model (and where an initial model could be expanded for diff= erent use cases), and relatively easy to obtain from the network? Alia Thanks, Jan On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov > wrote: Hi, I might be completely wrong but from a brief overview of the Topology API U= se Cases my guess would be. The topology data model will be an undirected graph with nodes, edges with = certain properties representing part of the network topology and the devic= e centric model will be something hierarchical with a root object the netwo= rk device its interfaces, their IPs, the protocols working on them and the = neighbor devices learned dynamically by those protocols. Most likely the network-centric topology models coming from each of the dev= ices will have to be merged by the network topology manager in order the re= st of the applications to be able to benefit from a complete model of the e= ntire network topology. In my opinion either of the models will be extremely useful for all kinds o= f OSS applications related to network service provisioning and fulfillment.= Currently is quite difficult to build any of them by means such as CLI par= sing and SNMP. Netconf is not bad but still an API will be much better :) BR, Nikolay Milovanov Network Engineer n.milovanov@gmail.com On Thu, Nov 7, 2013 at 8:16 AM, Russ White > wrote: > Are there really differences of opinion about what the difference is between > a network model and a device model? A network is a plurality of devices, > and a network model is something which deals with a system resulting from > the use of more than one device. (ok, yes, a network of one node is a corner > case blah blah handwave...). I don't see how there could be any real debate > around this, but if there is I'm quite interested in what it might be. Agreed--both seem necessary, but different beasts (see the discussion on sdnrg right now --same problem, different names). > It feels like the real question is whether i2rs should have network model= s in > scope. Right... I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network model cares about that a device model isn't going to care about. In other words, if we only look at protocol level use cases, we might miss some pieces of information we'll eventually need for building network topologies= , or that sort of thing. > If Yes: ok, cool. But between link properties (that is, at least some kind of > topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope. This is the problem on the other end, however... It's better, IMHO, to star= t with a single small set of problems and solve them in a way that specifically allows extensions to solve other problems. If we try to model every possible problem, to make certain we have accounted for every possibl= e situation, well, we'll never actually do anything but describe problems. I'= m pretty familiar with the "describing problems all the time" process, as I have kids... :-) (Oh, I'm glad they don't read this list, because they'd really be mad at me about now!). So I think it's valuable to describe these network models, and think about them. OTOH, I'm really concerned we're going to get bogged down in them, an= d take up a lot of time reading and accounting for them, which could well divert us (even more!) from picking a small set of well-defined problems an= d solving them in an extensible way. I think that's the point Joel was trying to make at the mic today, btw... :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs -- BR, Nikolay Milovanov Network Engineer Email: n.milovanov@gmail.com --_000_CEA08A13264F3jmedvedciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, November 6, 2013 1= 1:59 PM
To: Nikolay Milovanov <n.milovanov@gmail.com>
Cc: Russ White <russw@riw.us>, "i2rs@ietf.org" <i2rs@ietf.or= g>, "Eric Osborne (eosborne)" <eosborne@cisco.com>
Subject: Re: [i2rs] topology info m= odel - what makes it a "network" model vs. a "device" m= odel

Hi,

Yes - so what I'm really trying to do is elicit what the points of con= cern and different options are as far as modeling the topology information = from a device.   draft-medved-i2rs-topology-im has changed only minima= lly since last IETF - and in ways that don't seem to address any of the disagreements or concerns.

We need to be sure to bite off the right-sized first chunk to do.

If we have a device-centric model showing interf= aces and so on, then there's not a good way to express the learned IGP topo= logy.  Would we then need a different IM - perhaps as part of an IGP-s= pecific IM - to communicate the topology learned via the IGP?  Would that be preferable?

If we decide that topology learned via the IGP is indeed in = scope WG to go, then the IGP-specific IMs are already defined in draft= -medved-i2rs-topology-im.


Given that the active IGP topology can be learne= d via BGP-LS, are we better off focusing on an interface-focused IM (whethe= r that is a device model or an interfaces model or...)?

The same topology I'm model would apply to BGP-LS and to IGPs. 

I'd really like to make significant progress in = understanding the perspectives and thoughts of the WG on this.   I und= erstand that all these things may be useful but in our usual ocean-boiling-= avoidance method, we've got to prioritize.  

IMHO, it is actually easier to define the base network topology IM tha= n the device IMs from which a network topology can be 'stitched together'. = The base network topology IM is simple: it's a directed graph with nodes, l= inks and termination points. The base network topology IM can be easily augmented (extended) to cover L1-L3= networks, VPNs, etc. On the other hand, there is a variety of information = (in devices and in other systems) that can (must be) be used to 'stitch' to= gether a network topology: dynamically learned neighbor info (LLDP for example for L2, IGP neighbor info for L3, = for example), statically configured neighbor info in device configurations,= IGP LSDB, IGP configurations, inventory systems, interface data (interface= type, speed, =85), LAGs, etc. Trying to model all of this can turn out to be quite a chunk to bite off. 


I'm also not comfortable on having only one IM f= or basing all our requirements off of.

I don't understand what you mean - can you please explain?


So - more thoughts?

The charter does not say anything about 'device-centric' or 'network-c= entric' IMs - it talks merely about 'topology information'. Can you define = what 'device-centric' and 'network-centric' is?  Would 'device-centric= ' be information that a client could get from a single routing system device, without a third party data aggreg= ator, such as the Topology Manager or a Controller? Or would 'device-centri= c' be strictly information about the device, in which case an LSDB (or even= neighbor info) would not be in scope? How would you define 'network-centric'?

Could we also consider IM criteria such as useful/useless, easy-to-mod= el/difficult-to-model, easy-to-use/difficult-to-use, easy-to-extract/diffic= ult-to-extract? IOW, what kind of topology IM would be most useful to apps,= relatively easy to model (and where an initial model could be expanded for different use cases), and relativel= y easy to obtain from the network?


Alia

Thanks,
Jan


On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovano= v <n.milovanov@= gmail.com> wrote:
Hi,

I might be completely wrong but from a brief overview of the Topo= logy API Use Cases my guess would be. 

The topology data model will be an undirected graph with nodes, edges with = certain properties representing part of the network topology  and the = device centric model will be something hierarchical with a root object the = network device its interfaces, their IPs, the protocols working on them and the neighbor devices learned dynami= cally by those protocols.   

Most likely the network-centric topology models coming from each of th= e devices will have to be merged by the network topology manager in order t= he rest of the applications to be able to benefit from a complete model of = the entire network topology. 

In my opinion either of the models will be extremely useful for all ki= nds of OSS applications related to network service provisioning and fulfill= ment. Currently is quite difficult to build any of them by means such as CL= I parsing and SNMP. Netconf is not bad but still an API will be much better :)

 
BR, 
Nikolay Milovanov

Network Engineer




On Thu, Nov 7, 2013 at 8:16 AM, Russ White <russw@riw.us&= gt; wrote:

> Are there really differences of opinion about what the difference is between
> a network model and a device model?  A network is a plurality of = devices,
> and a network model is something which deals with a system resulting f= rom
> the use of more than one device.  (ok, yes, a network of one node= is a
corner
> case blah blah handwave...).  I don't see how there could be any = real
debate
> around this, but if there is I'm quite interested in what it might be.=

Agreed--both seem necessary, but different beasts (see the discussion on sdnrg right now --same problem, different names).

> It feels like the real question is whether i2rs should have network mo= dels
in
> scope.

Right...

I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network<= br> model cares about that a device model isn't going to care about. In other words, if we only look at protocol level use cases, we might miss some
pieces of information we'll eventually need for building network topologies= ,
or that sort of thing.

> If Yes: ok, cool.  But between link properties (that is, at least= some
kind of
> topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope.

This is the problem on the other end, however... It's better, IMHO, to star= t
with a single small set of problems and solve them in a way that
specifically allows extensions to solve other problems. If we try to model<= br> every possible problem, to make certain we have accounted for every possibl= e
situation, well, we'll never actually do anything but describe problems. I'= m
pretty familiar with the "describing problems all the time" proce= ss, as I
have kids... :-) (Oh, I'm glad they don't read this list, because they'd really be mad at me about now!).

So I think it's valuable to describe these network models, and think about<= br> them. OTOH, I'm really concerned we're going to get bogged down in them, an= d
take up a lot of time reading and accounting for them, which could well
divert us (even more!) from picking a small set of well-defined problems an= d
solving them in an extensible way. I think that's the point Joel was trying=
to make at the mic today, btw...

:-)

Russ



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



--
BR,

Nikolay Milovanov
Network Engineer
Email: n.milovan= ov@gmail.com

 --_000_CEA08A13264F3jmedvedciscocom_-- From russw@riw.us Thu Nov 7 06:23:04 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F4411E827F for ; Thu, 7 Nov 2013 06:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWmmqfs7gvpC for ; Thu, 7 Nov 2013 06:22:58 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4E321F936F for ; Thu, 7 Nov 2013 06:22:26 -0800 (PST) Received: from [64.114.24.114] (port=64420 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VeQTT-0006n0-2N; Thu, 07 Nov 2013 14:22:19 +0000 From: "Russ White" To: "'Alia Atlas'" , "'Nikolay Milovanov'" References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> In-Reply-To: Date: Thu, 7 Nov 2013 09:21:38 -0500 Message-ID: <01d701cedbc4$c85f12f0$591d38d0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFjCaXgA/khqN8XiklzqYpMrvs7iAFTQ9z3AgzgML4B1KmWAQJS8NxsmrU2bIA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: i2rs@ietf.org, "'Eric Osborne \(eosborne\)'" Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:23:04 -0000 > If we have a device-centric model showing interfaces and so on, then there's > not a good way to express the learned IGP topology. Would we then need a > different IM - perhaps as part of an IGP-specific IM - to communicate the > topology learned via the IGP? Would that be preferable? Yes, you are going to need different network models for different protocols, services, etc. There's not going to be any way to combine such models into a "coherent whole." On the other hand, all of these various models must meet in the interface to individual devices, and hence the model of the individual device and any protocols used to communicate with those individual devices. For the moment, the most useful thing I think we can take from these models is to understand, and plan for (if not incorporate immediately), the information they need to gather from individual devices in order to actually be built. So use cases are interesting in this space, though I'm still very concerned about the split or balance between "now" work and "building the foundation for later work." I consider network models "building the foundation for later," work, with the caveat that we need to make certain there is flexibility enough in the individual device model to accommodate the information needed to build a network model. If that makes sense. It's early, and I'm in a different time zone, so... :-) Russ From j.schoenwaelder@jacobs-university.de Thu Nov 7 06:54:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440EC21E8218 for ; Thu, 7 Nov 2013 06:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaM7JIeHFGoD for ; Thu, 7 Nov 2013 06:53:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB82121E81B7 for ; Thu, 7 Nov 2013 06:53:57 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F023200A7; Thu, 7 Nov 2013 15:53:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pt-cKJQS8Bl0; Thu, 7 Nov 2013 15:53:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F40572009A; Thu, 7 Nov 2013 15:53:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4B8242930EB0; Thu, 7 Nov 2013 15:53:48 +0100 (CET) Date: Thu, 7 Nov 2013 15:53:47 +0100 From: Juergen Schoenwaelder To: Russ White Message-ID: <20131107145347.GA87679@elstar.local> Mail-Followup-To: Russ White , 'Alia Atlas' , 'Nikolay Milovanov' , i2rs@ietf.org, "'Eric Osborne (eosborne)'" References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> <01d701cedbc4$c85f12f0$591d38d0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01d701cedbc4$c85f12f0$591d38d0$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'Eric Osborne \(eosborne\)'" , i2rs@ietf.org, 'Nikolay Milovanov' , 'Alia Atlas' Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:54:02 -0000 On Thu, Nov 07, 2013 at 09:21:38AM -0500, Russ White wrote: > > > If we have a device-centric model showing interfaces and so on, then > there's > > not a good way to express the learned IGP topology. Would we then need a > > different IM - perhaps as part of an IGP-specific IM - to communicate the > > topology learned via the IGP? Would that be preferable? > > Yes, you are going to need different network models for different protocols, > services, etc. There's not going to be any way to combine such models into a > "coherent whole." > Data models for different protocols such as OSPF or BGP have so far been done in WGs that care about those protocols and this has generally worked well as far as I can tell. We are now moving towards YANG models for configuration and state data and a general framework for YANG routing models has been defined in the NETMOD WG [1] (the next update of this document will go to WG last call). We expect that BGP, OSPF, ... specific extensions of this core routing model will be produced and we envision that this work takes place in the routing area, e.g., in WGs maintaining these routing protocols. Of course, we first need concrete proposals to start from. I think what I am saying is that (a) there is work going on outside of I2RS and we better avoid overlapping activities and (b) I like to remind you that work can be split and it is not necessary that I2RS creates all data models on its own. /js [1] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From russw@riw.us Thu Nov 7 07:14:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C0621E827C for ; Thu, 7 Nov 2013 07:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jZRDLHPkAlx for ; Thu, 7 Nov 2013 07:14:05 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF3B21E826F for ; Thu, 7 Nov 2013 07:13:53 -0800 (PST) Received: from [64.114.24.114] (port=64894 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VeRHI-0007CY-BG; Thu, 07 Nov 2013 15:13:50 +0000 From: "Russ White" To: "'Juergen Schoenwaelder'" References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> <01d701cedbc4$c85f12f0$591d38d0$@riw.us> <20131107145347.GA87679@elstar.local> In-Reply-To: <20131107145347.GA87679@elstar.local> Date: Thu, 7 Nov 2013 10:13:53 -0500 Message-ID: <095601cedbcb$fad0e040$f072a0c0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFjCaXgA/khqN8XiklzqYpMrvs7iAFTQ9z3AgzgML4B1KmWAQJS8NxsAdY0IdYBtaJ5f5qY52pQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: "'Eric Osborne \(eosborne\)'" , i2rs@ietf.org, 'Nikolay Milovanov' , 'Alia Atlas' Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:14:11 -0000 > I think what I am saying is that (a) there is work going on outside of I2RS and > we better avoid overlapping activities and (b) I like to remind you that work > can be split and it is not necessary that I2RS creates all data models on its > own. Of course! The first point seems to be to decide what models are needed, the second to decide where that work should be done, or if there is work that already fits what needs to be done. I'm more concerned about where and how these models are useful for the moment, not from the perspective of how they can be used, but rather from how the impact the models needed to "make I2RS go." IE, what do these models tell us about protocol and device model requirements? :-) Russ From kgray@juniper.net Thu Nov 7 07:51:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2CC21E81B9 for ; Thu, 7 Nov 2013 07:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQKwD1HSBs8Z for ; Thu, 7 Nov 2013 07:51:36 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id C1D2221E8167 for ; Thu, 7 Nov 2013 07:51:35 -0800 (PST) Received: from mail144-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 15:51:34 +0000 Received: from mail144-ch1 (localhost [127.0.0.1]) by mail144-ch1-R.bigfish.com (Postfix) with ESMTP id B3131A052C; Thu, 7 Nov 2013 15:51:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z579ehzdb82h98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail144-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(24454002)(377454003)(81542001)(81342001)(69226001)(46102001)(15202345003)(51856001)(74366001)(19580405001)(83322001)(74706001)(19580395003)(54356001)(53806001)(47736001)(49866001)(47976001)(50986001)(4396001)(80976001)(81686001)(87266001)(2656002)(74876001)(81816001)(561944002)(74316001)(33646001)(56816003)(77096001)(85306002)(76482001)(63696002)(66066001)(80022001)(54316002)(77982001)(15975445006)(59766001)(31966008)(65816001)(74502001)(83072001)(76576001)(74662001)(79102001)(56776001)(76786001)(76796001)(47446002)(87936001)(81183002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail144-ch1 (localhost.localdomain [127.0.0.1]) by mail144-ch1 (MessageSwitch) id 1383839492228746_1495; Thu, 7 Nov 2013 15:51:32 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail144-ch1.bigfish.com (Postfix) with ESMTP id 285EF1C0075; Thu, 7 Nov 2013 15:51:32 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 15:51:29 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 15:51:28 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 15:51:28 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.196]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.240]) with mapi id 15.00.0810.005; Thu, 7 Nov 2013 15:51:28 +0000 From: Ken Gray To: Russ White , Juergen Schoenwaelder Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO28lGS0Vr2Tu9+USLjqg42UwFUZoZ5+Cu Date: Thu, 7 Nov 2013 15:51:27 +0000 Message-ID: <957f6cf7972742a1a93c469155d59e7e@BL2PR05MB082.namprd05.prod.outlook.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> <01d701cedbc4$c85f12f0$591d38d0$@riw.us>, <20131107145347.GA87679@elstar.local> In-Reply-To: <20131107145347.GA87679@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 00235A1EEF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" , 'Alia Atlas' , "'Eric Osborne \(eosborne\)'" , 'Nikolay Milovanov' Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:51:42 -0000 While the question of WHERE the models finally get submitted is reasonable = (a fact I made to the preliminary discussion around creating NETCONF/Yang m= odels in the ONF for everything the wire protocol didn't easily cover), the= fact that the models are being developed (as mentioned below) is more acci= dental than planned, IMHO. =0A= =0A= That's the fundamental point - for me. Without THIS WG's mandate to do cre= ate such models and do so in an agreed upon and cohesive manner (which is w= hat Jan is going on about - "here's the BASE model, and examples of how to = extend it ... that's topology, let's use this as a method for the other shi= te on the list"), you're going to have either a very incoherent/potentially= -chaotic result OR an eventual return to the entropy that has stifled innov= ation for years prior.=0A= =0A= So, IMHO, I'm happy to hear that work is going on in other WGs but worried = about whether it is being tracked toward a common goal and (ultimately) for= ms a cohesive model in the whole - be it for network/topology or device.=0A= =0A= I'd add as well that other SDO-like organizations are considering doing som= e of this modeling in the gold-rush to create a "NorthBound API" for SDN, m= otherhood and apple-pie. So, if we keep on our current vector (providing n= o oversight and expecting things to organically blossom where interest lies= ) we may end up with a different result than any of us are contemplating.= =0A= ________________________________________=0A= From: i2rs-bounces@ietf.org on behalf of Juergen Sc= hoenwaelder =0A= Sent: Thursday, November 07, 2013 9:53 AM=0A= To: Russ White=0A= Cc: 'Eric Osborne (eosborne)'; i2rs@ietf.org; 'Nikolay Milovanov'; 'Alia At= las'=0A= Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model=0A= =0A= On Thu, Nov 07, 2013 at 09:21:38AM -0500, Russ White wrote:=0A= >=0A= > > If we have a device-centric model showing interfaces and so on, then=0A= > there's=0A= > > not a good way to express the learned IGP topology. Would we then need= a=0A= > > different IM - perhaps as part of an IGP-specific IM - to communicate t= he=0A= > > topology learned via the IGP? Would that be preferable?=0A= >=0A= > Yes, you are going to need different network models for different protoco= ls,=0A= > services, etc. There's not going to be any way to combine such models int= o a=0A= > "coherent whole."=0A= >=0A= =0A= Data models for different protocols such as OSPF or BGP have so far=0A= been done in WGs that care about those protocols and this has=0A= generally worked well as far as I can tell. We are now moving towards=0A= YANG models for configuration and state data and a general framework=0A= for YANG routing models has been defined in the NETMOD WG [1] (the=0A= next update of this document will go to WG last call). We expect that=0A= BGP, OSPF, ... specific extensions of this core routing model will be=0A= produced and we envision that this work takes place in the routing=0A= area, e.g., in WGs maintaining these routing protocols. Of course,=0A= we first need concrete proposals to start from.=0A= =0A= I think what I am saying is that (a) there is work going on outside of=0A= I2RS and we better avoid overlapping activities and (b) I like to=0A= remind you that work can be split and it is not necessary that I2RS=0A= creates all data models on its own.=0A= =0A= /js=0A= =0A= [1] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany=0A= Fax: +49 421 200 3103 =0A= _______________________________________________=0A= i2rs mailing list=0A= i2rs@ietf.org=0A= https://www.ietf.org/mailman/listinfo/i2rs=0A= =0A= =0A= From jmh@joelhalpern.com Thu Nov 7 08:15:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B54821E81A6 for ; Thu, 7 Nov 2013 08:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTp26KDDJ17o for ; Thu, 7 Nov 2013 08:15:48 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE521E81C2 for ; Thu, 7 Nov 2013 08:15:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0D58B1406F8; Thu, 7 Nov 2013 08:15:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-bcef.meeting.ietf.org (dhcp-bcef.meeting.ietf.org [31.133.188.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7ABC21406F7; Thu, 7 Nov 2013 08:15:43 -0800 (PST) Message-ID: <527BBCAE.5050102@joelhalpern.com> Date: Thu, 07 Nov 2013 11:15:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Jan Medved (jmedved)" , Alia Atlas , Nikolay Milovanov References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:15:54 -0000 If I thought we could get away with not having protocol specific information models, then trying to design a protocol independent topology model for use with the network elements would seem applicable. But, as it stands, even if we had such a model, we would still need protocol specific models, which would be having to manipulate many aspects related to the common model. The argument that an abstracted model is useful when you are northbound from the topology manager is very understandable and attractive. But northbound from the topology manager is not our working space. Yours, Joel On 11/7/13 3:51 AM, Jan Medved (jmedved) wrote: > > > From: Alia Atlas > > Date: Wednesday, November 6, 2013 11:59 PM > To: Nikolay Milovanov > > Cc: Russ White >, "i2rs@ietf.org > " >, "Eric > Osborne (eosborne)" > > Subject: Re: [i2rs] topology info model - what makes it a "network" > model vs. a "device" model > > Hi, > > Yes - so what I'm really trying to do is elicit what the points of > concern and different options are as far as modeling the topology > information from a device. draft-medved-i2rs-topology-im has > changed only minimally since last IETF - and in ways that don't seem > to address any of the disagreements or concerns. > > We need to be sure to bite off the right-sized first chunk to do. > > If we have a device-centric model showing interfaces and so on, then > there's not a good way to express the learned IGP topology. Would > we then need a different IM - perhaps as part of an IGP-specific IM > - to communicate the topology learned via the IGP? Would that be > preferable? > > > If we decide that topology learned via the IGP is indeed in scope WG to > go, then the IGP-specific IMs are already defined > in draft-medved-i2rs-topology-im. > > > Given that the active IGP topology can be learned via BGP-LS, are we > better off focusing on an interface-focused IM (whether that is a > device model or an interfaces model or...)? > > > The same topology I'm model would apply to BGP-LS and to IGPs. > > > I'd really like to make significant progress in understanding the > perspectives and thoughts of the WG on this. I understand that all > these things may be useful but in our usual ocean-boiling-avoidance > method, we've got to prioritize. > > > IMHO, it is actually easier to define the base network topology IM than > the device IMs from which a network topology can be 'stitched together'. > The base network topology IM is simple: it's a directed graph with > nodes, links and termination points. The base network topology IM can be > easily augmented (extended) to cover L1-L3 networks, VPNs, etc. On the > other hand, there is a variety of information (in devices and in other > systems) that can (must be) be used to 'stitch' together a network > topology: dynamically learned neighbor info (LLDP for example for L2, > IGP neighbor info for L3, for example), statically configured neighbor > info in device configurations, IGP LSDB, IGP configurations, inventory > systems, interface data (interface type, speed, …), LAGs, etc. Trying to > model all of this can turn out to be quite a chunk to bite off. > > > I'm also not comfortable on having only one IM for basing all our > requirements off of. > > > I don't understand what you mean - can you please explain? > > > So - more thoughts? > > > The charter does not say anything about 'device-centric' or > 'network-centric' IMs - it talks merely about 'topology information'. > Can you define what 'device-centric' and 'network-centric' is? Would > 'device-centric' be information that a client could get from a single > routing system device, without a third party data aggregator, such as > the Topology Manager or a Controller? Or would 'device-centric' be > strictly information about the device, in which case an LSDB (or even > neighbor info) would not be in scope? How would you define > 'network-centric'? > > Could we also consider IM criteria such as useful/useless, > easy-to-model/difficult-to-model, easy-to-use/difficult-to-use, > easy-to-extract/difficult-to-extract? IOW, what kind of topology IM > would be most useful to apps, relatively easy to model (and where an > initial model could be expanded for different use cases), and relatively > easy to obtain from the network? > > > Alia > > > Thanks, > Jan > > > On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov > > wrote: > > Hi, > > I might be completely wrong but from a brief overview of > the Topology API Use Cases my guess would be. > > The topology data model will be an undirected graph with nodes, > edges with certain properties representing part of the network > topology and the device centric model will be something > hierarchical with a root object the network device its > interfaces, their IPs, the protocols working on them and the > neighbor devices learned dynamically by those protocols. > > Most likely the network-centric topology models coming from each > of the devices will have to be merged by the network topology > manager in order the rest of the applications to be able to > benefit from a complete model of the entire network topology. > > In my opinion either of the models will be extremely useful for > all kinds of OSS applications related to network service > provisioning and fulfillment. Currently is quite difficult to > build any of them by means such as CLI parsing and SNMP. Netconf > is not bad but still an API will be much better :) > > BR, > Nikolay Milovanov > > Network Engineer > n.milovanov@gmail.com > > > > > On Thu, Nov 7, 2013 at 8:16 AM, Russ White > wrote: > > > > Are there really differences of opinion about what the difference is > between > > a network model and a device model? A network is a plurality of devices, > > and a network model is something which deals with a system resulting from > > the use of more than one device. (ok, yes, a network of one node is a > corner > > case blah blah handwave...). I don't see how there could be any real > debate > > around this, but if there is I'm quite interested in what it might be. > > Agreed--both seem necessary, but different beasts (see the > discussion on > sdnrg right now --same problem, different names). > > > It feels like the real question is whether i2rs should have network models > in > > scope. > > Right... > > I think network models at this point in the game might be > useful to make > certain we are getting all the information we need from the > models at the > protocol and device levels... In other words, there are > things the network > model cares about that a device model isn't going to care > about. In other > words, if we only look at protocol level use cases, we might > miss some > pieces of information we'll eventually need for building > network topologies, > or that sort of thing. > > > If Yes: ok, cool. But between link properties (that is, at least some > kind of > > topology view), counter dumps, debugs, routing, MPLS, and LAG member > > rebalancing, show me what's *not* in scope. > > This is the problem on the other end, however... It's > better, IMHO, to start > with a single small set of problems and solve them in a way that > specifically allows extensions to solve other problems. If > we try to model > every possible problem, to make certain we have accounted > for every possible > situation, well, we'll never actually do anything but > describe problems. I'm > pretty familiar with the "describing problems all the time" > process, as I > have kids... :-) (Oh, I'm glad they don't read this list, > because they'd > really be mad at me about now!). > > So I think it's valuable to describe these network models, > and think about > them. OTOH, I'm really concerned we're going to get bogged > down in them, and > take up a lot of time reading and accounting for them, which > could well > divert us (even more!) from picking a small set of > well-defined problems and > solving them in an extensible way. I think that's the point > Joel was trying > to make at the mic today, btw... > > :-) > > Russ > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > BR, > > Nikolay Milovanov > Network Engineer > Email: n.milovanov@gmail.com > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From jmedved@cisco.com Thu Nov 7 08:50:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8111E81E2 for ; Thu, 7 Nov 2013 08:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJQazUt7nTyQ for ; Thu, 7 Nov 2013 08:50:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEFD21E8121 for ; Thu, 7 Nov 2013 08:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2935; q=dns/txt; s=iport; t=1383842961; x=1385052561; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BN5ipqutn9xPBzEwPhQBmIe6pg61mOJd9ikUOjI1mRg=; b=eJrlpjfnrQe3VpPJLurpHjdBCeqwOCaUyXBxhqUm9JMH0jW7oI5vw9r8 7sL1RE8n6SJLhhLJG39VxwsyxdAqGDQps9zvB+cdW0r6y36JLskzdRuBN P9KHFhav4qHdUqLPwQr+lAWcwu7pKIvKosWbBaiwsAQT2s39+LCLfGMEW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFANHDe1KtJXG9/2dsb2JhbABXA4MHOFO/DoElFnSCJQEBAQQBAQE3NAsOBAEIDgIIHisMCyUCBAENBYgBDbxnBI9FEAcRhB8DmAyBL4kjhziBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="scan'208";a="281974593" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 07 Nov 2013 16:49:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7GnKVp013247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:49:20 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.189]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:49:20 -0600 From: "Jan Medved (jmedved)" To: Juergen Schoenwaelder , Russ White Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO28k3WGAZC6nZSUaK69XxbB+m5poZ2X8A Date: Thu, 7 Nov 2013 16:49:19 +0000 Message-ID: In-Reply-To: <20131107145347.GA87679@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.145.194] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ladislav Lhotka , "i2rs@ietf.org" , 'Alia Atlas' , "Eric Osborne \(eosborne\)" , 'Nikolay Milovanov' Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:50:36 -0000 Hi Juergen On 11/7/13 6:53 AM, "Juergen Schoenwaelder" wrote: >On Thu, Nov 07, 2013 at 09:21:38AM -0500, Russ White wrote: >>=20 >> > If we have a device-centric model showing interfaces and so on, then >> there's >> > not a good way to express the learned IGP topology. Would we then >>need a >> > different IM - perhaps as part of an IGP-specific IM - to communicate >>the >> > topology learned via the IGP? Would that be preferable? >>=20 >> Yes, you are going to need different network models for different >>protocols, >> services, etc. There's not going to be any way to combine such models >>into a >> "coherent whole." >>=20 > >Data models for different protocols such as OSPF or BGP have so far >been done in WGs that care about those protocols and this has >generally worked well as far as I can tell. We are now moving towards >YANG models for configuration and state data and a general framework >for YANG routing models has been defined in the NETMOD WG [1] (the >next update of this document will go to WG last call). We expect that >BGP, OSPF, ... specific extensions of this core routing model will be >produced and we envision that this work takes place in the routing >area, e.g., in WGs maintaining these routing protocols. Of course, >we first need concrete proposals to start from. > >I think what I am saying is that (a) there is work going on outside of >I2RS and we better avoid overlapping activities and (b) I like to >remind you that work can be split and it is not necessary that I2RS >creates all data models on its own. I2RS is not chartered to develop data models - it's chartered to develop *information models*. Not that I agree or disagree, I am just pointing out a subtle difference, which however has a practical impact: for example, for the topology model, we first developed a yang data model which was presented in the netmod WG. Then we also created a corresponding information model which was presented in the i2rs WG. For the I2RS RIB information model, there is a corresponding RIB yang data model, where we worked with Lada and aligned it with [1]. We would want to present it at the next IETF. So, there are no overlapping activities - the way the I2RS charter is defined, the WG operates at a different level. It has yet to decide what data modeling language should be adopted for i2rs, or whether data models would be developed in the WG. > >/js Thanks, Jan > >[1] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11 > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From prvs=80231452d2=hshah@ciena.com Thu Nov 7 09:06:27 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69321E8167 for ; Thu, 7 Nov 2013 09:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvSlVBX2EJAu for ; Thu, 7 Nov 2013 09:06:21 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63121E81D1 for ; Thu, 7 Nov 2013 09:06:16 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id rA7H4BVB030396; Thu, 7 Nov 2013 12:06:13 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1g0cqerqa3-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Nov 2013 12:06:13 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 7 Nov 2013 12:06:08 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Thu, 7 Nov 2013 12:05:55 -0500 From: "Shah, Himanshu" To: Alia Atlas , "i2rs@ietf.org" Date: Thu, 7 Nov 2013 12:05:54 -0500 Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: Ac7bYFdYtSdhlGxaSy68oQSDxnhcbwAespTA Message-ID: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> References: In-Reply-To: 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_40746B2300A8FC4AB04EE722A593182B69F84BCAONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20276.000 X-TM-AS-Result: No--8.271700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-07_05:2013-11-07, 2013-11-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311070124 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:06:27 -0000 --_000_40746B2300A8FC4AB04EE722A593182B69F84BCAONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given the discussions in the other thread, I would assume that nothing in I= 2RS is network centric, it is only device centric and interface between client and agent pair, anything beyond that is, out-o= f-scope, right?? /Himanshu From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Wednesday, November 06, 2013 9:23 PM To: i2rs@ietf.org Subject: [i2rs] topology info model - what makes it a "network" model vs. a= "device" model I'd really like to start a conversation about the differences between a top= ology IM model that is network-centric vs. device-centric. Clearly the WG = has strong and different opinions about it. Since many people are here in Vancouver, focused on IETF and not their day-= jobs, this seems like a good time to get it rolling... Alia --_000_40746B2300A8FC4AB04EE722A593182B69F84BCAONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given the= discussions in the other thread, I would assume that nothing in I2RS is ne= twork centric, it is only device centric

and interface between client and agent pair, anything bey= ond that is, out-of-scope, right??

 

/Himan= shu

 

From: i2rs-bounces@ietf.org [mailto:i2rs-bou= nces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, No= vember 06, 2013 9:23 PM
To: i2rs@ietf.org
Subject: [i2r= s] topology info model - what makes it a "network" model vs. a &q= uot;device" model

 = ;

I'd really like to start a conversatio= n about the differences between a topology IM model that is network-centric= vs. device-centric.  Clearly the WG has strong and different opinions= about it. 

 <= /p>

Since many people are here in Vancouver,= focused on IETF and not their day-jobs, this seems like a good time to get= it rolling...

 

Alia

= --_000_40746B2300A8FC4AB04EE722A593182B69F84BCAONWVEXCHMB04cie_-- From n.milovanov@gmail.com Thu Nov 7 09:16:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63F621E81E8 for ; Thu, 7 Nov 2013 09:16:11 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNXEXRDWR1BC for ; Thu, 7 Nov 2013 09:15:45 -0800 (PST) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D6B7E11E826A for ; Thu, 7 Nov 2013 09:15:41 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id r7so348355bkg.4 for ; Thu, 07 Nov 2013 09:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=7Maih4KxrgQczdpIqpo3W7tlNO4zKtlm8iCBnTfOlN4=; b=viXbXUTLsTuX+elv+xilnrTNJYHhGMy3oTcAU540VQtrE166IIBc/HYnXU+9eobqEH 2lQmXSUJPoCW2PRjf9dDYtdfuV2/yUYTx/FMV91f/Kf9ITLF4gH3AoAvzkHrFmTfb7IQ JMFHD8558c1VGwIZ96oKiu7PBWznfaUOPVdZ1y4NgZ+MK3U6V3M570MDpBMdx+fp8ydg zge1UPAiYCNZPJOmUT2sWWbcMX+kbqKJnnOPTds2XjUH+EVGiWGcuoRE40yWLC9nCiNJ CWv1I36kYq1aEXLm+vJtYDe67XElhzA4LxHUISO+3stJsQnLfqgjanI0mlQyOq3DAiZA Cf8A== X-Received: by 10.204.243.2 with SMTP id lk2mr54115bkb.94.1383844540166; Thu, 07 Nov 2013 09:15:40 -0800 (PST) Received: from [10.10.12.106] ([93.155.231.113]) by mx.google.com with ESMTPSA id t2sm3032427bkh.3.2013.11.07.09.15.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 09:15:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_FE7F83CC-0FC8-4B82-96F2-6AD3FC62E7A9" From: Nikolay Milovanov In-Reply-To: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> Date: Thu, 7 Nov 2013 19:15:34 +0200 Message-Id: <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> To: "Shah, Himanshu" X-Mailer: Apple Mail (2.1283) Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:16:12 -0000 --Apple-Mail=_FE7F83CC-0FC8-4B82-96F2-6AD3FC62E7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Isn't it a case that we will have a device information model which will = contain information also about a topology view as seen from the = perspective of the particular device.=20 In the end to build a network centric info/data model out of this the = network topology manager will have to collect and transform information = gained from many network devices.=20 Nikolay On Nov 7, 2013, at 7:05 PM, Shah, Himanshu wrote: > Given the discussions in the other thread, I would assume that nothing = in I2RS is network centric, it is only device centric > and interface between client and agent pair, anything beyond that is, = out-of-scope, right?? > =20 > /Himanshu > =20 > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf = Of Alia Atlas > Sent: Wednesday, November 06, 2013 9:23 PM > To: i2rs@ietf.org > Subject: [i2rs] topology info model - what makes it a "network" model = vs. a "device" model > =20 > I'd really like to start a conversation about the differences between = a topology IM model that is network-centric vs. device-centric. Clearly = the WG has strong and different opinions about it.=20 > =20 > Since many people are here in Vancouver, focused on IETF and not their = day-jobs, this seems like a good time to get it rolling... > =20 > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_FE7F83CC-0FC8-4B82-96F2-6AD3FC62E7A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Isn't it a case that we will have a device = information model which will contain information also about a topology = view as seen from the perspective of the particular = device. 

In the end to build a network centric = info/data model out of this the network topology manager will have to = collect and transform information gained from many network = devices. 

Nikolay
On = Nov 7, 2013, at 7:05 PM, Shah, Himanshu wrote:

Given the discussions in the other thread, I would assume that = nothing in I2RS is network centric, it is only device = centric
and interface between client and agent pair, anything beyond = that is, out-of-scope, right??
/Himanshu
 
 i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org= ] On Behalf Of Alia = Atlas
Sent: Wednesday, November 06, = 2013 9:23 PM
To: i2rs@ietf.org
Subject: [i2rs] topology info model = - what makes it a "network" model vs. a "device" = model
I'd really like to start = a conversation about the differences between a topology IM model that is = network-centric vs. device-centric.  Clearly the WG has strong and = different opinions about it. 
 
Since many people are here in Vancouver, focused on = IETF and not their day-jobs, this seems like a good time to get it = rolling...
To: Alia Atlas , Nikolay Milovanov Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO24mF/r3z/EHLnkmiazH9YecmkZoZZ26AgACd7RA= Date: Thu, 7 Nov 2013 17:59:45 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.25] Content-Type: multipart/alternative; boundary="_000_A46D9C092EA46F489F135060986AD9FFC8442BG6W2492americashp_" MIME-Version: 1.0 Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:01:40 -0000 --_000_A46D9C092EA46F489F135060986AD9FFC8442BG6W2492americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From an IM standpoint a network wide view is useful to "scope" the view. Then you could map various views of the device with ever increasing scope: 1) What is contained on the device (local configured) 2) What is contained on the device in the RIB/interfaces etc(local operatio= nal state: Interface, connection/MPLS LSP etc) 3) What is contained in the various IGP/EGP databases etc , (local from 2 p= ut in Device LSAs/TE etc). 4 )What is contained in the various IGP/EGP databases etc (Local and neighb= or view). These are ever increasing subsets of the complete Network information model= but they are not the complete Network model. And each level does not conta= in the level below but may only see a summary/partial view. In my view you could stop at 3 and still get a complete Network model by ex= tracting up to 3 on every device. Whether you included below 3 which is no= t really visible to routing is also a question. Including 4 would seem to be a cross check of what is in 3 but it has incre= asing temporal issues. I'd argue for 3. Don From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Thursday, November 07, 2013 2:59 AM To: Nikolay Milovanov Cc: Russ White; i2rs@ietf.org; Eric Osborne (eosborne) Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model Hi, Yes - so what I'm really trying to do is elicit what the points of concern = and different options are as far as modeling the topology information from = a device. draft-medved-i2rs-topology-im has changed only minimally since = last IETF - and in ways that don't seem to address any of the disagreements= or concerns. We need to be sure to bite off the right-sized first chunk to do. If we have a device-centric model showing interfaces and so on, then there'= s not a good way to express the learned IGP topology. Would we then need a= different IM - perhaps as part of an IGP-specific IM - to communicate the = topology learned via the IGP? Would that be preferable? Given that the active IGP topology can be learned via BGP-LS, are we better= off focusing on an interface-focused IM (whether that is a device model or= an interfaces model or...)? I'd really like to make significant progress in understanding the perspecti= ves and thoughts of the WG on this. I understand that all these things ma= y be useful but in our usual ocean-boiling-avoidance method, we've got to p= rioritize. I'm also not comfortable on having only one IM for basing all our requireme= nts off of. So - more thoughts? Alia On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov > wrote: Hi, I might be completely wrong but from a brief overview of the Topology API U= se Cases my guess would be. The topology data model will be an undirected graph with nodes, edges with = certain properties representing part of the network topology and the devic= e centric model will be something hierarchical with a root object the netwo= rk device its interfaces, their IPs, the protocols working on them and the = neighbor devices learned dynamically by those protocols. Most likely the network-centric topology models coming from each of the dev= ices will have to be merged by the network topology manager in order the re= st of the applications to be able to benefit from a complete model of the e= ntire network topology. In my opinion either of the models will be extremely useful for all kinds o= f OSS applications related to network service provisioning and fulfillment.= Currently is quite difficult to build any of them by means such as CLI par= sing and SNMP. Netconf is not bad but still an API will be much better :) BR, Nikolay Milovanov Network Engineer n.milovanov@gmail.com On Thu, Nov 7, 2013 at 8:16 AM, Russ White > wrote: > Are there really differences of opinion about what the difference is between > a network model and a device model? A network is a plurality of devices, > and a network model is something which deals with a system resulting from > the use of more than one device. (ok, yes, a network of one node is a corner > case blah blah handwave...). I don't see how there could be any real debate > around this, but if there is I'm quite interested in what it might be. Agreed--both seem necessary, but different beasts (see the discussion on sdnrg right now --same problem, different names). > It feels like the real question is whether i2rs should have network model= s in > scope. Right... I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network model cares about that a device model isn't going to care about. In other words, if we only look at protocol level use cases, we might miss some pieces of information we'll eventually need for building network topologies= , or that sort of thing. > If Yes: ok, cool. But between link properties (that is, at least some kind of > topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope. This is the problem on the other end, however... It's better, IMHO, to star= t with a single small set of problems and solve them in a way that specifically allows extensions to solve other problems. If we try to model every possible problem, to make certain we have accounted for every possibl= e situation, well, we'll never actually do anything but describe problems. I'= m pretty familiar with the "describing problems all the time" process, as I have kids... :-) (Oh, I'm glad they don't read this list, because they'd really be mad at me about now!). So I think it's valuable to describe these network models, and think about them. OTOH, I'm really concerned we're going to get bogged down in them, an= d take up a lot of time reading and accounting for them, which could well divert us (even more!) from picking a small set of well-defined problems an= d solving them in an extensible way. I think that's the point Joel was trying to make at the mic today, btw... :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs -- BR, Nikolay Milovanov Network Engineer Email: n.milovanov@gmail.com --_000_A46D9C092EA46F489F135060986AD9FFC8442BG6W2492americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

From an IM standpoint a n= etwork wide view is useful to “scope” the view.

 <= /p>

Then you could map variou= s views of the device with ever increasing scope:

1) What is contained on t= he device (local configured)

2) What is contained on t= he device in the RIB/interfaces etc(local operational state: Interface, con= nection/MPLS LSP etc)

3) What is contained in t= he various IGP/EGP databases etc , (local from 2 put in Device LSAs/TE etc)= .

4 )What is contained in t= he various IGP/EGP databases etc (Local and neighbor view).

 <= /p>

These are ever increasing= subsets of the complete Network information model but they are not the com= plete Network model. And each level does not contain the level below but may only see a summary/partial view.  

In my view you could stop= at 3 and still get a complete Network model by extracting up to 3 on every= device.  Whether you included below 3 which is not really visible to routing is also a question.

Including 4 would seem to= be a cross check of what is in 3 but it has increasing temporal issues.

 <= /p>

I’d argue for 3.

 <= /p>

Don

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Thursday, November 07, 2013 2:59 AM
To: Nikolay Milovanov
Cc: Russ White; i2rs@ietf.org; Eric Osborne (eosborne)
Subject: Re: [i2rs] topology info model - what makes it a "netw= ork" model vs. a "device" model

 

Hi,

 

Yes - so what I'm really trying to do is elicit what= the points of concern and different options are as far as modeling the top= ology information from a device.   draft-medved-i2rs-topology-im has c= hanged only minimally since last IETF - and in ways that don't seem to address any of the disagreements or concern= s.


We need to be sure to bite off the right-sized first chunk to do.

 

If we have a device-centric model showing interfaces= and so on, then there's not a good way to express the learned IGP topology= .  Would we then need a different IM - perhaps as part of an IGP-speci= fic IM - to communicate the topology learned via the IGP?  Would that be preferable?

 

Given that the active IGP topology can be learned vi= a BGP-LS, are we better off focusing on an interface-focused IM (whether th= at is a device model or an interfaces model or...)?

 

I'd really like to make significant progress in unde= rstanding the perspectives and thoughts of the WG on this.   I underst= and that all these things may be useful but in our usual ocean-boiling-avoi= dance method, we've got to prioritize.  

 

I'm also not comfortable on having only one IM for b= asing all our requirements off of.

 

So - more thoughts?

 

Alia

 

On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov &l= t;n.milovanov@gm= ail.com> wrote:

Hi,

 

I might be completely wrong but from a brief overvie= w of the Topology API Use Cases my guess would be. 

 

The topology data model will be an undirected graph = with nodes, edges with certain properties representing part of the network = topology  and the device centric model will be something hierarchical = with a root object the network device its interfaces, their IPs, the protocols working on them and the neighbor devi= ces learned dynamically by those protocols.   

 

Most likely the network-centric topology models comi= ng from each of the devices will have to be merged by the network topology = manager in order the rest of the applications to be able to benefit from a = complete model of the entire network topology. 

 

In my opinion either of the models will be extremely= useful for all kinds of OSS applications related to network service provis= ioning and fulfillment. Currently is quite difficult to build any of them b= y means such as CLI parsing and SNMP. Netconf is not bad but still an API will be much better :)

 

 

BR, 

Nikolay Milovanov

 

Network Engineer

 

 

 

On Thu, Nov 7, 2013 at 8:16 AM, Russ White <russw@riw.us> wrote:


> Are there really differences of opinion about what the difference is between
> a network model and a device model?  A network is a plurality of = devices,
> and a network model is something which deals with a system resulting f= rom
> the use of more than one device.  (ok, yes, a network of one node= is a
corner
> case blah blah handwave...).  I don't see how there could be any = real
debate
> around this, but if there is I'm quite interested in what it might be.=

Agreed--both seem necessary, but different beasts (s= ee the discussion on
sdnrg right now --same problem, different names).


> It feels like the real question is whether i2rs should have network mo= dels
in
> scope.

Right...

I think network models at this point in the game might be useful to make certain we are getting all the information we need from the models at the protocol and device levels... In other words, there are things the network<= br> model cares about that a device model isn't going to care about. In other words, if we only look at protocol level use cases, we might miss some
pieces of information we'll eventually need for building network topologies= ,
or that sort of thing.


> If Yes: ok, cool.  But between link properties (that is, at least= some
kind of
> topology view), counter dumps, debugs, routing, MPLS, and LAG member > rebalancing, show me what's *not* in scope.

This is the problem on the other end, however... It'= s better, IMHO, to start
with a single small set of problems and solve them in a way that
specifically allows extensions to solve other problems. If we try to model<= br> every possible problem, to make certain we have accounted for every possibl= e
situation, well, we'll never actually do anything but describe problems. I'= m
pretty familiar with the "describing problems all the time" proce= ss, as I
have kids... :-) (Oh, I'm glad they don't read this list, because they'd really be mad at me about now!).

So I think it's valuable to describe these network models, and think about<= br> them. OTOH, I'm really concerned we're going to get bogged down in them, an= d
take up a lot of time reading and accounting for them, which could well
divert us (even more!) from picking a small set of well-defined problems an= d
solving them in an extensible way. I think that's the point Joel was trying=
to make at the mic today, btw...

:-)

Russ



_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs



 

--
BR,

Nikolay Milovanov
Network Engineer
Email: n.milovanov@gmail.com

 

--_000_A46D9C092EA46F489F135060986AD9FFC8442BG6W2492americashp_-- From tnadeau@lucidvision.com Thu Nov 7 10:32:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066CB21E8143 for ; Thu, 7 Nov 2013 10:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph8aBqh7WUrT for ; Thu, 7 Nov 2013 10:32:07 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9DD11E822F for ; Thu, 7 Nov 2013 10:32:01 -0800 (PST) Received: from dhcp-9087.meeting.ietf.org (dhcp-9087.meeting.ietf.org [31.133.144.135]) by lucidvision.com (Postfix) with ESMTP id 1DF3325E18E7; Thu, 7 Nov 2013 13:31:58 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_21ED3C3C-7249-425D-949E-00D2E9CCDD73"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 7 Nov 2013 10:31:55 -0800 Message-Id: <9EFFED55-3203-42E1-9389-D347768FA000@lucidvision.com> References: To: "jmedved Medved (jmedved)" X-Mailer: Apple Mail (2.1816) Cc: "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Juergen Schoenwaelder , Ladislav Lhotka , Alia Atlas , Russ White , Nikolay Milovanov Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:32:24 -0000 --Apple-Mail=_21ED3C3C-7249-425D-949E-00D2E9CCDD73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 7, 2013:8:49 AM, at 8:49 AM, Jan Medved (jmedved) = wrote: > Hi Juergen >=20 > On 11/7/13 6:53 AM, "Juergen Schoenwaelder" > wrote: >=20 >> On Thu, Nov 07, 2013 at 09:21:38AM -0500, Russ White wrote: >>>=20 >>>> If we have a device-centric model showing interfaces and so on, = then >>> there's >>>> not a good way to express the learned IGP topology. Would we then >>> need a >>>> different IM - perhaps as part of an IGP-specific IM - to = communicate >>> the >>>> topology learned via the IGP? Would that be preferable? >>>=20 >>> Yes, you are going to need different network models for different >>> protocols, >>> services, etc. There's not going to be any way to combine such = models >>> into a >>> "coherent whole." >>>=20 >>=20 >> Data models for different protocols such as OSPF or BGP have so far >> been done in WGs that care about those protocols and this has >> generally worked well as far as I can tell. We are now moving towards >> YANG models for configuration and state data and a general framework >> for YANG routing models has been defined in the NETMOD WG [1] (the >> next update of this document will go to WG last call). We expect that >> BGP, OSPF, ... specific extensions of this core routing model will be >> produced and we envision that this work takes place in the routing >> area, e.g., in WGs maintaining these routing protocols. Of course, >> we first need concrete proposals to start from. >>=20 >> I think what I am saying is that (a) there is work going on outside = of >> I2RS and we better avoid overlapping activities and (b) I like to >> remind you that work can be split and it is not necessary that I2RS >> creates all data models on its own. >=20 > I2RS is not chartered to develop data models - it's chartered to = develop > *information models*. Not that I agree or disagree, I am just pointing = out > a subtle difference, which however has a practical impact: for = example, > for the topology model, we first developed a yang data model which was > presented in the netmod WG. Then we also created a corresponding > information model which was presented in the i2rs WG. For the I2RS RIB > information model, there is a corresponding RIB yang data model, where = we > worked with Lada and aligned it with [1]. We would want to present it = at > the next IETF. >=20 > So, there are no overlapping activities - the way the I2RS charter is > defined, the WG operates at a different level. It has yet to decide = what > data modeling language should be adopted for i2rs, or whether data = models > would be developed in the WG. Spot on.=20 --Tom >=20 >=20 >=20 >>=20 >> /js >=20 >=20 > Thanks, > Jan >=20 >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_21ED3C3C-7249-425D-949E-00D2E9CCDD73 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSe9ybAAoJEPcO+I7eiUJZQwMP/A1cu+LRjJCGHlLxPczf87DV izNCuqEsTP3OrHBN7wXkYDUgmgefZbpNHUj30/EEdQexA7YClRfoj7xkptBRYtxD aGaMbjptE1mv6gOth+ZuuO9MoK/Tfc6kNeasdcX/Z281HgiOUySPE8nYYN8h88wb lhA6MYoA7dQPmpTEXu1n2Pgu45cBKKjwSlyvwGTSkYWBoF0ieRlgygzM55Ytsnn2 k7la3UoZS0G2Q6P12OSRm0UKvJ0wFyL/Q/QLH2Me0SaXPWkpMdOsXrti/2sZ6r9h uUSUD0lRQdZ1Z9qR0ElUCCtFCHpqdfcHUWVwUdNafQTw50dhvpToiRUNcrG2PN9K L4whgCeK1doHPiHr+faSwv92GtSwS/lIvPMhxXcPkOa9BoxB1QdDXCcsgMbgxCWE zAFa0ji67wf8kf6p6k0yCHXZPstWN9uqDThm3lO9u9+L/Wr8OgrgZIZv3TloMNac JJ3JKt3UORqysEJC4ZRAi0D01RHTsfiy6KbyfF3nJ6rEXqUcWtyPD/FE7juyqazd gQ0hAXinfoOGxc3k3mI8Bv4r62bpFWjloGkmaSWjvJJyhHByOh1taSprufOmylix o5lL8LcYgaL3L73KyvAbzu2Ansj8Idga/wVjG2eXCdM81mQ28oFd4KgaL7yn/tuu mm72h+Nj0DIljguoPoGK =KjPM -----END PGP SIGNATURE----- --Apple-Mail=_21ED3C3C-7249-425D-949E-00D2E9CCDD73-- From j.schoenwaelder@jacobs-university.de Thu Nov 7 10:41:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A8921E8213 for ; Thu, 7 Nov 2013 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urc51slYygBY for ; Thu, 7 Nov 2013 10:40:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36D21E821B for ; Thu, 7 Nov 2013 10:40:05 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D90E3200AF; Thu, 7 Nov 2013 19:40:01 +0100 (CET) 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 DydiIwGY0JlD; Thu, 7 Nov 2013 19:40:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBB0820068; Thu, 7 Nov 2013 19:40:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0C6CE2931B22; Thu, 7 Nov 2013 19:39:54 +0100 (CET) Date: Thu, 7 Nov 2013 19:39:54 +0100 From: Juergen Schoenwaelder To: "Jan Medved (jmedved)" Message-ID: <20131107183953.GA89247@elstar.local> Mail-Followup-To: "Jan Medved (jmedved)" , Russ White , "Eric Osborne (eosborne)" , "i2rs@ietf.org" , 'Nikolay Milovanov' , 'Alia Atlas' , Ladislav Lhotka References: <20131107145347.GA87679@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: "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Ladislav Lhotka , 'Alia Atlas' , Russ White , 'Nikolay Milovanov' Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:41:13 -0000 On Thu, Nov 07, 2013 at 04:49:19PM +0000, Jan Medved (jmedved) wrote: > > I2RS is not chartered to develop data models - it's chartered to develop > *information models*. Not that I agree or disagree, I am just pointing out > a subtle difference, which however has a practical impact: for example, > for the topology model, we first developed a yang data model which was > presented in the netmod WG. Then we also created a corresponding > information model which was presented in the i2rs WG. For the I2RS RIB > information model, there is a corresponding RIB yang data model, where we > worked with Lada and aligned it with [1]. We would want to present it at > the next IETF. > > So, there are no overlapping activities - the way the I2RS charter is > defined, the WG operates at a different level. It has yet to decide what > data modeling language should be adopted for i2rs, or whether data models > would be developed in the WG. > Yes, I am aware of the difference. The point, however, is that creating consistent data and information models that provide a reasonable coverage is a huge task and it either requires very tight coordination between WGs running at different speeds or a kitchen sink WG that tries to get all done in one place. Both options are very difficult to implement in the IETF. At the end of the day, it is not useful for running networks if information models and data models developed within the IETF are not consistent. So from a larger perspective, there is an interesting scoping and coordination challenge here that we need to manage somehow. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From shane@castlepoint.net Thu Nov 7 11:12:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B5711E822F for ; Thu, 7 Nov 2013 11:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkYwkSgHvUkA for ; Thu, 7 Nov 2013 11:12:17 -0800 (PST) Received: from mail.tcb.net (mail.tcb.net [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF4A11E8238 for ; Thu, 7 Nov 2013 11:12:17 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.tcb.net (Postfix) with SMTP id EC241300056 for ; Thu, 7 Nov 2013 19:12:16 +0000 (UTC) Received: from dhcp-8c82.meeting.ietf.org (dhcp-8c82.meeting.ietf.org [31.133.140.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 70CF830004C; Thu, 7 Nov 2013 12:12:15 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7BFF5E57-CCA6-439D-A7C3-FF4C8241E0FC" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Shane Amante In-Reply-To: <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> Date: Thu, 7 Nov 2013 11:12:14 -0800 Message-Id: <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net> References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> To: Nikolay Milovanov X-Mailer: Apple Mail (2.1812) X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Nov 7 12:12:16 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 527be61042071308981771 X-DSPAM-Factors: 27, 2013+at, 0.40000, 2013+at, 0.40000, what's+#+#+#+allows, 0.40000, what's+#+#+#+allows, 0.40000, milovanov+gmail, 0.40000, milovanov+gmail, 0.40000, two+#+#+together, 0.40000, two+#+#+together, 0.40000, network+#+#+#+collection, 0.40000, network+#+#+#+collection, 0.40000, to+#+#+#+an, 0.40000, to+#+#+#+an, 0.40000, be+#+a, 0.40000, be+#+a, 0.40000, Nikolay+Milovanov, 0.40000, Nikolay+Milovanov, 0.40000, Subject*topology+#+#+#+what, 0.40000, Subject*model+#+#+#+it, 0.40000, the+#+#+as, 0.40000, the+#+#+as, 0.40000, Subject*topology+info, 0.40000, with+#+a, 0.40000, with+#+a, 0.40000, devices+talk, 0.40000, devices+talk, 0.40000, NE's+#+on, 0.40000, NE's+#+on, 0.40000 Cc: "i2rs@ietf.org" , "Shah, Himanshu" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:12:25 -0000 --Apple-Mail=_7BFF5E57-CCA6-439D-A7C3-FF4C8241E0FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov = wrote: > In the end to build a network centric info/data model out of this the = network topology manager will have to collect and transform information = gained from many network devices.=20 +1. I believe I may be observing a tension between the traditional IETF view = of "how do I make two devices communicate together", i.e.: what's the = protocol that allows that communication to occur robustly, vs. an = operator view of "Sure, I need protocols to make two devices talk to = each other, but what's more critical for my business is to look at the = whole network, which is a collection of devices". A Network Topology = Information Model would assist operators with having a cohesive view of = the overall "network as a system", because that's the foundation upon = which _services_ are delivered ... both within the data-path between = various NE's and on top of various NE's. =20 So, +1 to network-centric topology IM model. =20 -shane --Apple-Mail=_7BFF5E57-CCA6-439D-A7C3-FF4C8241E0FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 7, 2013, at 9:15 AM, Nikolay = Milovanov <n.milovanov@gmail.com> = wrote:
In the end to build a network centric info/data model out = of this the network topology manager will have to collect and transform = information gained from many network devices. 

+1.
<= div>
I believe I may be observing a tension between the = traditional IETF view of "how do I make two devices communicate = together", i.e.: what's the protocol that allows that communication to = occur robustly, vs. an operator view of "Sure, I need protocols to make = two devices talk to each other, but what's more critical for my business = is to look at the whole network, which is a collection of devices". =  A Network Topology Information Model would assist operators with = having a cohesive view of the overall "network as a system", because = that's the foundation upon which _services_ are delivered ... both = within the data-path between various NE's and on top of various NE's. =  

So, +1 to network-centric topology IM = model. =  

-shane


= = --Apple-Mail=_7BFF5E57-CCA6-439D-A7C3-FF4C8241E0FC-- From jclarke@cisco.com Thu Nov 7 12:39:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3812C21E8089 for ; Thu, 7 Nov 2013 12:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QKDBoxmmpmy for ; Thu, 7 Nov 2013 12:39:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2193E21E809F for ; Thu, 7 Nov 2013 12:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1176; q=dns/txt; s=iport; t=1383856759; x=1385066359; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=np/iqv0VB4RgJL10dqw1KW+2eVAC5GbinKrE3k9DztI=; b=cMye+6qH1V+0JcDWOh3+n8pq0I1YqhWP6SYOHrC0GbS98TGDAkSVAQmf qEoxVH0m5IAxce6bb3N928UD4w4XDOcMbYDESyNJSFr/7PkRPmw/iiH9Z Sb6RL8wmcnip9DAqbfJON/l7XZ3GFYcYtIOQh0EbitPItHldT+tGZPvhx M=; X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="93605887" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 07 Nov 2013 20:39:17 +0000 Received: from sjc-vpn2-1287.cisco.com (sjc-vpn2-1287.cisco.com [10.21.117.7]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7KdFZm023211; Thu, 7 Nov 2013 20:39:15 GMT Message-ID: <527BFA73.70108@cisco.com> Date: Thu, 07 Nov 2013 15:39:15 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" , Alia Atlas , "i2rs@ietf.org" References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 20:39:33 -0000 On 11/7/13, 12:11 AM, Eric Osborne (eosborne) wrote: > If Not: what problems arise that would be solved by having a network model, do we need one, and where would it come from if not i2rs? I think it is useful to have a network-wide topology model that is accessible at a device level. Meaning, topology could be distributed into the network and retrievable either as a whole network or in parts based on filters. For example, given an I2RS Agent, give me the Agent plus two routed hops. This would be very useful, for example, in the support case where we need to understand what a network looks like in order to help troubleshoot problems. But, I could also ask this same Agent to give me the whole routed network from a given instance. This would give me the graph (edges, nodes) of that topology. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From eosborne@cisco.com Thu Nov 7 12:51:42 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7605D21E818D for ; Thu, 7 Nov 2013 12:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MbTwLEbKZRB for ; Thu, 7 Nov 2013 12:51:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6015421E81CE for ; Thu, 7 Nov 2013 12:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2568; q=dns/txt; s=iport; t=1383857494; x=1385067094; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZT2E7YB6Fc/zD38ivQxhcsm4u42vP+DJv6MCFuqfpK4=; b=nFZgMVa32vJfC2Dl8u42UV8pi0x4LF+tIeygAMGyJV/oCaD9sCZ5YN1H bf4MZX82HDICP1U2fS7sx+SYqaoP/dNtiRMVJUwifKMUg9s44TroezQWW xzvgJS/BeMV6NWTYZd7ACljElzt9LmGmPG2bT3wLF/Tk1HItwdlYN3uF+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAI78e1KtJXHA/2dsb2JhbABXA4MHgQu/DoEmFnSCJQEBAQQ6SwICAgEIEQQBAQEKFBAbFx0IAgQBEgiHeb0IBI4MgRghFwYLgw+BEAOULI4yhziBaIE+gXE5 X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="279155469" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2013 20:51:34 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA7KpXC6026899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 20:51:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 14:51:33 -0600 From: "Eric Osborne (eosborne)" To: "Joe Clarke (jclarke)" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO22BfjXVgSCqIVkWy1YdjiTTe+ZoZNw3AgAFpn4D//50VsA== Date: Thu, 7 Nov 2013 20:51:32 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> In-Reply-To: <527BFA73.70108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 20:51:42 -0000 If you want to get the link state for an entire network there are two ways = to do it: 1) the i2rs client fetches each node's link state info from that node, and = plugs them together to make a network, 2) the i2rs client fetches the entire LSDB from one node. =20 IMO either one is OK, and #2 makes the most sense. In any case it's a read= -only thing so it doesn't really matter how it gets done. Where it gets hairy is when you want to write to the network. The question= that kicked off this thread was along those lines, if I recall. If you wa= nt to get a mutex on the network as a whole you *need* a way to lock all de= vices. Perhaps this is best done in the client - acquire a lock on the con= fig for each node in the network, make your changes, then unlock. If there= were a higher level way to do this with some sort of network API that's wh= at it would have to do under the covers anyways. And if you have locking w= rite access to the client then you don't need a network model, just a route= r model. eric > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Thursday, November 07, 2013 12:39 PM > To: Eric Osborne (eosborne); Alia Atlas; i2rs@ietf.org > Subject: Re: [i2rs] topology info model - what makes it a "network" > model vs. a "device" model >=20 > On 11/7/13, 12:11 AM, Eric Osborne (eosborne) wrote: > > If Not: what problems arise that would be solved by having a network > model, do we need one, and where would it come from if not i2rs? >=20 > I think it is useful to have a network-wide topology model that is > accessible at a device level. Meaning, topology could be distributed > into the network and retrievable either as a whole network or in parts > based on filters. For example, given an I2RS Agent, give me the Agent > plus two routed hops. This would be very useful, for example, in the > support case where we need to understand what a network looks like in > order to help troubleshoot problems. >=20 > But, I could also ask this same Agent to give me the whole routed > network from a given instance. This would give me the graph (edges, > nodes) of that topology. >=20 > Joe >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ------------------------------------------------------------------------ > ---- From tnadeau@lucidvision.com Thu Nov 7 13:05:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E828811E81DA for ; Thu, 7 Nov 2013 13:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5J+toiOTyHD for ; Thu, 7 Nov 2013 13:05:12 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id E237111E81A4 for ; Thu, 7 Nov 2013 13:05:11 -0800 (PST) Received: from dhcp-9087.meeting.ietf.org (dhcp-9087.meeting.ietf.org [31.133.144.135]) by lucidvision.com (Postfix) with ESMTP id F16AC25E20A1; Thu, 7 Nov 2013 16:05:09 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_8FD7B9D5-CDE3-4B32-BBFE-3ECB8194AB43"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Thomas Nadeau In-Reply-To: <527BFA73.70108@cisco.com> Date: Thu, 7 Nov 2013 13:05:06 -0800 Message-Id: <8D578A56-5626-45CE-BA70-6E0F26DAB09D@lucidvision.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1816) Cc: "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:05:17 -0000 --Apple-Mail=_8FD7B9D5-CDE3-4B32-BBFE-3ECB8194AB43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 7, 2013:12:39 PM, at 12:39 PM, Joe Marcus Clarke = wrote: > On 11/7/13, 12:11 AM, Eric Osborne (eosborne) wrote: >> If Not: what problems arise that would be solved by having a network = model, do we need one, and where would it come from if not i2rs? >=20 > I think it is useful to have a network-wide topology model that is = accessible at a device level. Meaning, topology could be distributed = into the network and retrievable either as a whole network or in parts = based on filters. =20 That is definitely the right way to go here, and is indeed = explained in the topology-related architecture. The idea is much along = the lines of a network service that lets say has a ReSTful interface = whereby you specify various filtering options in a GET request and are = returned a subset of the topology. Asking for just devices, hops, links, = etc... is just one option we definitely envisioned.=20 --Tom > For example, given an I2RS Agent, give me the Agent plus two routed = hops. This would be very useful, for example, in the support case where = we need to understand what a network looks like in order to help = troubleshoot problems. >=20 > But, I could also ask this same Agent to give me the whole routed = network from a given instance. This would give me the graph (edges, = nodes) of that topology. >=20 > Joe >=20 > --=20 > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_8FD7B9D5-CDE3-4B32-BBFE-3ECB8194AB43 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSfACCAAoJEPcO+I7eiUJZTK0QAJxGQoscpod1zok97PV3LvRu 2h3S5VDWl3CQrDC818/QWA5s0149lJThqETwHzP8G51YeB5+uwfFjzFxBI5HvLun g5+o/6Ab7XlwaIJJ0tsiBdFqZHWOoEdWFdBJT4Of/7F5oag1pDwshVCgr3sucuz1 rme2EcJTOAYZv1NxOwhAnRlDDjFYmlGGIZQaEvmOqDNFJ66I4hkKrBvAQKmeZcqC oQFtWjIAW/VbQm8du3d5lvy9T8wTbz1BWO+SmlZO0EdQ7MGIOCJjFJsTez8VfQdw QlNSwry7GqmViXfi+AzrWXGb1vlBrD4ORyMS981winkhLbJ40M3xUyZ4PfFbQyzO N7/kzgBEi/y2tWnnfg2oSuMbkJdn4tpaRZnfEbjqihcWDuGOYXTp4fv7cUUdJERx 3VV4a+qSStp1uzhSoecTLU4kxDA64++762JFuVaoBZNqKmWbtiKEjP3rEygmqusv 4EeStr/hpvRfvTFIyGdFBV2+V3xkSAKqbFprAJHBfc0n0ShlhdyDHliUXb1jbbXq d7IidPLCpVI1NtB/sAHxPpzRbou/MRyMiq3OaZlrtKelocNMYV7nzT09Qexu0Nyd IQbkKfPzXL1VvjYt0o3LR1c65ISfpk/pjBArJ3zgTLMj3UUUjcCDhMaq0ibeT3BD 54Q4VAA1XLZ7oVHqF8Pm =lmbW -----END PGP SIGNATURE----- --Apple-Mail=_8FD7B9D5-CDE3-4B32-BBFE-3ECB8194AB43-- From sriganeshkini@gmail.com Thu Nov 7 13:12:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D066D21E8092 for ; Thu, 7 Nov 2013 13:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVRos96A9IpU for ; Thu, 7 Nov 2013 13:12:29 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 73DF411E8264 for ; Thu, 7 Nov 2013 13:12:29 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kp14so1188008pab.18 for ; Thu, 07 Nov 2013 13:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9UVGRIggFW/sgZDuJJEyM2GDYa5zHnin5/I8/iePrZM=; b=NLj0wp0Dtw9zP96tpOOXh1KieBo9K5oQTQpBcXFE+bVnUFIYhGFb9A0C/UhvtUBZTs 55G3DlCJ1KylsrB62zCWZBdRp40KsklqQH73NTYFwHif4pGRqC+mXwrvIoNjYDccoHF+ VsgP6OxnVsPsXSOHIyquRToqYt4e5KkdRP52WbwsfMYQ9chR3UWKyAlRfeDTVV3QyvUu nX/ajwEQRLMrOygHOihLDbyFEBNVTu/ybqTxiif7UeyZpqKpqAVlojvMy0iVIbzExwST VXTb2el0u6yigjLbE6kmzckxAXbQjgAi3MlHK1YOKLA6BeAmYjUb2BKIBFwgAdYJurxL rxdg== X-Received: by 10.68.221.5 with SMTP id qa5mr11245850pbc.36.1383858749154; Thu, 07 Nov 2013 13:12:29 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Thu, 7 Nov 2013 13:11:58 -0800 (PST) In-Reply-To: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> From: Sriganesh Kini Date: Thu, 7 Nov 2013 13:11:58 -0800 X-Google-Sender-Auth: bnJSAKG-Ot1JUIurp1QONZ6o5_A Message-ID: To: Nikolay Milovanov Content-Type: text/plain; charset=UTF-8 Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:12:29 -0000 A critical question is whether the "merging of the models from each device" is within the scope of I2RS. Also note that "complete model of entire network topology" can be misleading. This may be true for small networks within a single administrative domain, but as the scope of the network increases (e.g. multiple administrative domains) there will not be a single way to get the "entire network topology", but there will be some details that will be abstracted out. - Sri On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov wrote: > Most likely the network-centric topology models coming from each of the > devices will have to be merged by the network topology manager in order the > rest of the applications to be able to benefit from a complete model of the > entire network topology. From alex@cisco.com Thu Nov 7 13:32:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9137811E81B3 for ; Thu, 7 Nov 2013 13:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETXa018wlfRY for ; Thu, 7 Nov 2013 13:32:41 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 234CF11E8110 for ; Thu, 7 Nov 2013 13:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3892; q=dns/txt; s=iport; t=1383859961; x=1385069561; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mxac8B/U7aLzCrJluLHEFcQ+3sgyeLrUCg7eknJ8leg=; b=lOXvPABUKVNmPk/u0nFT1EuSiRKk+TsSEKdukNQxYdAVcH8dEBYDJBDq f+6dtWjvxfgySN2xv8kKNLVywdFUHv0T6O8iBR+qZikOdLKS6dJZqASTW 026NSHc+Bh2sGlfmoL8Mdg/Z033uid+X0k80Z3RGoq0xcJ4sXVKEZJKl4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAKMGfFKtJV2c/2dsb2JhbABXA4MHOFO/DoEnFnSCJQEBAQQBAQE3NBcCAgIBCBEEAQEBChQJBxsMCxQJCAIEARIIh3kNvQgEBI4MgRghFwYLgw+BEAOULI4yhziBaIE+gXE5 X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="scan'208";a="282192020" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2013 21:32:32 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA7LWW5G006460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 21:32:32 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 15:32:31 -0600 From: "Alexander Clemm (alex)" To: "Eric Osborne (eosborne)" , "Joe Clarke (jclarke)" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO22Bf6bwscQ76RkeT4ztjVritFpoZnYGAgAEDK4CAAANvAP//ouaQ Date: Thu, 7 Nov 2013 21:32:31 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:32:46 -0000 Ultimately, many of the I2RS applications concern what you want to do with = the network, and having a model that represents an abstraction of the netwo= rk as a whole (as opposed to individual devices) seems to be core of what a= controller needs to do. I think there is therefore no question that a top= ology model is needed. The question that is debatable concerns whether the= interface that is exposed northbound of a controller (which will include a= topology model) is within scope. Even if the interface is not in scope (t= here is certainly validity to the scope creep argument), retaining the mode= l by itself in scope makes sense: as a "use case" and a source of requireme= nts (as it needs populating), and as a way to capture topology information = as it is understood by the devices themselves. =20 --- Alex -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: Thursday, November 07, 2013 12:52 PM To: Joe Clarke (jclarke); Alia Atlas; i2rs@ietf.org Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model If you want to get the link state for an entire network there are two ways = to do it: 1) the i2rs client fetches each node's link state info from that node, and = plugs them together to make a network, 2) the i2rs client fetches the entire LSDB from one node. =20 IMO either one is OK, and #2 makes the most sense. In any case it's a read= -only thing so it doesn't really matter how it gets done. Where it gets hairy is when you want to write to the network. The question= that kicked off this thread was along those lines, if I recall. If you wa= nt to get a mutex on the network as a whole you *need* a way to lock all de= vices. Perhaps this is best done in the client - acquire a lock on the con= fig for each node in the network, make your changes, then unlock. If there= were a higher level way to do this with some sort of network API that's wh= at it would have to do under the covers anyways. And if you have locking w= rite access to the client then you don't need a network model, just a route= r model. eric > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Thursday, November 07, 2013 12:39 PM > To: Eric Osborne (eosborne); Alia Atlas; i2rs@ietf.org > Subject: Re: [i2rs] topology info model - what makes it a "network" > model vs. a "device" model >=20 > On 11/7/13, 12:11 AM, Eric Osborne (eosborne) wrote: > > If Not: what problems arise that would be solved by having a network > model, do we need one, and where would it come from if not i2rs? >=20 > I think it is useful to have a network-wide topology model that is=20 > accessible at a device level. Meaning, topology could be distributed=20 > into the network and retrievable either as a whole network or in parts=20 > based on filters. For example, given an I2RS Agent, give me the Agent=20 > plus two routed hops. This would be very useful, for example, in the=20 > support case where we need to understand what a network looks like in=20 > order to help troubleshoot problems. >=20 > But, I could also ask this same Agent to give me the whole routed=20 > network from a given instance. This would give me the graph (edges, > nodes) of that topology. >=20 > Joe >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ---------------------------------------------------------------------- > -- > ---- _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From n.milovanov@gmail.com Thu Nov 7 13:33:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4CC11E8110 for ; Thu, 7 Nov 2013 13:33:29 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjaHpswqEuwD for ; Thu, 7 Nov 2013 13:33:28 -0800 (PST) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2DED921F9A59 for ; Thu, 7 Nov 2013 13:33:27 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id v10so436587bkz.25 for ; Thu, 07 Nov 2013 13:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XbWBua3z2SqwJMebo8t+XrZD72A790UrS20E5GxaNrw=; b=ZliPj2GpQvUXUWnCgkFSf2rmviAKOR+dHzeVJJ+Qh/6DhmW93rdQ3Ne3A+tKdDfwxi APu0mQhYZFJ66XMNJIwmQLe1xBg0X0qylOO8RiUCWCPYIL9YM8sBy+TpZnRYntQdn6Em hkcZl/MwJmeLdUA9PZuJkM0tIOyn6osUjnfnx6dvicfrO+Hh+HVizLHXQ3HAF/pIllMO VAuO1fa/HJeumng2bPUrfF61exn0b3iv5KK4exSDcOmmO5HKKZ+OTiWhRLJ9Kq57V9/i mV7wTrUiZpvXZKsGA5NsTLx3WikzNSkW1rivtR6DxDqrlYLBAU7EFXrjS+jmmG8BUqZ1 S6wg== X-Received: by 10.204.233.129 with SMTP id jy1mr8071598bkb.27.1383859996592; Thu, 07 Nov 2013 13:33:16 -0800 (PST) Received: from [10.10.12.106] ([93.155.231.113]) by mx.google.com with ESMTPSA id qg7sm3620510bkb.6.2013.11.07.13.33.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 13:33:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Nikolay Milovanov In-Reply-To: Date: Thu, 7 Nov 2013 23:33:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F7BE70F-6D4A-4FEC-9A87-3A596B48F105@gmail.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> To: Sriganesh Kini X-Mailer: Apple Mail (2.1283) Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:33:29 -0000 Hi Sri,=20 I guess instead of "complete model of entire network topology" it = should be "a model of the network topology as visible from a particular = device perspective".=20 The topology discoverer acting as an i2rs client will have to have some = rules in order to handle differences between network models received by = different devices.=20 It is interesting how the i2rs client will do the merge if some edges = part of the model received from one network node(agent) and are missing = from the model received by its neighbor? Shall does go into the entire = network model or not? I guess this is an implementation detail not = really related to the info model spec. For example in such cases there = might be a discrepancy mechanism able to handle that. It might be = configurable and able to do different things as per the exact network = use case.=20 I have a question to the group members related to How formal that model = will has to be?. For example it might contain not only nodes and edges = but also some of their key properties. It might be useful if for example = some of the edge properties to be the local/remote interface through = which the edge has been built also the local/remote L2/L3 network = address used for edge building.=20 Also is interesting how to ensure that the data coming from different = nodes in the network but related to the same node/edge will have the = same unique ID so that the network topology manager will be able to = merge it correctly.=20 Nikolay On Nov 7, 2013, at 11:11 PM, Sriganesh Kini wrote: > A critical question is whether the "merging of the models from each > device" is within the scope of I2RS. Also note that "complete model of > entire network topology" can be misleading. This may be true for small > networks within a single administrative domain, but as the scope of > the network increases (e.g. multiple administrative domains) there > will not be a single way to get the "entire network topology", but > there will be some details that will be abstracted out. >=20 > - Sri >=20 > On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov > wrote: >> Most likely the network-centric topology models coming from each of = the >> devices will have to be merged by the network topology manager in = order the >> rest of the applications to be able to benefit from a complete model = of the >> entire network topology. From andy@yumaworks.com Thu Nov 7 13:50:36 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352B311E8110 for ; Thu, 7 Nov 2013 13:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjsuhdCPaXsu for ; Thu, 7 Nov 2013 13:50:31 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C711E8127 for ; Thu, 7 Nov 2013 13:50:25 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id b4so1151192qen.34 for ; Thu, 07 Nov 2013 13:50:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+74UDc4yxsFbSysou3QHXMrf0EVCSMTFW/guAY5awdU=; b=Bthjsys1ziV00iAsOpHMxGwrwYScdJ0kb8pu/xpH9+ualx2m38RGoW8d4hHhc51bke 78z3OYRo8rRDPsBxwnbZHvkCub+YBLbUMpEr12aFCgPH2xEvNJv8v7oix5NKAgg4bNuG jn6IzamuhmjNnGnXj5JY9iHQ4Q3qaIj+cHJmrJhB9NdA48zwSfDpGb/vGAl1kmT23xy/ WU5+iXxOafXI/HWTBSkovyvYGju7xi0IaX9z0SU6Z+gnq+Mw0EFSeC39WP1gITJFz8sM 2ZFgdtuggyWxrOVpMmQRFjSZQra1O3rWureVkBxX+NsIIP437tJrJ34rjowRtygYl0KX Cxfg== X-Gm-Message-State: ALoCoQkQMYrMFym5o9rA8kecsRpe+syLUzPAxSgLuf9Js52ECAlrHuzPIEtWgppHt6gnkLKG0gf+ MIME-Version: 1.0 X-Received: by 10.49.35.15 with SMTP id d15mr16952554qej.16.1383861021582; Thu, 07 Nov 2013 13:50:21 -0800 (PST) Received: by 10.140.100.203 with HTTP; Thu, 7 Nov 2013 13:50:21 -0800 (PST) In-Reply-To: <527BBCAE.5050102@joelhalpern.com> References: <527BBCAE.5050102@joelhalpern.com> Date: Thu, 7 Nov 2013 13:50:21 -0800 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b6dcbe09c574104ea9d40aa Cc: "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Alia Atlas , Russ White , "Jan Medved \(jmedved\)" , Nikolay Milovanov Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:50:36 -0000 --047d7b6dcbe09c574104ea9d40aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Joel, I agree with you that the network-wide view of topology that a controller might provide is out of scope. I do not see the value of even defining a standar= d info model for this network-wide view unless/until there is a standard northbound protocol to expose this data to applications. IMO topology is a big enough problem to have its own WG, especially if there needs to be a framework and protocol-specific models developed, plus standard mechanisms to correlate NE data into a canonical view of network topology. Andy On Thu, Nov 7, 2013 at 8:15 AM, Joel M. Halpern wrote= : > If I thought we could get away with not having protocol specific > information models, then trying to design a protocol independent topology > model for use with the network elements would seem applicable. > > But, as it stands, even if we had such a model, we would still need > protocol specific models, which would be having to manipulate many aspect= s > related to the common model. > > The argument that an abstracted model is useful when you are northbound > from the topology manager is very understandable and attractive. But > northbound from the topology manager is not our working space. > > Yours, > Joel > > On 11/7/13 3:51 AM, Jan Medved (jmedved) wrote: > >> >> >> From: Alia Atlas > >> Date: Wednesday, November 6, 2013 11:59 PM >> To: Nikolay Milovanov > n.milovanov@gmail.com>> >> Cc: Russ White >, "i2rs@ietf.org >> " >, "Eric >> Osborne (eosborne)" > >> Subject: Re: [i2rs] topology info model - what makes it a "network" >> model vs. a "device" model >> >> Hi, >> >> Yes - so what I'm really trying to do is elicit what the points of >> concern and different options are as far as modeling the topology >> information from a device. draft-medved-i2rs-topology-im has >> changed only minimally since last IETF - and in ways that don't seem >> to address any of the disagreements or concerns. >> >> We need to be sure to bite off the right-sized first chunk to do. >> >> If we have a device-centric model showing interfaces and so on, then >> there's not a good way to express the learned IGP topology. Would >> we then need a different IM - perhaps as part of an IGP-specific IM >> - to communicate the topology learned via the IGP? Would that be >> preferable? >> >> >> If we decide that topology learned via the IGP is indeed in scope WG to >> go, then the IGP-specific IMs are already defined >> in draft-medved-i2rs-topology-im. >> >> >> Given that the active IGP topology can be learned via BGP-LS, are we >> better off focusing on an interface-focused IM (whether that is a >> device model or an interfaces model or...)? >> >> >> The same topology I'm model would apply to BGP-LS and to IGPs. >> >> >> I'd really like to make significant progress in understanding the >> perspectives and thoughts of the WG on this. I understand that all >> these things may be useful but in our usual ocean-boiling-avoidance >> method, we've got to prioritize. >> >> >> IMHO, it is actually easier to define the base network topology IM than >> the device IMs from which a network topology can be 'stitched together'. >> The base network topology IM is simple: it's a directed graph with >> nodes, links and termination points. The base network topology IM can be >> easily augmented (extended) to cover L1-L3 networks, VPNs, etc. On the >> other hand, there is a variety of information (in devices and in other >> systems) that can (must be) be used to 'stitch' together a network >> topology: dynamically learned neighbor info (LLDP for example for L2, >> IGP neighbor info for L3, for example), statically configured neighbor >> info in device configurations, IGP LSDB, IGP configurations, inventory >> systems, interface data (interface type, speed, =85), LAGs, etc. Trying = to >> model all of this can turn out to be quite a chunk to bite off. >> >> >> I'm also not comfortable on having only one IM for basing all our >> requirements off of. >> >> >> I don't understand what you mean - can you please explain? >> >> >> So - more thoughts? >> >> >> The charter does not say anything about 'device-centric' or >> 'network-centric' IMs - it talks merely about 'topology information'. >> Can you define what 'device-centric' and 'network-centric' is? Would >> 'device-centric' be information that a client could get from a single >> routing system device, without a third party data aggregator, such as >> the Topology Manager or a Controller? Or would 'device-centric' be >> strictly information about the device, in which case an LSDB (or even >> neighbor info) would not be in scope? How would you define >> 'network-centric'? >> >> Could we also consider IM criteria such as useful/useless, >> easy-to-model/difficult-to-model, easy-to-use/difficult-to-use, >> easy-to-extract/difficult-to-extract? IOW, what kind of topology IM >> would be most useful to apps, relatively easy to model (and where an >> initial model could be expanded for different use cases), and relatively >> easy to obtain from the network? >> >> >> Alia >> >> >> Thanks, >> Jan >> >> >> On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov >> > wrote: >> >> Hi, >> >> I might be completely wrong but from a brief overview of >> the Topology API Use Cases my guess would be. >> >> The topology data model will be an undirected graph with nodes, >> edges with certain properties representing part of the network >> topology and the device centric model will be something >> hierarchical with a root object the network device its >> interfaces, their IPs, the protocols working on them and the >> neighbor devices learned dynamically by those protocols. >> >> Most likely the network-centric topology models coming from each >> of the devices will have to be merged by the network topology >> manager in order the rest of the applications to be able to >> benefit from a complete model of the entire network topology. >> >> In my opinion either of the models will be extremely useful for >> all kinds of OSS applications related to network service >> provisioning and fulfillment. Currently is quite difficult to >> build any of them by means such as CLI parsing and SNMP. Netconf >> is not bad but still an API will be much better :) >> >> BR, >> Nikolay Milovanov >> >> Network Engineer >> n.milovanov@gmail.com >> >> >> >> >> On Thu, Nov 7, 2013 at 8:16 AM, Russ White > > wrote: >> >> >> > Are there really differences of opinion about what the >> difference is >> between >> > a network model and a device model? A network is a >> plurality of devices, >> > and a network model is something which deals with a system >> resulting from >> > the use of more than one device. (ok, yes, a network of >> one node is a >> corner >> > case blah blah handwave...). I don't see how there could >> be any real >> debate >> > around this, but if there is I'm quite interested in what >> it might be. >> >> Agreed--both seem necessary, but different beasts (see the >> discussion on >> sdnrg right now --same problem, different names). >> >> > It feels like the real question is whether i2rs should hav= e >> network models >> in >> > scope. >> >> Right... >> >> I think network models at this point in the game might be >> useful to make >> certain we are getting all the information we need from the >> models at the >> protocol and device levels... In other words, there are >> things the network >> model cares about that a device model isn't going to care >> about. In other >> words, if we only look at protocol level use cases, we might >> miss some >> pieces of information we'll eventually need for building >> network topologies, >> or that sort of thing. >> >> > If Yes: ok, cool. But between link properties (that is, a= t >> least some >> kind of >> > topology view), counter dumps, debugs, routing, MPLS, and >> LAG member >> > rebalancing, show me what's *not* in scope. >> >> This is the problem on the other end, however... It's >> better, IMHO, to start >> with a single small set of problems and solve them in a way >> that >> specifically allows extensions to solve other problems. If >> we try to model >> every possible problem, to make certain we have accounted >> for every possible >> situation, well, we'll never actually do anything but >> describe problems. I'm >> pretty familiar with the "describing problems all the time" >> process, as I >> have kids... :-) (Oh, I'm glad they don't read this list, >> because they'd >> really be mad at me about now!). >> >> So I think it's valuable to describe these network models, >> and think about >> them. OTOH, I'm really concerned we're going to get bogged >> down in them, and >> take up a lot of time reading and accounting for them, which >> could well >> divert us (even more!) from picking a small set of >> well-defined problems and >> solving them in an extensible way. I think that's the point >> Joel was trying >> to make at the mic today, btw... >> >> :-) >> >> Russ >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> >> >> -- >> BR, >> >> Nikolay Milovanov >> Network Engineer >> Email: n.milovanov@gmail.com >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b6dcbe09c574104ea9d40aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Joel,

I agree with you that the netw= ork-wide view of topology that a controller might
provide is out = of scope. =A0I do not see the value of even defining a standard
i= nfo model for this network-wide view unless/until there is a standard north= bound
protocol to expose this data to applications.

IMO topology is a big enough problem to have its own WG, especially if
there needs to be a framework and protocol-specific models developed= ,
plus standard mechanisms to correlate NE data into a canonical view
of network topology.


Andy




On Thu, Nov 7, 2013 at 8:15 AM, Joel M. Halpern = <jmh@joelhalpern.com> wrote:
If I thought we could get away with not having protocol specific informatio= n models, then trying to design a protocol independent topology model for u= se with the network elements would seem applicable.

But, as it stands, even if we had such a model, we would still need protoco= l specific models, which would be having to manipulate many aspects related= to the common model.

The argument that an abstracted model is useful when you are northbound fro= m the topology manager is very understandable and attractive. =A0But northb= ound from the topology manager is not our working space.

Yours,
Joel

On 11/7/13 3:51 AM, Jan Medved (jmedved) wrote:


From: Alia Atlas <akatlas@gmail.com <mailto:akatlas@gmail.com>>
Date: Wednesday, November 6, 2013 11:59 PM
To: Nikolay Milovanov <n.milovanov@gmail.com <mailto:n.milovanov@gmail.com>> Cc: Russ White <russw@= riw.us <mailto:rus= sw@riw.us>>, "i2rs@ietf.org
<mailto:i2rs@ietf.org= >" <i2rs@= ietf.org <mailto:= i2rs@ietf.org>>, "Eric
Osborne (eosborne)" <eosborne@cisco.com <mailto:eosborne@cisco.com>>
Subject: Re: [i2rs] topology info model - what makes it a "network&quo= t;
model vs. a "device" model

=A0 =A0 Hi,

=A0 =A0 Yes - so what I'm really trying to do is elicit what the points= of
=A0 =A0 concern and different options are as far as modeling the topology =A0 =A0 information from a device. =A0 draft-medved-i2rs-topology-im has =A0 =A0 changed only minimally since last IETF - and in ways that don't= seem
=A0 =A0 to address any of the disagreements or concerns.

=A0 =A0 We need to be sure to bite off the right-sized first chunk to do.
=A0 =A0 If we have a device-centric model showing interfaces and so on, the= n
=A0 =A0 there's not a good way to express the learned IGP topology. =A0= Would
=A0 =A0 we then need a different IM - perhaps as part of an IGP-specific IM=
=A0 =A0 - to communicate the topology learned via the IGP? =A0Would that be=
=A0 =A0 preferable?


If we decide that topology learned via the IGP is indeed in scope WG to
go, then the IGP-specific IMs are already defined
in draft-medved-i2rs-topology-im.


=A0 =A0 Given that the active IGP topology can be learned via BGP-LS, are w= e
=A0 =A0 better off focusing on an interface-focused IM (whether that is a =A0 =A0 device model or an interfaces model or...)?


The same topology I'm model would apply to BGP-LS and to IGPs.


=A0 =A0 I'd really like to make significant progress in understanding t= he
=A0 =A0 perspectives and thoughts of the WG on this. =A0 I understand that = all
=A0 =A0 these things may be useful but in our usual ocean-boiling-avoidance=
=A0 =A0 method, we've got to prioritize.


IMHO, it is actually easier to define the base network topology IM than
the device IMs from which a network topology can be 'stitched together&= #39;.
The base network topology IM is simple: it's a directed graph with
nodes, links and termination points. The base network topology IM can be easily augmented (extended) to cover L1-L3 networks, VPNs, etc. On the
other hand, there is a variety of information (in devices and in other
systems) that can (must be) be used to 'stitch' together a network<= br> topology: dynamically learned neighbor info (LLDP for example for L2,
IGP neighbor info for L3, for example), statically configured neighbor
info in device configurations, IGP LSDB, IGP configurations, inventory
systems, interface data (interface type, speed, =85), LAGs, etc. Trying to<= br> model all of this can turn out to be quite a chunk to bite off.


=A0 =A0 I'm also not comfortable on having only one IM for basing all o= ur
=A0 =A0 requirements off of.


I don't understand what you mean - can you please explain?


=A0 =A0 So - more thoughts?


The charter does not say anything about 'device-centric' or
'network-centric' IMs - it talks merely about 'topology informa= tion'.
Can you define what 'device-centric' and 'network-centric' = is? =A0Would
'device-centric' be information that a client could get from a sing= le
routing system device, without a third party data aggregator, such as
the Topology Manager or a Controller? Or would 'device-centric' be<= br> strictly information about the device, in which case an LSDB (or even
neighbor info) would not be in scope? How would you define
'network-centric'?

Could we also consider IM criteria such as useful/useless,
easy-to-model/difficult-to-model, easy-to-use/difficult-to-use,
easy-to-extract/difficult-to-extract? IOW, what kind of topology IM<= br> would be most useful to apps, relatively easy to model (and where an
initial model could be expanded for different use cases), and relatively easy to obtain from the network?


=A0 =A0 Alia


Thanks,
Jan


=A0 =A0 On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov
=A0 =A0 <n.mi= lovanov@gmail.com <mailto:n.milovanov@gmail.com>> wrote:

=A0 =A0 =A0 =A0 Hi,

=A0 =A0 =A0 =A0 I might be completely wrong but from a brief overview of =A0 =A0 =A0 =A0 the Topology API Use Cases my guess would be.

=A0 =A0 =A0 =A0 The topology data model will be an undirected graph with no= des,
=A0 =A0 =A0 =A0 edges with certain properties representing part of the netw= ork
=A0 =A0 =A0 =A0 topology =A0and the device centric model will be something<= br> =A0 =A0 =A0 =A0 hierarchical with a root object the network device its
=A0 =A0 =A0 =A0 interfaces, their IPs, the protocols working on them and th= e
=A0 =A0 =A0 =A0 neighbor devices learned dynamically by those protocols.
=A0 =A0 =A0 =A0 Most likely the network-centric topology models coming from= each
=A0 =A0 =A0 =A0 of the devices will have to be merged by the network topolo= gy
=A0 =A0 =A0 =A0 manager in order the rest of the applications to be able to=
=A0 =A0 =A0 =A0 benefit from a complete model of the entire network topolog= y.

=A0 =A0 =A0 =A0 In my opinion either of the models will be extremely useful= for
=A0 =A0 =A0 =A0 all kinds of OSS applications related to network service =A0 =A0 =A0 =A0 provisioning and fulfillment. Currently is quite difficult = to
=A0 =A0 =A0 =A0 build any of them by means such as CLI parsing and SNMP. Ne= tconf
=A0 =A0 =A0 =A0 is not bad but still an API will be much better :)

=A0 =A0 =A0 =A0 BR,
=A0 =A0 =A0 =A0 Nikolay Milovanov

=A0 =A0 =A0 =A0 Network Engineer
=A0 =A0 =A0 =A0 = n.milovanov@gmail.com <mailto:n.milovanov@gmail.com>




=A0 =A0 =A0 =A0 On Thu, Nov 7, 2013 at 8:16 AM, Russ White <russw@riw.us
=A0 =A0 =A0 =A0 <mailto:russw@riw.us>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 > Are there really differences of opinion about = what the difference is
=A0 =A0 =A0 =A0 =A0 =A0 between
=A0 =A0 =A0 =A0 =A0 =A0 > a network model and a device model? =A0A netwo= rk is a plurality of devices,
=A0 =A0 =A0 =A0 =A0 =A0 > and a network model is something which deals w= ith a system resulting from
=A0 =A0 =A0 =A0 =A0 =A0 > the use of more than one device. =A0(ok, yes, = a network of one node is a
=A0 =A0 =A0 =A0 =A0 =A0 corner
=A0 =A0 =A0 =A0 =A0 =A0 > case blah blah handwave...). =A0I don't se= e how there could be any real
=A0 =A0 =A0 =A0 =A0 =A0 debate
=A0 =A0 =A0 =A0 =A0 =A0 > around this, but if there is I'm quite int= erested in what it might be.

=A0 =A0 =A0 =A0 =A0 =A0 Agreed--both seem necessary, but different beasts (= see the
=A0 =A0 =A0 =A0 =A0 =A0 discussion on
=A0 =A0 =A0 =A0 =A0 =A0 sdnrg right now --same problem, different names).
=A0 =A0 =A0 =A0 =A0 =A0 > It feels like the real question is whether i2r= s should have network models
=A0 =A0 =A0 =A0 =A0 =A0 in
=A0 =A0 =A0 =A0 =A0 =A0 > scope.

=A0 =A0 =A0 =A0 =A0 =A0 Right...

=A0 =A0 =A0 =A0 =A0 =A0 I think network models at this point in the game mi= ght be
=A0 =A0 =A0 =A0 =A0 =A0 useful to make
=A0 =A0 =A0 =A0 =A0 =A0 certain we are getting all the information we need = from the
=A0 =A0 =A0 =A0 =A0 =A0 models at the
=A0 =A0 =A0 =A0 =A0 =A0 protocol and device levels... In other words, there= are
=A0 =A0 =A0 =A0 =A0 =A0 things the network
=A0 =A0 =A0 =A0 =A0 =A0 model cares about that a device model isn't goi= ng to care
=A0 =A0 =A0 =A0 =A0 =A0 about. In other
=A0 =A0 =A0 =A0 =A0 =A0 words, if we only look at protocol level use cases,= we might
=A0 =A0 =A0 =A0 =A0 =A0 miss some
=A0 =A0 =A0 =A0 =A0 =A0 pieces of information we'll eventually need for= building
=A0 =A0 =A0 =A0 =A0 =A0 network topologies,
=A0 =A0 =A0 =A0 =A0 =A0 or that sort of thing.

=A0 =A0 =A0 =A0 =A0 =A0 > If Yes: ok, cool. =A0But between link properti= es (that is, at least some
=A0 =A0 =A0 =A0 =A0 =A0 kind of
=A0 =A0 =A0 =A0 =A0 =A0 > topology view), counter dumps, debugs, routing= , MPLS, and LAG member
=A0 =A0 =A0 =A0 =A0 =A0 > rebalancing, show me what's *not* in scope= .

=A0 =A0 =A0 =A0 =A0 =A0 This is the problem on the other end, however... It= 's
=A0 =A0 =A0 =A0 =A0 =A0 better, IMHO, to start
=A0 =A0 =A0 =A0 =A0 =A0 with a single small set of problems and solve them = in a way that
=A0 =A0 =A0 =A0 =A0 =A0 specifically allows extensions to solve other probl= ems. If
=A0 =A0 =A0 =A0 =A0 =A0 we try to model
=A0 =A0 =A0 =A0 =A0 =A0 every possible problem, to make certain we have acc= ounted
=A0 =A0 =A0 =A0 =A0 =A0 for every possible
=A0 =A0 =A0 =A0 =A0 =A0 situation, well, we'll never actually do anythi= ng but
=A0 =A0 =A0 =A0 =A0 =A0 describe problems. I'm
=A0 =A0 =A0 =A0 =A0 =A0 pretty familiar with the "describing problems = all the time"
=A0 =A0 =A0 =A0 =A0 =A0 process, as I
=A0 =A0 =A0 =A0 =A0 =A0 have kids... :-) (Oh, I'm glad they don't r= ead this list,
=A0 =A0 =A0 =A0 =A0 =A0 because they'd
=A0 =A0 =A0 =A0 =A0 =A0 really be mad at me about now!).

=A0 =A0 =A0 =A0 =A0 =A0 So I think it's valuable to describe these netw= ork models,
=A0 =A0 =A0 =A0 =A0 =A0 and think about
=A0 =A0 =A0 =A0 =A0 =A0 them. OTOH, I'm really concerned we're goin= g to get bogged
=A0 =A0 =A0 =A0 =A0 =A0 down in them, and
=A0 =A0 =A0 =A0 =A0 =A0 take up a lot of time reading and accounting for th= em, which
=A0 =A0 =A0 =A0 =A0 =A0 could well
=A0 =A0 =A0 =A0 =A0 =A0 divert us (even more!) from picking a small set of<= br> =A0 =A0 =A0 =A0 =A0 =A0 well-defined problems and
=A0 =A0 =A0 =A0 =A0 =A0 solving them in an extensible way. I think that'= ;s the point
=A0 =A0 =A0 =A0 =A0 =A0 Joel was trying
=A0 =A0 =A0 =A0 =A0 =A0 to make at the mic today, btw...

=A0 =A0 =A0 =A0 =A0 =A0 :-)

=A0 =A0 =A0 =A0 =A0 =A0 Russ



=A0 =A0 =A0 =A0 =A0 =A0 ____________________________________________= ___
=A0 =A0 =A0 =A0 =A0 =A0 i2rs mailing list
=A0 =A0 =A0 =A0 =A0 =A0 = i2rs@ietf.org <mailto:i2rs@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/i2rs=




=A0 =A0 =A0 =A0 --
=A0 =A0 =A0 =A0 BR,

=A0 =A0 =A0 =A0 Nikolay Milovanov
=A0 =A0 =A0 =A0 Network Engineer
=A0 =A0 =A0 =A0 Email: n.milovanov@gmail.com <mailto:n.milovanov@gmail.com>




_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b6dcbe09c574104ea9d40aa-- From sriganeshkini@gmail.com Thu Nov 7 13:59:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AE711E829D for ; Thu, 7 Nov 2013 13:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jBHpR-x2y75 for ; Thu, 7 Nov 2013 13:59:16 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 702FE11E8110 for ; Thu, 7 Nov 2013 13:56:54 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb1so1242843pad.3 for ; Thu, 07 Nov 2013 13:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=reg0warr74tLcCD4t5ySZgZFyouJRsUFBPBL3+MLDHc=; b=En6h8EEPqi6vOUxf748nEw+xw41EPZyhQc2NJgdIUjTXfHRB7sYI+VcPrQBIixAHrt eKB5xifTa90AE9+M7Dba5minNGVoXZROlFWUi2AJqjym3mWmqf8UC/IZ7lrUQceyQBKE WIjD0VTBv+o5MRmp7u5pQdQBSTnSYBAhy1vB7Fgh5Iw+5Qd2kFpoKWautFJH/bCflVTP oOVKjIX5jxJ0FFGazt9DEdw1JIKSC+QoIN34vseUgsSkK8K6vpylFyEEp1MdPgbJjjLz Xz74/5113jEgg7CHt7eNrOdN+CdHvWW6YNsEHBBp9NY4x4hhNu5VSEBR1+au9xD893wN zJjQ== X-Received: by 10.68.253.67 with SMTP id zy3mr11310352pbc.137.1383861414054; Thu, 07 Nov 2013 13:56:54 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Thu, 7 Nov 2013 13:56:23 -0800 (PST) In-Reply-To: <0F7BE70F-6D4A-4FEC-9A87-3A596B48F105@gmail.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> <0F7BE70F-6D4A-4FEC-9A87-3A596B48F105@gmail.com> From: Sriganesh Kini Date: Thu, 7 Nov 2013 13:56:23 -0800 X-Google-Sender-Auth: ztihhrmq21_gdzdFGjxxBik-jMQ Message-ID: To: Nikolay Milovanov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "Eric Osborne \(eosborne\)" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:59:16 -0000 Hi Nikolay, On Thu, Nov 7, 2013 at 1:33 PM, Nikolay Milovanov w= rote: > Hi Sri, > > I guess instead of "complete model of entire network topology" it should= be "a model of the network topology as visible from a particular device pe= rspective". This is still a device-centric topology view. Even though it may be of the whole network and not just its immediate neighbors, it is still a device-centric view. Unless the device itself has a strong-consistency model of the entire network, in which case I would like to know what that is. > The topology discoverer acting as an i2rs client will have to have some = rules in order to handle differences between network models received by dif= ferent devices. My question to the group is whether those rules are in the I2RS charter. Will we be designing those procedures and mechanisms in I2RS WG (this may be replicating a link-state IGP's db update procedures). > > It is interesting how the i2rs client will do the merge if some edges par= t of the model received from one network node(agent) and are missing from t= he model received by its neighbor? Shall does go into the entire network mo= del or not? I guess this is an implementation detail not really related to = the info model spec. For example in such cases there might be a discrepancy= mechanism able to handle that. It might be configurable and able to do dif= ferent things as per the exact network use case. > I don't think this is an implementation detail. A network-centric topology model must be recursively stackable. It must be standardized as to how the "discrepancies" are handled. > I have a question to the group members related to How formal that model = will has to be?. For example it might contain not only nodes and edges but = also some of their key properties. It might be useful if for example some o= f the edge properties to be the local/remote interface through which the ed= ge has been built also the local/remote L2/L3 network address used for edge= building. > Also is interesting how to ensure that the data coming from different nod= es in the network but related to the same node/edge will have the same uniq= ue ID so that the network topology manager will be able to merge it correct= ly. Seems like we are getting into a link-state advertisement discussion here := -) > > Nikolay > - Sri > > On Nov 7, 2013, at 11:11 PM, Sriganesh Kini wrote: > >> A critical question is whether the "merging of the models from each >> device" is within the scope of I2RS. Also note that "complete model of >> entire network topology" can be misleading. This may be true for small >> networks within a single administrative domain, but as the scope of >> the network increases (e.g. multiple administrative domains) there >> will not be a single way to get the "entire network topology", but >> there will be some details that will be abstracted out. >> >> - Sri >> >> On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov >> wrote: >>> Most likely the network-centric topology models coming from each of the >>> devices will have to be merged by the network topology manager in order= the >>> rest of the applications to be able to benefit from a complete model of= the >>> entire network topology. > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From swhyte@google.com Thu Nov 7 14:34:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2120321E808F for ; Thu, 7 Nov 2013 14:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJY37s7xlT0N for ; Thu, 7 Nov 2013 14:34:40 -0800 (PST) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9701111E8127 for ; Thu, 7 Nov 2013 14:34:38 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id if17so849566vcb.41 for ; Thu, 07 Nov 2013 14:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2BIs2PyPjZRhAqcBT9d8MyWzKYOPE0+8TeTzAUs1BOA=; b=Zbkbq5kenZuToeKl7r+t9Qp7B3iwKiBvHPauErj2Cha0iGuSA2GJXDzTdLg7Q+mAU8 0Eogj7XRHTciJSl3vaYiWO4tVGwkq/yCx/u23UVul/kQ4I1ZiRG/xW74opvTMhcgKuQr 9fcBTt3I/IcqR/gXI64ZlBWrUNZHgQlz+JZGoaKs96Y0z1n/h0CVvAIq4y6wqVFvFr8X Bf2HCuxB0OBTEbfvcgvc+TTSgAE6A4TJcgoMOsv2p20GGhlZuVaIgh4dnjSMKXu3lXXw w3DKI98wZzBBnLiJYfdKnFOTHh5Z5SBwp5fEYrDm7RmU6XxcqmzvN99EUZRJFAqnzdBB cXDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2BIs2PyPjZRhAqcBT9d8MyWzKYOPE0+8TeTzAUs1BOA=; b=cTlcsHXIsYCdmcmBQ5p/JYyMhFUu+IBG+CPDLC9nrdiVFqkivDIqEau0ZRuqTn9Hb3 fgeyxZ03aS+la7u86RPOgaQSP/s5HcnM1frkRAI/oCu6invLO5deuyJu3pkgR25TWSbE epFdtqyylfPqcCtlzhcgFO/6oiokwfS4A+ewonT1x+84RMzGStrpeHUwUjqTrzMWK74Z sFz51/YIDkBnk8/wEJLIL7d4jTSX9GJUj5dSSoVhRSaCUDD9H7cGX/Do9Beuy0rn028O bGaYH8YSG1OOPy3vRgAhhT1fh+w65Cyr0otqRnMxtRNWS6cyHyFuGmoCgV9cyVo0RNzR LRsA== X-Gm-Message-State: ALoCoQl6a2QDSUVsnL/5j4h605/5BFp518SgwDtHKkD74kAlP32iO/PZCoGsY5HGaJ/1jarfg2hUZ6TZ1KWb9MHjvyi0uqFkhtBVrrWHMzkpi5dUqyPe/QQmVj5yxW+R+qKjVwY+Ono++Ed8WyCu0b0uXDdbkVmG0aFF/owBBeF2dfNuYwTW9Q9Jtnd/L/YbiJv8FG72upis MIME-Version: 1.0 X-Received: by 10.58.107.204 with SMTP id he12mr8614323veb.26.1383863667858; Thu, 07 Nov 2013 14:34:27 -0800 (PST) Received: by 10.52.106.230 with HTTP; Thu, 7 Nov 2013 14:34:27 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BFDEBD@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BFDEBD@dfweml509-mbx.china.huawei.com> Date: Thu, 7 Nov 2013 14:34:27 -0800 Message-ID: From: Scott Whyte To: Linda Dunbar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "i2rs@ietf.org" , "Jixiaofeng \(Steven\)" , Yangang Subject: Re: [i2rs] Filtering to draft-swhyte-i2rs-data-collection-system X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:34:41 -0000 On Wed, Nov 6, 2013 at 5:11 PM, Linda Dunbar wrot= e: > Scott, > > > > In addition RIB, there are much more data on router. > =E2=80=9Cdraft-jxf-i2rs-im-architecture-01=E2=80=9D has identified many l= ayers of > information on routers, as shown below. Do you need to get data on every > layer? Based on feedback from the meeting, I'm going to try and focus more on the RIB use case examples, and provide some more details in the draft specific to that. The rest remains interesting but we need a solid starting point. -Scott > > > > > > P-------------------------------------------------------------------- > > | Network Service Plane > > | L--------------------------------------------------------------- > > | | Network Service Layer > > | L--------------------------------------------------------------- > > | | Network Protocol Layer > > | L--------------------------------------------------------------- > > | | Network Resource Layer > > | L--------------------------------------------------------------- > > | | Network Policy Layer > > | L--------------------------------------------------------------- > > | | Network Container Layer > > | +--------------------------------------------------------------- > > P ------------------------------------------------------------------- > > | Infrastructure Plane > > | L--------------------------------------------------------------- > > | | System Management Layer > > | L--------------------------------------------------------------- > > | | System Inventory Objects Layer (Software and Hardware) > > | +--------------------------------------------------------------- > > | ------------------------------------------------------------------- > > > > > > Thanks, Linda --=20 There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman From swhyte@google.com Thu Nov 7 14:45:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDA621F9DBD for ; Thu, 7 Nov 2013 14:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXx1p+6orIOw for ; Thu, 7 Nov 2013 14:45:13 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3A21F9A7D for ; Thu, 7 Nov 2013 14:45:12 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id hz11so855740vcb.24 for ; Thu, 07 Nov 2013 14:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KwYcZKBW19qQf/f1PLYhpeh0F5tiOqMZylobHI5r8dI=; b=djtI7XWq4gauqPUeJ2n5BbGS/sXiVNdDFd7a16sv2dND43bdWHVIfan2ADeZkOt87X BJ8vUnGRYTlTvC0s7a7sZ7zOTtXYrA3QWBp6REo+DP2KA7abP86m5BHMPJqB2BA05gvN Ifr++XtDVQxTkPK+e7RYRZmX9fMmthw/PtEomshNEdDklgyv5zHWBdXd1bI/sWT4YZtq p1okC3HBBaTLZuZcGXAXWfmj/rX4oXu8GQyYthVBmInhRl8k2xItFiGbN+Iqd3e5LAoV 5KZnxo5pNMetUJlvgk7CO+xOHfL0rjggGi8HwLkjFOT6A0ea3rtFPg8nMi8exhe5uyEt 0H+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KwYcZKBW19qQf/f1PLYhpeh0F5tiOqMZylobHI5r8dI=; b=MWxQQ1iTw9RTw5OGFo+fETJjfHC8moSGh++gJVSzeFktco7hPdfGxZD3Xu9ogIMq5K 2Fr9zyfW5JnzSiL3w9vskcwPe2iHbQ9x8tY6quLfnTKSuEWFbOzMVFgaeFHjWU5MFah/ tnYRvhzJubSinBr8g71zB9xLqiOMKOKk+xA9DEZr9XfxsdhNRBvGyyLIiV3p5+FokjtT kSZtmtAn+pYmlJK8RKrY2YM4GZyeCCGKnSxVzHQzwFCvDCkyxK+URR9+PPmqYH1ZS2Gn SUMRMqcuIlrpt1F2sFe7HUS7FLcn3cAsb5jp+Da8aGV39ACAFJU2CEHti7ElzCjOKAG1 Ye4Q== X-Gm-Message-State: ALoCoQnB7JOowgNj2bU+AW2inoRDkL9+YcIRYXXySb3KcPxcunttZBJse2AWX3osunfQgPkbjP/ecRacN91zPb3meJoPqYBk4ALz/QP3ebk8MkumX7ykzKGzHoKvkTinZzefnG/sORoUlNiTFimgW+/sAQYJ9/GOJgZORnoAzILsIIuGl+F7nkDuBTs2ZihHRQn4KdvaX5Im MIME-Version: 1.0 X-Received: by 10.58.54.69 with SMTP id h5mr8755785vep.25.1383864311733; Thu, 07 Nov 2013 14:45:11 -0800 (PST) Received: by 10.52.106.230 with HTTP; Thu, 7 Nov 2013 14:45:11 -0800 (PST) In-Reply-To: <527A9A0A.8030503@cisco.com> References: <527A9A0A.8030503@cisco.com> Date: Thu, 7 Nov 2013 14:45:11 -0800 Message-ID: From: Scott Whyte To: Joe Marcus Clarke Content-Type: text/plain; charset=UTF-8 Cc: Warren Kumari , i2rs@ietf.org, Marcus Hines Subject: Re: [i2rs] Bulk data collection use cases draft submitted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 22:45:13 -0000 On Wed, Nov 6, 2013 at 11:35 AM, Joe Marcus Clarke wrote: > On 10/21/13, 5:02 PM, Scott Whyte wrote: >> >> We've submitted a draft of what we believe to be interesting bulk data >> collection use cases for I2RS, and the concomitant functionality >> missing from existing solutions. Please read and comment. >> >> Normative and informative references are still to be added, and the >> draft is still rough around the edges. Data model discussions are >> deliberately left out, hopefully the scope is sufficient. And of >> course other interesting use cases would be welcome. >> >> Thanks for having a look. > > > Thanks for raising this, Scott. In terms of the streaming (i.e., live data > feeds), I see this as a very valuable thing for our traceability draft as > well. I feel there is a good compliment there. Early on I had thought I2RS > itself (via notifications) could make logging data available as a "stream." > > With your idea of bulk information collection and querying/filtering, we can > install a filter to collect specific log messages or specific parts of log > messages. This would be very beneficial for troubleshooting and consistency > validation. Joe, Thanks for the feedback. I think there is a good fit for this information source in traceability as well; having consumers subscribe to different streams, with different parameters, for different purposes should be very powerful. Ideally the same system could support streaming all the logs off to a pub-sub message bus system for filtering, especially if the number of consumers and overlapping data is high, which should have some nice scaling properties. -Scott > > Joe > >> >> -Scott >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Oct 21, 2013 at 11:11 AM >> Subject: New Version Notification for >> draft-swhyte-i2rs-data-collection-system-00.txt >> To: Scott Whyte , Marcus Hines , >> Warren Kumari >> >> >> >> A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt >> has been successfully submitted by Scott Whyte and posted to the >> IETF repository. >> >> Filename: draft-swhyte-i2rs-data-collection-system >> Revision: 00 >> Title: Bulk Network Data Collection System >> Creation date: 2013-10-21 >> Group: Individual Submission >> Number of pages: 10 >> URL: >> >> http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-system-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system >> Htmlized: >> http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 >> >> >> Abstract: >> Collecting large amounts of data from network infrastructure devices >> has never been very easy. Existing methods generate CPU and memory >> loads that may be unacceptable, the output varies across >> implementations and can be difficult to parse, and these methods are >> often difficult to scale. I2RS programmatic interfacing with the >> routing system may exacerbate this problem: state needs to be >> collected from nodes and fed to consumers participating in the >> control plane that may not be physically close to the nodes. This >> state includes not only control plane information, but elements of >> the data plane that have a direct impact on control plane behavior, >> like traffic engineering. >> >> This document outlines a set of use cases requiring a flexible >> framework to collect routing system data, and the features and >> functionality needed to make such a framework useful for these use >> cases. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > ---------------------------------------------------------------------------- -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman From swhyte@google.com Thu Nov 7 15:28:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94D011E81C9 for ; Thu, 7 Nov 2013 15:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ll-GhIElK2m for ; Thu, 7 Nov 2013 15:28:55 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DE22421E80C7 for ; Thu, 7 Nov 2013 15:28:53 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id oz11so939440veb.22 for ; Thu, 07 Nov 2013 15:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c3w8v7m6xSKibgQccVuJ9JBTlnpmFzWE9eE+XEonb2o=; b=U80NCQkv+bjIG+wAet+8wNA7uUmKpEWs3JXIZKE7K1EDSw+jFylR4RURlto3zNPfjz 8LBRkBoSAW9KG3Oz4x6y3L9pb17azUBSuUFqwUZSOmzwAWnUj1iDPyytCboDaCuvu6Xw RLotvZyvC5qSEAGr16RAwg8Rd3+a5THDiTpnRmI3Kp89JYmi+ZYz55wQEd9rIaAoS/Xx ElOIBZRjMVJkRn5O4r2NVMWk2N+OJKWsPokb7vCnMnv+jlogdI00Hl+1kQEPyyfdIU1g 0Ikcu3zR+m1xf0soQ+HDiFg5hUu7G+xngS6VOyUg+p/YmFYfOqHlMl/4aEf/OYGIXiy7 +O4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c3w8v7m6xSKibgQccVuJ9JBTlnpmFzWE9eE+XEonb2o=; b=FQowYttF47iM5eMq3LXMcINJ483v3obqaMEVXA/2wt+GAopgDi+/4lm80fiuqWowtT EsDX6MMUZUopshiijji+lF/TfO304RtMKvSeAdT2IRXzof+kyvX8gqE9x7nWTt5yhOaE BkmL4cW+VEEpO0ZP1fum5ebWBqM/RTk1EG92yh7pPmLvQLE/oE8dd6uHxlS03/8R937s g4J5TRlhvXXGhO1hbNRUaFmLYf+QU+TZgBRbUHKZuSJ6bCMMORUlVZdMniHDhLPzJ1t/ TZXaZMmMuLGdB1XmR29qJ1qwCY+KEEad8VGCEr86eMiwmnmOAEf2AOPNfu/DXcO5aGq9 F6+w== X-Gm-Message-State: ALoCoQkIGlX4LZDIBEjJETy+9nOwaaKWkIlR/ccu+7kDeM3LrmzzFIrmq5zQ/c0kW53xmEGQ5MJmMo4pMUESGuTI979Gso4MngWMlQPUw1nvMAuRJr/qtm4kIIcw5bqw+BcBWsA+I9ZckjyHTijLlmwsPxDONQ/2jnB3DkZcWJsJ2vUPh0qBADeORHSMuCZKyNaSkbIAEJXZ MIME-Version: 1.0 X-Received: by 10.58.54.69 with SMTP id h5mr8915714vep.25.1383866917742; Thu, 07 Nov 2013 15:28:37 -0800 (PST) Received: by 10.52.106.230 with HTTP; Thu, 7 Nov 2013 15:28:37 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Nov 2013 15:28:37 -0800 Message-ID: From: Scott Whyte To: Robert Raszuk Content-Type: text/plain; charset=UTF-8 Cc: Warren Kumari , "i2rs@ietf.org" , Marcus Hines Subject: Re: [i2rs] Bulk data collection use cases draft submitted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:28:55 -0000 On Wed, Nov 6, 2013 at 10:34 AM, Robert Raszuk wrote: > Hi Scott, > > As mentioned yesterday it would be helpful to provide reasons why MRT > (Multi-Threaded Routing Toolkit (MRT) Routing Information Export > Format) http://tools.ietf.org/html/rfc6396 or perhaps it's minor > extension would not work for you. > > Sorry for misstating the "M", but for me everything is multiprotocol > :-) And MRT already supports OSPFv2/v3, BGP, ISIS & RIB exports. Funny enough, I know what MRT is, but didn't have any idea it moved into the IETF, so the context gave me a bit of cognitive dissonance. I hear that's common at IETF :) I read over rfc6369. I think MRT is a similar use-case to IPFIX or BMP: if a network node supports exporting MRT data, I would like to see this framework enable that via a subscription. If you feel i2rs should leverage MRT as its _standard_ format for exporting RIB snapshots, I suppose we need to wait a bit to see if there is enough interest in the more abstract ideas here first. Thanks for the feeback! -Scott > > Thx, > R. > > > On Mon, Oct 21, 2013 at 11:02 PM, Scott Whyte wrote: >> We've submitted a draft of what we believe to be interesting bulk data >> collection use cases for I2RS, and the concomitant functionality >> missing from existing solutions. Please read and comment. >> >> Normative and informative references are still to be added, and the >> draft is still rough around the edges. Data model discussions are >> deliberately left out, hopefully the scope is sufficient. And of >> course other interesting use cases would be welcome. >> >> Thanks for having a look. >> >> -Scott >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Oct 21, 2013 at 11:11 AM >> Subject: New Version Notification for >> draft-swhyte-i2rs-data-collection-system-00.txt >> To: Scott Whyte , Marcus Hines , >> Warren Kumari >> >> >> >> A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt >> has been successfully submitted by Scott Whyte and posted to the >> IETF repository. >> >> Filename: draft-swhyte-i2rs-data-collection-system >> Revision: 00 >> Title: Bulk Network Data Collection System >> Creation date: 2013-10-21 >> Group: Individual Submission >> Number of pages: 10 >> URL: >> http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-system-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system >> Htmlized: >> http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 >> >> >> Abstract: >> Collecting large amounts of data from network infrastructure devices >> has never been very easy. Existing methods generate CPU and memory >> loads that may be unacceptable, the output varies across >> implementations and can be difficult to parse, and these methods are >> often difficult to scale. I2RS programmatic interfacing with the >> routing system may exacerbate this problem: state needs to be >> collected from nodes and fed to consumers participating in the >> control plane that may not be physically close to the nodes. This >> state includes not only control plane information, but elements of >> the data plane that have a direct impact on control plane behavior, >> like traffic engineering. >> >> This document outlines a set of use cases requiring a flexible >> framework to collect routing system data, and the features and >> functionality needed to make such a framework useful for these use >> cases. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs -- There was never any more inception than there is now, Nor any more youth or age than there is now, And will never be any more perfection than there is now, Nor any more heaven or hell than there is now. -Walt Whitman From don.fedyk@hp.com Thu Nov 7 16:12:23 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABF411E8293 for ; Thu, 7 Nov 2013 16:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAOD7KMLawmC for ; Thu, 7 Nov 2013 16:12:17 -0800 (PST) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13CCC21E80BD for ; Thu, 7 Nov 2013 16:11:39 -0800 (PST) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id 799A428006; Fri, 8 Nov 2013 00:11:38 +0000 (UTC) Received: from G6W3999.americas.hpqcorp.net (16.205.80.214) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 8 Nov 2013 00:09:28 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.40]) by G6W3999.americas.hpqcorp.net ([16.205.80.214]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 00:09:28 +0000 From: "Fedyk, Don" To: "Eric Osborne (eosborne)" , "Joe Clarke (jclarke)" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO22BVhJT+UYFtukuy272KjDX3LJoZOOyAgAEDK4CAAANvAIAANWeg Date: Fri, 8 Nov 2013 00:09:27 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:12:23 -0000 Hi Eric Actually I don't think the 2 are equivalent. My argument is TE as an examp= le is only advertised as a summary (I'm sure there are other examples). So = you can get more detail fetching the node by node information. (I'd agree w= ith you if your argument is just limit the information to what is in the = LSDB (or other routing DB) but I think that would be limiting.)=20 Cheers, Don=20 -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: Thursday, November 07, 2013 3:52 PM To: Joe Clarke (jclarke); Alia Atlas; i2rs@ietf.org Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model If you want to get the link state for an entire network there are two ways = to do it: 1) the i2rs client fetches each node's link state info from that node, and = plugs them together to make a network, 2) the i2rs client fetches the entire LSDB from one node. =20 IMO either one is OK, and #2 makes the most sense. In any case it's a read= -only thing so it doesn't really matter how it gets done. Where it gets hairy is when you want to write to the network. The question= that kicked off this thread was along those lines, if I recall. If you wa= nt to get a mutex on the network as a whole you *need* a way to lock all de= vices. Perhaps this is best done in the client - acquire a lock on the con= fig for each node in the network, make your changes, then unlock. If there= were a higher level way to do this with some sort of network API that's wh= at it would have to do under the covers anyways. And if you have locking w= rite access to the client then you don't need a network model, just a route= r model. eric > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Thursday, November 07, 2013 12:39 PM > To: Eric Osborne (eosborne); Alia Atlas; i2rs@ietf.org > Subject: Re: [i2rs] topology info model - what makes it a "network" > model vs. a "device" model >=20 > On 11/7/13, 12:11 AM, Eric Osborne (eosborne) wrote: > > If Not: what problems arise that would be solved by having a network > model, do we need one, and where would it come from if not i2rs? >=20 > I think it is useful to have a network-wide topology model that is=20 > accessible at a device level. Meaning, topology could be distributed=20 > into the network and retrievable either as a whole network or in parts=20 > based on filters. For example, given an I2RS Agent, give me the Agent=20 > plus two routed hops. This would be very useful, for example, in the=20 > support case where we need to understand what a network looks like in=20 > order to help troubleshoot problems. >=20 > But, I could also ask this same Agent to give me the whole routed=20 > network from a given instance. This would give me the graph (edges, > nodes) of that topology. >=20 > Joe >=20 > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com >=20 > ---------------------------------------------------------------------- > -- > ---- _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From jclarke@cisco.com Thu Nov 7 16:29:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3CA21E811F for ; Thu, 7 Nov 2013 16:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-b3NTsbJDY8 for ; Thu, 7 Nov 2013 16:29:13 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24A9421E814B for ; Thu, 7 Nov 2013 16:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1164; q=dns/txt; s=iport; t=1383870553; x=1385080153; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vdkW3fdEsDcsfAnhmBZcS/KcNa794iOncl9c2KR++tE=; b=dXZmDdbm+XCd/DATPAcx8/NmkfySIXzzbC/exjfMDGSC2ikbh3Gt2BYw 4IomzC9pL5+ezLr06kt8G6vPIuymDOoWDOdKPdEl2gR+UenZCIKmAwg1C p1T+dVSjSr/ltFwVWtVOnNpa6DzFXfHcgfDZ3l7Ft9O+RYsMJulc6DWgl w=; X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="93618665" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 Nov 2013 00:29:11 +0000 Received: from sjc-vpn2-34.cisco.com (sjc-vpn2-34.cisco.com [10.21.112.34]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA80TAhL023078; Fri, 8 Nov 2013 00:29:10 GMT Message-ID: <527C3056.4010505@cisco.com> Date: Thu, 07 Nov 2013 19:29:10 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" , Alia Atlas , "i2rs@ietf.org" References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:29:19 -0000 On 11/7/13, 3:51 PM, Eric Osborne (eosborne) wrote: > one is OK, and #2 makes the most sense. In any case it's a read-only thing so it doesn't really matter how it gets done. > > Where it gets hairy is when you want to write to the network. The question that kicked off this thread was along those lines, if I recall. If you want to get a mutex on the network as a whole y This is where I differ from what others may want. I would like a network-wide topology accessible at each node, but I don't think I2RS needs to enforce a network-wide mutex. Meaning, let me learn about the network from a node, then me (as an application) can do what is needed to change the network. I may have to coordinate with other writers (as is stated IIRC in the architecture) to prevent conflicts from occurring. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From swhyte@google.com Thu Nov 7 16:35:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854F921E80B7 for ; Thu, 7 Nov 2013 16:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGCi-kA4W-Z5 for ; Thu, 7 Nov 2013 16:35:19 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7714F11E80E3 for ; Thu, 7 Nov 2013 16:35:19 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hv10so942688vcb.1 for ; Thu, 07 Nov 2013 16:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mu7HVQCqvMqCL2MvED6Er/EoTjEkBv3A+om2I5Zeeqg=; b=cVxDQPc2yMuhWbKtY2HmvT4l7Zx2hbfXdyvhbj9kMcVDwpgpR3Gx05eTcEi7fof59P vvLns/vP6f6OEde2OgJxRB6bWv15YdsvNB3rbbPgWPid1VK6NCw4WP2uFRWyTE1wcVbo AG7lgQON94SFGFaXcPQsytjZpzWCfvMUyZpkakGB9wcHDmUiKDjRqWh02p4Vyv9eEPLW k7CKCHR+yJdYGRUdSxRYtdZttInROj86Fkf/vyyw3cF+PKIDrYgGnZW7mhXm2j7pqi7m LUcFhgsq484vmBiUbf6n0FQm9xylNx6lptjlnwijI6pPGOG3+GFPhH0bzAEOsZ2jPY8T J3Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Mu7HVQCqvMqCL2MvED6Er/EoTjEkBv3A+om2I5Zeeqg=; b=N27Fza4R9vnoxmOYqc0TKKp7ZC1paiFC8kSRKOEQxpXg1yj1JudnQOYU7TIzPCAOwx 61S2zKvaB9H3FSmS4kDxQik83u5f6GSb4GcMjALCykGvqqpHj9DXuNhC9pN2BchQD6db EjfKymrCU9dtuM5Gbd/5Mh2g+3w3TuRA3NogIt7YafXrCPz3snPveh9u7YT1p7KPRGSJ dssjv7fLx1fEJTu29g/xzJVw8Mt311OBFFrCXmiikr25Z3anQ8+YoLrTv//xt2R1cbLU FjmvhWoIANC3ilhbP5f0fp31aQ2xIje+bbf+pRSu2GOw3dnWLueKadXNnmlB0Tcppf0h XlKg== X-Gm-Message-State: ALoCoQnST8c2xSVyb+fNSi0DjoU1daXoqBhH2ymuxbKQCvHy5ixuVs8++wu/0zyOMMnGoHkAH+JxPcA1y0uaB3pLZkZEf1G8nrzFxLyRKOLVnDBGvv3Fmx+4vrT+CwfZzNa4JArHKiQbTfzs6rI3pAXAT2fJBedao2gTLDtt5dwaF+yZ9mjujWi0FEaJL/2dSnN5bg+ABpsm MIME-Version: 1.0 X-Received: by 10.221.51.206 with SMTP id vj14mr9186563vcb.17.1383870918715; Thu, 07 Nov 2013 16:35:18 -0800 (PST) Received: by 10.52.106.230 with HTTP; Thu, 7 Nov 2013 16:35:18 -0800 (PST) In-Reply-To: <20ECF67871905846A80F77F8F4A2757210456B92@xmb-rcd-x09.cisco.com> References: <40746B2300A8FC4AB04EE722A593182B69F0907F@ONWVEXCHMB04.ciena.com> <527A7448.6010108@joelhalpern.com> <40746B2300A8FC4AB04EE722A593182B69F0947A@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F095A8@ONWVEXCHMB04.ciena.com> <40746B2300A8FC4AB04EE722A593182B69F0967F@ONWVEXCHMB04.ciena.com> <20ECF67871905846A80F77F8F4A2757210456B92@xmb-rcd-x09.cisco.com> Date: Thu, 7 Nov 2013 16:35:18 -0800 Message-ID: From: Scott Whyte To: "Eric Osborne (eosborne)" Content-Type: text/plain; charset=UTF-8 Cc: "i2rs@ietf.org" , "Shah, Himanshu" , Alia Atlas , Russ White , "Joel M. Halpern" , Sriganesh Kini Subject: Re: [i2rs] question on I2RS architecture X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:35:20 -0000 On Wed, Nov 6, 2013 at 2:45 PM, Eric Osborne (eosborne) wrote: > i2rs is basically an API into the router. I think what you're looking for is an api into the network as a whole. I have yet to grok all the i2rs docs but something like that seems very clearly Somebody Else's Problem - that is, out of scope. https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final8.pdf might be of interest as I believe it addresses some (not all) of the issues raised on this thread. And I agree with Eric this sort of thing lives on a client not an agent (per the architecture draft diagram). -Scott > > > > > eric From hadi@mojatatu.com Mon Nov 11 04:55:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E511E80FC for ; Mon, 11 Nov 2013 04:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw-FRONW9vIE for ; Mon, 11 Nov 2013 04:55:00 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id AA27A11E80F2 for ; Mon, 11 Nov 2013 04:55:00 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id db12so311985veb.39 for ; Mon, 11 Nov 2013 04:55:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mrfSlPE/EY4Sw2ZDzP8692bmY1nO72QSofo7hRG3+b0=; b=ZxTlhOHSB+041TQgPziciJ7YmpArD9BnsHKKjt5VpM8kmQ/vCqcYBCkHV+1wDcGwBN h6ROC3KrtPczotYlM1V0oc3ii47f4oa9EpGbc4dHfRR/jmDZT6A2Q8s6MFJ6UbYAsApG cqP8K2CbT1SFGzmk/VwqmHGDzDEyoYiuP7LXVyzbTTYyBYFzl+RvykdGa77I6vm9srhM RpX4FNu09mnBTjr0lSolge3psGzmxZ6Rp3RRTGM1hnb3IPEgr2VAd5xvSkkflrTDyfLP skK/OLZZMFJkj7yGkM6evGGZ1x9e4IfkkGVtJsi9/yGsFXy2+e3zoMlam2dx0mDIxFK8 TuoQ== X-Gm-Message-State: ALoCoQnFd8JXLK0oEkquMHGmOv7r/i7F5hrHzbvSOCU3zsyhioOytBunyDom7CExcAAW6MgmIZ7B X-Received: by 10.220.16.73 with SMTP id n9mr1651224vca.24.1384174500169; Mon, 11 Nov 2013 04:55:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.8.19 with HTTP; Mon, 11 Nov 2013 04:54:39 -0800 (PST) In-Reply-To: <20131111124553.20298.81335.idtracker@ietfa.amsl.com> References: <20131111124553.20298.81335.idtracker@ietfa.amsl.com> From: Jamal Hadi Salim Date: Mon, 11 Nov 2013 07:54:39 -0500 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "forces@ietf.org" Subject: [i2rs] Fwd: New Version Notification for draft-hadi-i2rs-forces-gap-analysis-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 12:55:05 -0000 First cut of viability of ForCES - done on trip back. Not exactly proof-read, but thought i'd get it out before i got busy-ed out on something else. Please provide feedback and i will re-iterate cheers, jamal ---------- Forwarded message ---------- From: Date: Mon, Nov 11, 2013 at 7:45 AM Subject: New Version Notification for draft-hadi-i2rs-forces-gap-analysis-00.txt To: Jamal Hadi Salim A new version of I-D, draft-hadi-i2rs-forces-gap-analysis-00.txt has been successfully submitted by Jamal Hadi Salim and posted to the IETF repository. Filename: draft-hadi-i2rs-forces-gap-analysis Revision: 00 Title: ForCES For I2RS Creation date: 2013-11-11 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-hadi-i2rs-forces-gap-analysis-00.txt Status: http://datatracker.ietf.org/doc/draft-hadi-i2rs-forces-gap-analysis Htmlized: http://tools.ietf.org/html/draft-hadi-i2rs-forces-gap-analysis-00 Abstract: This document provide a gap-analysis on ForCES meeting the requirements for I2RS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From edc@google.com Tue Nov 12 10:56:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4523A11E8122 for ; Tue, 12 Nov 2013 10:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3gBMuv0NU9n for ; Tue, 12 Nov 2013 10:56:58 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 79D9C21E8064 for ; Tue, 12 Nov 2013 10:56:58 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so4812111wgh.17 for ; Tue, 12 Nov 2013 10:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j0CpQx07Q/TC/BpNL1b/UjJ1+KDm/JMlPIU0schrV9A=; b=TBcpvMN+iTsV6w6x9+bxxAHm2LdsfuRfHDi3kHe87Nr93kUesC2ffitfkp37+6B8UY VcSJZm199vocUMbAYbrppw+7NW4lWj841jserMLVFK6ncV1RZw8k+LnZl9XR/04EGeKz boVF9y7xkfrqgzF25Zfcz71z7G2svCF7LZd9/W7uBMuxiQu02uti5VN3RoJ7YWO+kpaT IyJN+BWnYWQMc3MqSG81S2J0OaOKjfZs1HUhWwMZ+BZrNxMJSqsIU3S+Lxlwi28vjHW6 GOYPZw/1XNkvrcLRgjH3BTv5TvscAYdtLcpHJi6OxeVxqAxCVxIT9KS4jjXrQmAZ7fl8 Y6pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=j0CpQx07Q/TC/BpNL1b/UjJ1+KDm/JMlPIU0schrV9A=; b=UuFDRYrP5xvGIzMRABdnV7WerHZPtu3XzWPQWCAZHR1cKhXZYQuBT+7ouOn+5Ia+QH rE5oRRUZSVzinqA/EAPloQjaLLeMyNItyz2PA1vofmlsvH5I8qDdQBkEkAFwtZsLu0E7 RqwkbGH6LamYqFjSQiWvs3OnRnr4fCfGj5JdE2a2iZyQH1wrLaDB/agMbbmU9rDOwj7Q 69qkLNffsOe3kDuoTOxSwE8yHtMn23Diq4FTzDNs8/w4cVzWUVfY0pssepaaQcV+95Af hopZnyTL8RZKBYe+zzNCMsLFM1gmmLga24nZAHDOtGf/pMJ3W6Maa5mlz33BgsASrqIF QJgg== X-Gm-Message-State: ALoCoQmqjlcsY9cO3W2obHzomOp9Rmaq87awCVD4oV8TMWKQIEMW2tLwKNwRBIZ/47kPOFew6PwTstYIkGqutKpEcuyo21F++1vR6LeMd1h6fo3BzaG7ySWrL6CATL/j0U7NEGtXmu0AX1rYu48XL/z8RuQ9FvNzrBtnaV6qqog6zPamVWtsxz/d4Xn1kMyaKQxaEVhnCZPt X-Received: by 10.180.84.101 with SMTP id x5mr17294952wiy.58.1384282610369; Tue, 12 Nov 2013 10:56:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Tue, 12 Nov 2013 10:56:10 -0800 (PST) In-Reply-To: <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net> References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net> From: Edward Crabbe Date: Tue, 12 Nov 2013 10:56:10 -0800 Message-ID: To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Nikolay Milovanov , "Shah, Himanshu" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:56:59 -0000 With my chair hat off: Any 'device-centric' model must be composable into a 'network-wide' model, otherwise it's not particularly useful. So yes, +1 and agree with Shane. with my chair hat on: I believe *this specifically* is in charter. On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante wrote: > > On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov wrote: > > In the end to build a network centric info/data model out of this the > network topology manager will have to collect and transform information > gained from many network devices. > > > +1. > > I believe I may be observing a tension between the traditional IETF view of > "how do I make two devices communicate together", i.e.: what's the protocol > that allows that communication to occur robustly, vs. an operator view of > "Sure, I need protocols to make two devices talk to each other, but what's > more critical for my business is to look at the whole network, which is a > collection of devices". A Network Topology Information Model would assist > operators with having a cohesive view of the overall "network as a system", > because that's the foundation upon which _services_ are delivered ... both > within the data-path between various NE's and on top of various NE's. > > So, +1 to network-centric topology IM model. > > -shane > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From kgray@juniper.net Tue Nov 12 11:16:15 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA5B21E80C0 for ; Tue, 12 Nov 2013 11:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+8jKGgGL+H4 for ; Tue, 12 Nov 2013 11:16:05 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F221E80A7 for ; Tue, 12 Nov 2013 11:16:04 -0800 (PST) Received: from mail212-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.22; Tue, 12 Nov 2013 19:16:04 +0000 Received: from mail212-co1 (localhost [127.0.0.1]) by mail212-co1-R.bigfish.com (Postfix) with ESMTP id 2693A40298; Tue, 12 Nov 2013 19:16:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z579ehz98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail212-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(24454002)(51704005)(199002)(189002)(85306002)(47446002)(74876001)(49866001)(50986001)(47976001)(2656002)(31966008)(69226001)(87266001)(4396001)(74662001)(74502001)(81342001)(81542001)(74366001)(47736001)(74706001)(87936001)(76482001)(59766001)(77982001)(56776001)(54316002)(79102001)(63696002)(19580395003)(19580405001)(81686001)(81816001)(83322001)(56816003)(76796001)(76786001)(66066001)(65816001)(76576001)(80022001)(33646001)(74316001)(15975445006)(54356001)(77096001)(80976001)(83072001)(46102001)(51856001)(53806001)(81183002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB084; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail212-co1 (localhost.localdomain [127.0.0.1]) by mail212-co1 (MessageSwitch) id 1384283762300225_375; Tue, 12 Nov 2013 19:16:02 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.254]) by mail212-co1.bigfish.com (Postfix) with ESMTP id 4511410004C; Tue, 12 Nov 2013 19:16:02 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 12 Nov 2013 19:16:01 +0000 Received: from BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 12 Nov 2013 19:15:57 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) with Microsoft SMTP Server (TLS) id 15.0.810.5; Tue, 12 Nov 2013 19:15:55 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) with mapi id 15.00.0820.005; Tue, 12 Nov 2013 19:15:55 +0000 From: Ken Gray To: Edward Crabbe , Shane Amante Thread-Topic: [i2rs] topology info model - what makes it a "network" model vs. a "device" model Thread-Index: AQHO39kBe79RMl8nDUegYRm3vrZ58Zoh91XE Date: Tue, 12 Nov 2013 19:15:55 +0000 Message-ID: <0df46c579790441b9064658f7a207df5@BL2PR05MB082.namprd05.prod.outlook.com> References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 00286C0CA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" , Nikolay Milovanov , "Shah, Himanshu" , Alia Atlas Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:16:15 -0000 +1 (can't believe we're even discussing this at this point)=0A= ________________________________________=0A= From: i2rs-bounces@ietf.org on behalf of Edward Cra= bbe =0A= Sent: Tuesday, November 12, 2013 1:56 PM=0A= To: Shane Amante=0A= Cc: i2rs@ietf.org; Nikolay Milovanov; Shah, Himanshu; Alia Atlas=0A= Subject: Re: [i2rs] topology info model - what makes it a "network" model v= s. a "device" model=0A= =0A= With my chair hat off:=0A= =0A= Any 'device-centric' model must be composable into a 'network-wide'=0A= model, otherwise it's not particularly useful.=0A= So yes, +1 and agree with Shane.=0A= =0A= with my chair hat on:=0A= =0A= I believe *this specifically* is in charter.=0A= =0A= =0A= On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante wrote= :=0A= >=0A= > On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov wro= te:=0A= >=0A= > In the end to build a network centric info/data model out of this the=0A= > network topology manager will have to collect and transform information= =0A= > gained from many network devices.=0A= >=0A= >=0A= > +1.=0A= >=0A= > I believe I may be observing a tension between the traditional IETF view = of=0A= > "how do I make two devices communicate together", i.e.: what's the protoc= ol=0A= > that allows that communication to occur robustly, vs. an operator view of= =0A= > "Sure, I need protocols to make two devices talk to each other, but what'= s=0A= > more critical for my business is to look at the whole network, which is a= =0A= > collection of devices". A Network Topology Information Model would assis= t=0A= > operators with having a cohesive view of the overall "network as a system= ",=0A= > because that's the foundation upon which _services_ are delivered ... bot= h=0A= > within the data-path between various NE's and on top of various NE's.=0A= >=0A= > So, +1 to network-centric topology IM model.=0A= >=0A= > -shane=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > i2rs mailing list=0A= > i2rs@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/i2rs=0A= >=0A= _______________________________________________=0A= i2rs mailing list=0A= i2rs@ietf.org=0A= https://www.ietf.org/mailman/listinfo/i2rs=0A= =0A= =0A= From m.hallgren@free.fr Tue Nov 12 12:27:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690AF21F9DE9 for ; Tue, 12 Nov 2013 12:27:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WubuKoS+vAUb for ; Tue, 12 Nov 2013 12:27:27 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id BE38321F9B85 for ; Tue, 12 Nov 2013 12:27:16 -0800 (PST) Received: from [IPv6:2a01:e35:2e49:1280:d530:d997:4e7b:444b] (unknown [IPv6:2a01:e35:2e49:1280:d530:d997:4e7b:444b]) (Authenticated sender: m.hallgren) by smtp4-g21.free.fr (Postfix) with ESMTPSA id 2064E4C81A5 for ; Tue, 12 Nov 2013 21:27:08 +0100 (CET) Message-ID: <52828F16.1020402@free.fr> Date: Tue, 12 Nov 2013 21:27:02 +0100 From: Michael Hallgren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mh@xalto.net List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:27:28 -0000 Le 12/11/2013 19:56, Edward Crabbe a écrit : > With my chair hat off: > > Any 'device-centric' model must be composable into a 'network-wide' > model, otherwise it's not particularly useful. > So yes, +1 and agree with Shane. > > with my chair hat on: > > I believe *this specifically* is in charter. I need to update myself at the tail (and maybe also the head) of this thread, but it seems to me that looking at these things from a network graph perspective, populated by more or less complex nodes (maybe abstracting networks themselves) wouldn't be a null route path to explore. Thus +1. Seen from an inter-networking perspective, each node is representing some set of capabilities and connected to nodes able to participate in that capability network. Then, we'd slice view the model by abstraction level. Thoughts? Cheers, mh > > > On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante wrote: >> On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov wrote: >> >> In the end to build a network centric info/data model out of this the >> network topology manager will have to collect and transform information >> gained from many network devices. >> >> >> +1. >> >> I believe I may be observing a tension between the traditional IETF view of >> "how do I make two devices communicate together", i.e.: what's the protocol >> that allows that communication to occur robustly, vs. an operator view of >> "Sure, I need protocols to make two devices talk to each other, but what's >> more critical for my business is to look at the whole network, which is a >> collection of devices". A Network Topology Information Model would assist >> operators with having a cohesive view of the overall "network as a system", >> because that's the foundation upon which _services_ are delivered ... both >> within the data-path between various NE's and on top of various NE's. >> >> So, +1 to network-centric topology IM model. >> >> -shane >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From Krishnan.Subramanian@guavus.com Thu Nov 28 13:28:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC711AE246 for ; Thu, 28 Nov 2013 13:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHHNCTR6A4hI for ; Thu, 28 Nov 2013 13:28:19 -0800 (PST) Received: from mx1.guavus.com (mx1.guavus.com [204.232.241.167]) by ietfa.amsl.com (Postfix) with ESMTP id 200CF1AE14B for ; Thu, 28 Nov 2013 13:28:19 -0800 (PST) Received: from MX3.guavus.com ([204.232.241.166]) by mx1.guavus.com ([204.232.241.167]) with mapi id 14.01.0438.000; Thu, 28 Nov 2013 13:28:08 -0800 From: Krishnan Subramanian To: "i2rs@ietf.org" Thread-Topic: access network topology support in data model Thread-Index: AQHO7IC646+JhDda5kG9us+m2Nc6vQ== Date: Thu, 28 Nov 2013 21:28:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.3.142.255] Content-Type: multipart/alternative; boundary="_000_CEBCF56915B01krishnansubramanianguavuscom_" MIME-Version: 1.0 Subject: [i2rs] access network topology support in data model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 21:28:20 -0000 --_000_CEBCF56915B01krishnansubramanianguavuscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Will access networks like broadband networks (cable, DSL, FTTH) be supporte= d in the network topology data model? This would include everything from the CPE (ie= . cable modem ) to the a node, CMTS, headend , backhaul network. In wireless networ= ks this would include every topology component from the base station all the way up to the mobile backhaul network as well= as access point to wireless controller. Providing such a complete network topology model would be helpful in delive= ring location based services in addition to analytics that are topology aware. Regards, Krishnan Subramanian --_000_CEBCF56915B01krishnansubramanianguavuscom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi ,

Will access networks like broadband networks (cable, DSL, FTTH) be sup= ported in the 
network topology data model? This would include everything from the CP= E (ie. cable
modem ) to the a node, CMTS, headend , backhaul network. In wireless n= etworks this would include every topology component
from the base station all the way up to the mobile backhaul network as= well as access point to wireless controller.
Providing such a complete network topology model would be helpful in d= elivering location based 
services in addition to analytics that are topology aware.

Regards,
Krishnan Subramanian

--_000_CEBCF56915B01krishnansubramanianguavuscom_--