From sriganeshkini@gmail.com Mon Dec 2 17:04:42 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 931641AE00C for ; Mon, 2 Dec 2013 17:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 6gW9JHkQvhiE for ; Mon, 2 Dec 2013 17:04:41 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7EF1AE005 for ; Mon, 2 Dec 2013 17:04:39 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id z10so19239046pdj.16 for ; Mon, 02 Dec 2013 17:04:37 -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=D8vAv+mqbdVcoiGNcjFZyNNQlX9V3yZ4Q37mp35kQFE=; b=qscbFjcL8qurzOBolQ4yhZsCNRy28LmEqs85wxUmDbB+r7W04d0xOLo9P0wk/h6QPy FWelmbteT3GauKHn6UxIiRNsIUt7i8/gnGFeq3QxI5IZp0iI0+qUAd0NqLfdcSC3iA4k WbwpRJ9crSeJUZneFDppuUXDVNfxjoWX99jGvsk7utdDOaKIg4ctWtxrOWGw/Pu4i+In EjtecCbQ6cUI1f1dwn7s4TV7GW0gLCChJgr2T44WJnewVwZNPe3AaikE4FD6lEV47L9A IjfFl0kzYTf8LfauHSygjdJ/Q4uiwL+an6EWQSZm4ODV/SICfIlN18FJdwNbACW0o916 Mhrg== X-Received: by 10.66.119.105 with SMTP id kt9mr34009847pab.94.1386032677134; Mon, 02 Dec 2013 17:04:37 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Mon, 2 Dec 2013 17:04:07 -0800 (PST) In-Reply-To: References: From: Sriganesh Kini Date: Mon, 2 Dec 2013 17:04:07 -0800 X-Google-Sender-Auth: d66uI0FwlDKC2ML3UrIbhhEW7Y8 Message-ID: To: Krishnan Subramanian Content-Type: multipart/alternative; boundary=047d7b0723105e28b604ec96e151 Cc: "i2rs@ietf.org" Subject: Re: [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: Tue, 03 Dec 2013 01:04:42 -0000 --047d7b0723105e28b604ec96e151 Content-Type: text/plain; charset=UTF-8 If a device has a routing system in it, then yes, it is in scope to be reflected in the I2RS topology model. Sri On Thu, Nov 28, 2013 at 1:28 PM, Krishnan Subramanian < Krishnan.Subramanian@guavus.com> wrote: > Hi , > > Will access networks like broadband networks (cable, DSL, FTTH) be > supported 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 > networks 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 > delivering location based > services in addition to analytics that are topology aware. > > Regards, > Krishnan Subramanian > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --047d7b0723105e28b604ec96e151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If a device has a routing system in it, then yes, it is in= scope to be reflected in the I2RS topology model.


<= /div>
Sri


On Thu, Nov 28, 2013 at 1:28 PM, Krishnan Subramanian <= ;Krish= nan.Subramanian@guavus.com> wrote:
Hi ,

Will access networks like broadband networks (cable, DSL, FTTH) be sup= ported in the=C2=A0
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=C2=A0
services in addition to analytics that are topology aware.

Regards,
Krishnan Subramanian


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


--047d7b0723105e28b604ec96e151-- From lhotka@nic.cz Tue Dec 3 01:47:40 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 9B1FB1A1F71 for ; Tue, 3 Dec 2013 01:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no 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 UoMk4HzPRgXv for ; Tue, 3 Dec 2013 01:47:39 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id E6DBF1AE067 for ; Tue, 3 Dec 2013 01:47:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 97AF05403AA; Tue, 3 Dec 2013 10:47:34 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHoMsboHd+su; Tue, 3 Dec 2013 10:47:29 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CF388540218; Tue, 3 Dec 2013 10:47:24 +0100 (CET) From: Ladislav Lhotka To: Sriganesh Kini , Krishnan Subramanian In-Reply-To: References: User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Tue, 03 Dec 2013 10:47:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "i2rs@ietf.org" Subject: Re: [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: Tue, 03 Dec 2013 09:47:40 -0000 Sriganesh Kini writes: > If a device has a routing system in it, then yes, it is in scope to be > reflected in the I2RS topology model. But isn't the restriction to unidirectional and PtP links too limiting for multiaccess networks? I understand that routing systems usually deal with some kind of pairwise adjacencies, but perhaps the topology model could be used in other contexts, too (as it is already the case in OpenDaylight). Lada > > > Sri > > > On Thu, Nov 28, 2013 at 1:28 PM, Krishnan Subramanian < > Krishnan.Subramanian@guavus.com> wrote: > >> Hi , >> >> Will access networks like broadband networks (cable, DSL, FTTH) be >> supported 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 >> networks 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 >> delivering location based >> services in addition to analytics that are topology aware. >> >> Regards, >> Krishnan Subramanian >> >> >> _______________________________________________ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From sriganeshkini@gmail.com Tue Dec 3 06:25:52 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 2C45D1AE0C5 for ; Tue, 3 Dec 2013 06:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 xHUKeb1Xxwa5 for ; Tue, 3 Dec 2013 06:25:50 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 711C31AC4C1 for ; Tue, 3 Dec 2013 06:25:50 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so21241833pbc.27 for ; Tue, 03 Dec 2013 06:25:47 -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=dzsNq14YLNBolW8sWkJL3E/lyS9aNCmK2T1Fx8e39bw=; b=qLt8svMAEKHzFbkB7SIlizVwoqsLF/yAl42BDQ4zmBPwYL4vhCJ0ic+JrKjYukB13/ HMnr4xcyTtO1ubsGTLKCcagItBSZoflpjetFVa9Jv0OZu2cEEE4mJKPtoglt/jpkyrE0 sjuK/+WC5b6+qhUtdKG78hE/UxqgNRPG/tBRI4JCfSIUAfY4F9kPZaDHvRM2zRBLENSk RzD3wSWiErQ4TjsSuoTl+jmQlFlvQWOvFKm7GR6W0Qls6eV3rTT+JZBiY3Sdg1xexX2G 8Y/ezFhuqpel+paplDjOOb2fT7VjM8rMtdgMfHBQXWSoapHteOM2w+teitAoMGREpHyR BniQ== X-Received: by 10.66.141.144 with SMTP id ro16mr36806344pab.131.1386080734195; Tue, 03 Dec 2013 06:25:34 -0800 (PST) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.228 with HTTP; Tue, 3 Dec 2013 06:25:03 -0800 (PST) In-Reply-To: References: From: Sriganesh Kini Date: Tue, 3 Dec 2013 06:25:03 -0800 X-Google-Sender-Auth: 7XHR29sljH7ZhBiF8ZhPFlB7CXA Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1133316ccab72904eca2116c Cc: "i2rs@ietf.org" , Krishnan Subramanian Subject: Re: [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: Tue, 03 Dec 2013 14:25:52 -0000 --001a1133316ccab72904eca2116c Content-Type: text/plain; charset=UTF-8 Mutipoint links should be in scope. They can be modeled using multiple p2p-unidirectional links just as IGPs have. The topology draft should reflect this. Sri On Tue, Dec 3, 2013 at 1:47 AM, Ladislav Lhotka wrote: > Sriganesh Kini writes: > > > If a device has a routing system in it, then yes, it is in scope to be > > reflected in the I2RS topology model. > > But isn't the restriction to unidirectional and PtP links too limiting for > multiaccess networks? I understand that routing systems usually deal with > some kind of pairwise adjacencies, but perhaps the topology model could be > used in other contexts, too (as it is already the case in OpenDaylight). > > Lada > > > > > > > Sri > > > > > > On Thu, Nov 28, 2013 at 1:28 PM, Krishnan Subramanian < > > Krishnan.Subramanian@guavus.com> wrote: > > > >> Hi , > >> > >> Will access networks like broadband networks (cable, DSL, FTTH) be > >> supported 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 > >> networks 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 > >> delivering location based > >> services in addition to analytics that are topology aware. > >> > >> Regards, > >> Krishnan Subramanian > >> > >> > >> _______________________________________________ > >> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1133316ccab72904eca2116c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mutipoint links should be in scope. They can be modeled us= ing multiple p2p-unidirectional links just as IGPs have. The topology draft= should reflect this.


Sri


On Tue, Dec 3, 2013 at 1:47 AM, Ladislav= Lhotka <lhotka@nic.cz> wrote:
Sriganesh Kini <sriganesh.kini@ericsson.com> writes:

> If a device has a routing system in it, then yes, it is in scope to be=
> reflected in the I2RS topology model.

But isn't the restriction to unidirectional and PtP links too lim= iting for multiaccess networks? I understand that routing systems usually d= eal with some kind of pairwise adjacencies, but perhaps the topology model = could be used in other contexts, too (as it is already the case in OpenDayl= ight).

Lada

>
>
> Sri
>
>
> On Thu, Nov 28, 2013 at 1:28 PM, Krishnan Subramanian <
> Krishnan.Subramania= n@guavus.com> wrote:
>
>> =C2=A0Hi ,
>>
>> =C2=A0Will access networks like broadband networks (cable, DSL, FT= TH) be
>> supported in the
>> network topology data model? This would include everything from th= e CPE
>> (ie. cable
>> modem ) to the a node, CMTS, headend , backhaul network. In wirele= ss
>> networks this would include every topology component
>> from the base station all the way up to the mobile backhaul networ= k as
>> well as access point to wireless controller.
>> Providing such a complete network topology model would be helpful = in
>> delivering location based
>> services in addition to analytics that are topology aware.
>>
>> =C2=A0Regards,
>> =C2=A0Krishnan Subramanian
>>
>>
>> _______________________________________________
>> 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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_____________________= __________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--001a1133316ccab72904eca2116c-- From akatlas@gmail.com Thu Dec 5 08:46:39 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 0028B1AE0CF for ; Thu, 5 Dec 2013 08:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8-5VJIWVObIi for ; Thu, 5 Dec 2013 08:46:36 -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 7FC7A1AE0C7 for ; Thu, 5 Dec 2013 08:46:36 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so28780741iec.7 for ; Thu, 05 Dec 2013 08:46:33 -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=BL2/dtx1uhM2HHUtQfB6u+V0xujJoOrWfDZR0iTWskk=; b=FBwGsvH6I3mH93KkzdmEP/3rtnC0pcrfj8NNsIjyHjZ39fnaf1S69YcXrkXLKK4QrP E9bgsw9Tt7C4k8EI8+VCDJ1lFbOMXsmY5XjNtx+Nl9rCDokzTmw+x4ts/aTjLqbZl75k VmaLlzwf/jaOLzG2+4QlCEHSBTOwTODpWUDe1KG/fYlOzVmBLCjbOU0ENyuA0F5HY28h PQc2nKyJOz5TfobMO9Dnp3uf6kD/Rp9haZL0I01grvmjRjJdTWr/2DwFyyhJlx1cqKT3 aH/ANsoKY4ywFJu5LL0F65sunNcJynvLou689SKRdyYsKr8RuNWzZ2Z5lXuGknzdIE0u XFKg== MIME-Version: 1.0 X-Received: by 10.42.48.202 with SMTP id t10mr56411507icf.9.1386261993106; Thu, 05 Dec 2013 08:46:33 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 08:46:32 -0800 (PST) In-Reply-To: References: <40746B2300A8FC4AB04EE722A593182B69F84BCA@ONWVEXCHMB04.ciena.com> <156BFC82-17F0-4D97-B1CF-BE0CACA1DC6D@gmail.com> <47554CB2-A4A9-498D-A242-FCE1B5F9777D@castlepoint.net> Date: Thu, 5 Dec 2013 11:46:32 -0500 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=90e6ba6e8e88aa520704eccc459b Cc: Shane Amante , Nikolay Milovanov , "Shah, Himanshu" , "i2rs@ietf.org" 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.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, 05 Dec 2013 16:46:39 -0000 --90e6ba6e8e88aa520704eccc459b Content-Type: text/plain; charset=ISO-8859-1 Sorry for the late response, but to summarize... What I am hearing is several things: a) We definitely need a device's perspective of topology - to include at least the IGP's LSDB and probably local interfaces. b) There is a strong desire for a network-wide topology-model - even though any protocol (north-bound, etc) to use that is definitely NOT in scope for I2RS. A key additional complexity for this is correlating the data from multiple devices' perspectives - and to get this right we should do both the device's perspective and the network-wide perspective in combination. However, it is not clear that any complex correlation logic would be in scope. c) As per the charter, writing topology is out of scope. d) Filtering of topology information by the I2RS agent for extraction would be very useful. e) Topology information is only PART of the IGP IM (whether we have an OSPF IM and an ISIS IM or...) I think that part of what we are running into is the need for indirection between different IMs - so that an IGP IM can express its LSDB based from a generic links-and-nodes model - but that may still have more information than a network-centric model would keep. It would also be useful to discuss what else should be in the IGP IM... While we've had a good discussion, is anyone (other than Jan, Alex, etc on (b)) specifically planning on working on any of the topology related IMs as I described above? In reference to my earlier comment about "I'm also not comfortable on having only one IM for basing all our requirements off of.", what I meant is that I2RS is rapidly progressing towards gap-analysis for both data-modeling languages and protocols (I'd love to see drafts soon) - and the reasoning for the requirements come from the architecture (fairly baked), the RIB IM (in good shape), various suggested use-cases (need work) and possibly Jan's network-centric topology IM (under serious discussion). I realize that draft-rfernando-i2rs-protocol-requirements-00 and draft-swhyte-i2rs-data-collection-system-00 also give some requirements and guidance - but they are also not yet WG drafts. We do need to get moving :-) Alia On Tue, Nov 12, 2013 at 1:56 PM, Edward Crabbe wrote: > 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 > > > --90e6ba6e8e88aa520704eccc459b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry for the late response, but to summarize...

<= /div>
What I am hearing is several things:

a) = =A0We definitely need a device's perspective of topology - to include a= t least the IGP's LSDB and probably local interfaces.
b) =A0There is a strong desire for a network-wide topology-model - eve= n though any protocol (north-bound, etc) to use that is definitely NOT in s= cope for I2RS. =A0 A key additional complexity for this is correlating the = data from multiple devices' perspectives - and to get this right we sho= uld do both the device's perspective and the network-wide perspective i= n combination. =A0However, it is not clear that any complex correlation log= ic would be in scope.
c) As per the charter, writing topology is out of scope.
d) = Filtering of topology information by the I2RS agent for extraction would be= very useful.
e) Topology information is only PART of the IGP IM = (whether we have an OSPF IM and an ISIS IM or...)

I think that part of what we are running into is the ne= ed for indirection between different IMs - so that an IGP IM can express it= s LSDB based from a generic links-and-nodes model - but that may still have= more information than a network-centric model would keep.

It would also be useful to discuss what else should be = in the IGP IM...

While we've had a good discus= sion, is anyone (other than Jan, Alex, etc on (b)) specifically planning on= working on any of the topology related IMs as I described above? =A0

In reference to my earlier comment about "I'm also not comfor= table on having only one IM for basing all our requirements off of.", = what I meant is that I2RS is rapidly progressing towards gap-analysis for b= oth data-modeling languages and protocols =A0(I'd love to see drafts so= on) - and the reasoning for the requirements come from the architecture (fa= irly baked), the RIB IM (in good shape), various suggested use-cases (need = work) and possibly Jan's network-centric topology IM (under serious dis= cussion). =A0 I realize that=A0draft-rfernando-i2rs-protocol-requirements-00 a= nd=A0draft-swhyt= e-i2rs-data-collection-system-00 also give some requirements and guidan= ce - but they are also not yet WG drafts.

We do need to get moving :-)

A= lia



On Tue, Nov 12, 2013 at 1:56 PM, Edward Crabbe <edc@google= .com> wrote:
With my chair hat off:

Any 'device-centric' model must be composable into a 'network-w= ide'
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 <shane@castlepoint.net> wrote:
>
> 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<= br> > network topology manager will have to collect and transform informatio= n
> gained from many network devices.
>
>
> +1.
>
> I believe I may be observing a tension between the traditional IETF vi= ew 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, b= ut what's
> more critical for my business is to look at the whole network, which i= s a
> collection of devices". =A0A Network Topology Information Model w= ould 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
>

--90e6ba6e8e88aa520704eccc459b-- From akatlas@gmail.com Thu Dec 5 08:50:07 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 551D21AE0F9 for ; Thu, 5 Dec 2013 08:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Y7RKKJxgKSAv for ; Thu, 5 Dec 2013 08:50:05 -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 48B461AE0FB for ; Thu, 5 Dec 2013 08:50:05 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so30256480ieb.32 for ; Thu, 05 Dec 2013 08:50:01 -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=/Sym0Onq4J+QBzAxd3nYmuWg71sVMNyuNO9ydUFx6Bk=; b=js+cQ9f/TfjlzuSdz3hhDdQ9iVGqU3yaxNy7HMow1WdsoszqWkqFv30xlJWAJ2FQDQ TYLLKRy/M+4MuJIHFarobRSwhqYCYYIwLYStg6L4MnyJtVnU0jOjNAUZGzsqU5CkXEjW 8mUSDRs1WuJ42duhn9p9ejZ9XxScry4fNpjhinW66034iv7JrluXfOjbzE6Sb0trqqec T5exL1GUeuadn30Tf/kr6LidNC8/EUShlEjuUu4q8P6gAITLHuAayLeFkh3VmUOGbk9h KXmQg74h7BqrQnoAF5p3vk/rr4IivGPdxHnqdhCbvs2qCQn83umw5LEaGwTa98CYjqZu qVVg== MIME-Version: 1.0 X-Received: by 10.50.40.102 with SMTP id w6mr7252156igk.20.1386262201803; Thu, 05 Dec 2013 08:50:01 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 08:50:01 -0800 (PST) In-Reply-To: <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <527BFA73.70108@cisco.com> <20ECF67871905846A80F77F8F4A2757210459D69@xmb-rcd-x09.cisco.com> Date: Thu, 5 Dec 2013 11:50:01 -0500 Message-ID: From: Alia Atlas To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=089e0112c7fe1aa9a704eccc5298 Cc: "i2rs@ietf.org" , "Joe Clarke \(jclarke\)" 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.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, 05 Dec 2013 16:50:07 -0000 --089e0112c7fe1aa9a704eccc5298 Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, On Thu, Nov 7, 2013 at 3:51 PM, Eric Osborne (eosborne) wrote: > 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. > > 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. > I agree that (2) makes sense - but certainly how it gets done does matter. Writing isn't the only complexity. Take another read through draft-swhyte-i2rs-data-collection-system if you think it is :-) For instance, I see (2) as likely being exposed as an information stream that can be subscribed to. 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 you *need* a way to lock all > devices. Perhaps this is best done in the client - acquire a lock on the > config 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 what it would have to do under the covers anyways. And if you have > locking write access to the client then you don't need a network model, > just a router model. > Writing the topology is specifically out of scope. I2RS is certainly not expecting to do things such as lock all devices. Alia --089e0112c7fe1aa9a704eccc5298 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,

On Thu, Nov 7, 2013 at 3:51 PM= , Eric Osborne (eosborne) <eosborne@cisco.com> wrote:
If you want to get the link sta= te 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.

IMO either one is OK, and #2 makes the most sense. =A0In any case it's = a read-only thing so it doesn't really matter how it gets done.

I agree that (2) makes sense - but certainly h= ow it gets done does matter. =A0Writing isn't the only complexity. =A0T= ake another read through=A0draft-swhyte-i2rs-data-collection-system=A0if you think it i= s :-)
For instance, I see (2) as likely being exposed as an information stre= am that can be subscribed to.

Where it gets hairy is when you want to write to the network. =A0The questi= on that kicked off this thread was along those lines, if I recall. =A0If yo= u want to get a mutex on the network as a whole you *need* a way to lock al= l devices. =A0Perhaps this is best done in the client - acquire a lock on t= he config for each node in the network, make your changes, then unlock. =A0= If there were a higher level way to do this with some sort of network API t= hat's what it would have to do under the covers anyways. =A0And if you = have locking write access to the client then you don't need a network m= odel, just a router model.

Writing the topology is specifically out o= f scope. =A0I2RS is certainly not expecting to do things such as lock all d= evices.
=A0
Alia
--089e0112c7fe1aa9a704eccc5298-- From akatlas@gmail.com Thu Dec 5 08:58:51 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 00B6C1AE0A7 for ; Thu, 5 Dec 2013 08:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 uLs0bxQX_crS for ; Thu, 5 Dec 2013 08:58:47 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 03A821AE0E2 for ; Thu, 5 Dec 2013 08:58:46 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so29495176iej.40 for ; Thu, 05 Dec 2013 08:58:43 -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=D68KzgDzuuhw4brDbkfTipXrduz38/yE5o8Gs4zLEh0=; b=IjVazmMurp5m/KIksTmRkRQYQ5TnCe54pP0dowvkjXoi/vPbPrubSjIjo0M+RacZfv US9VYz2lM3hVkdxuYn8CcncboA+L2sj7FOYqOm8tx9rNcKDaLzeWaiXbqu3YYsiNlS0Y BkaEM/+OAfAzi8Aos0lBrQ9WnZ3LzquXUOkS9db484A5iT5C3bQ5SrsW8o5zD5UeowMa s5rntlL1PcduvEyLqW+99HI6u/wOwc/7ChuaiMheu0ml0LB+ttM6TR7YM8H6BjB//O5S e6ajEWfoKWERTCpMt2ZcAU5x3HYH7PW/LWjsv1PuvV2ekPuLSCEgXx37PDNZaCf3ZXU7 BHnw== MIME-Version: 1.0 X-Received: by 10.42.123.199 with SMTP id t7mr15785103icr.45.1386262723510; Thu, 05 Dec 2013 08:58:43 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 08:58:43 -0800 (PST) In-Reply-To: References: <20ECF67871905846A80F77F8F4A27572104578C9@xmb-rcd-x09.cisco.com> <002701cedb80$e0285700$a0790500$@riw.us> <0F7BE70F-6D4A-4FEC-9A87-3A596B48F105@gmail.com> Date: Thu, 5 Dec 2013 11:58:43 -0500 Message-ID: From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=20cf301af61933489c04eccc716c Cc: Russ White , "i2rs@ietf.org" , Nikolay Milovanov , "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.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, 05 Dec 2013 16:58:51 -0000 --20cf301af61933489c04eccc716c Content-Type: text/plain; charset=ISO-8859-1 Hi Sri, Sorry for top-posting. I generally agree that understanding what information should be including in the device perspective's topology IM in order to resolve discrepancies is important. I don't think that we need to recreate IGPs' mechanisms for this - but rather include the information in there so that resolution can be done. For instance, with an LSA - it is clear which is more recent. If multiple router LSAs from the same router are reported by different devices, then clearly the network is reconverging - and there can be flags indicating this along with old state and new state. Ideally, one could associate the time that a device originated an LSA (if that device is contributing information) as well. For each OSPF area, it could be marked as reconverging or stable. I think that probably one would have two topologies available - the "old" and the "new" where the default would be to work with the new. Does that make sense to you? Alia On Thu, Nov 7, 2013 at 4:56 PM, Sriganesh Kini wrote: > Hi Nikolay, > > On Thu, Nov 7, 2013 at 1:33 PM, Nikolay Milovanov > wrote: > > 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 perspective". > > 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 > different 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 > 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. > > > > 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 > 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. > > 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. > > 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 > --20cf301af61933489c04eccc716c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sri,

Sorry for top-posting. =A0 I ge= nerally agree that understanding what information should be including in th= e device perspective's topology IM in order to resolve discrepancies is= important. =A0I don't think that we need
to recreate IGPs' mechanisms for this - but rather include the inf= ormation in there so that resolution can be done. =A0For instance, with an = LSA - it is clear which is more recent. =A0If multiple router LSAs from the= same router are reported by different devices, then clearly the network is= reconverging - and there can be flags indicating this along with old state= and new state. =A0Ideally, one could associate the time that a device orig= inated an LSA (if that device is contributing information) as well. =A0 For= each OSPF area, it could be marked as reconverging or stable. =A0I think t= hat probably one would have two topologies available - the "old" = and the "new" where the default would be to work with the new.

Does that make sense to you?

A= lia


On Thu, Nov 7, 2013 at 4:56 PM, Sriganesh Kini <sriganesh.kini= @ericsson.com> wrote:
Hi Nikolay,

On Thu, Nov 7, 2013 at 1:33 PM, Nikolay Milovanov <n.milovanov@gmail.com> wrote:
> Hi Sri,
>
> I guess instead of "complete model of entire network topology&quo= t; =A0it should be "a model of the network topology as visible from a = particular device perspective".

This is still a device-centric topology view. Even though it may be o= f
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 =A0topology discoverer acting as an i2rs client will have to have = some rules in order to handle differences between network models received b= y different 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 = part of the model received from one network node(agent) and are missing fro= m 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 discrepa= ncy mechanism able to handle that. It might be configurable and able to do = different 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 =A0How formal that m= odel 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 s= ome of the edge properties to be the local/remote interface through which t= he edge 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 = nodes in the network but related to the same node/edge will have the same u= nique ID so that the network topology manager will be able to merge it corr= ectly.

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 fro= m each
>> device" is within the scope of I2RS. Also note that "com= plete model of
>> entire network topology" can be misleading. This may be true = for small
>> networks within a single administrative domain, but as the scope o= f
>> the network increases (e.g. multiple administrative domains) there=
>> will not be a single way to get the "entire network topology&= quot;, but
>> there will be some details that will be abstracted out.
>>
>> - Sri
>>
>> On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov
>> <n.milovanov@gmail.com= > wrote:
>>> Most likely the network-centric topology models coming from ea= ch 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

--20cf301af61933489c04eccc716c-- From akatlas@gmail.com Thu Dec 5 09:02:46 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 73E9D1AE0E1 for ; Thu, 5 Dec 2013 09:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 o-MkyiIY0JtG for ; Thu, 5 Dec 2013 09:02:42 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 69BC51ADFB4 for ; Thu, 5 Dec 2013 09:02:42 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so29507160iej.40 for ; Thu, 05 Dec 2013 09:02:38 -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=jHmkCYDN5j60L/C1KPq6+IrokTvp8qCbFdhDBF6S2O4=; b=qcO8NLrDihVzwMaY+j27tGMX5DhVSUOf+i4KJW+NKRTydyxHGozXvDjg1aeqANH67b /sk7n+fWdKTxkpXuCxyG7t3/6kaQ9zjsP6syFT9RPwFh1WHOi/NThRfjbCtT14WUbEzX hiUf4s41PSsU0ArLMWDCxDEpY/JDXXdWCh6oaybuuzBElQ1gQsUYVWdovge0yJopMzVN N21SlvS6GqORRJaUJ8nnM/HBebCUcvWO+heK1FDGNJz1qgTrIdienQn9NDOuTrvw8r1k xrc4hfTZ14UgTyMtzIwUA9Bi1KLSblvRO7OB960IHP/XWss5cOmxcX5tG+fq1ZSZqZKc pXSQ== MIME-Version: 1.0 X-Received: by 10.43.51.65 with SMTP id vh1mr54250234icb.24.1386262958839; Thu, 05 Dec 2013 09:02:38 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 09:02:38 -0800 (PST) In-Reply-To: <527BBCAE.5050102@joelhalpern.com> References: <527BBCAE.5050102@joelhalpern.com> Date: Thu, 5 Dec 2013 12:02:38 -0500 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=bcaec5299ad73a1d1204eccc7feb Cc: Russ White , "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Nikolay Milovanov , "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.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, 05 Dec 2013 17:02:46 -0000 --bcaec5299ad73a1d1204eccc7feb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Joel, On Thu, Nov 7, 2013 at 11: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. > We certainly need protocol specific information included to help with resolving different data in LSDBs. We also need additional functionality for IGP IMs beyond the topology. 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. > Agreed - so can we have dependencies or reuse of the aspects in common? That seems desirable for accurately describing the IMs as well as the data-models. > 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. > I agree that it is not our workspace - but being able to combine the information from different device's into a network-wide model is important and I don't think it will be possible without careful initial thought and working in parallel. Regards, Alia > 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 >> >> --bcaec5299ad73a1d1204eccc7feb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Joel,

On Thu, Nov 7, 2013 at 11:15 AM, Joel M. Halpern <jmh@joelhalp= ern.com> wrote:
If I thought we could get away with not havi= ng protocol specific information models, then trying to design a protocol i= ndependent topology model for use with the network elements would seem appl= icable.

We certainly need protocol specific inform= ation included to help with resolving different data in LSDBs. =A0We also n= eed additional functionality for IGP IMs beyond the topology.
But, as it stands, even if we had such= a model, we would still need protocol specific models, which would be havi= ng to manipulate many aspects related to the common model.

Agreed - so can we have dependencies or re= use of the aspects in common? =A0That seems desirable for accurately descri= bing the IMs as well as the data-models.
=A0
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.

I agree that it is not our workspace - but being able t= o combine the information from different device's into a network-wide m= odel is important and I don't think it will be possible without careful= initial thought and working in parallel.
=A0
Regards,
Alia


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


--bcaec5299ad73a1d1204eccc7feb-- From akatlas@gmail.com Thu Dec 5 09:11:23 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 552501AE0C9 for ; Thu, 5 Dec 2013 09:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 JFtpnlKkCE5R for ; Thu, 5 Dec 2013 09:11:16 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 88CCE1AE0D4 for ; Thu, 5 Dec 2013 09:11:16 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so28786186iej.26 for ; Thu, 05 Dec 2013 09:11:13 -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=rimd3I0o2IG7rXAuF6tQ594BU0dpmZyrdQOxBhrJq3U=; b=qiA4+dfTOwiDtO5AK8ddMVP9iiZcPX4dtrsxehQ7sb7iopLlaKeJNyEmxR7d7yydqH HxW5lLKbEA0rzU3yirGydV4ZoVNjkRJTRZC5B8R2D6x898Lfums3MnexqydRWLWPCgzU lMUfqUyG03CgnP6D9QecphdM4cpX5HvtAiBpJsBPOgxq6/7Xjytkvgl/AprusRhW4uv3 bRsc/JUCOd/7e8Tsiri7v0/gNXAUcarxOZuHefFSgKUp3lBGH9sUgkY81RQglFB2pZcE LCngZD1JlD4BpisAPgcnFbA82i+dSMNPXXiUjIKauRZMP9jD9W7nFKJV1QCcZZIyT/+4 Swng== MIME-Version: 1.0 X-Received: by 10.50.92.8 with SMTP id ci8mr14002438igb.23.1386263473092; Thu, 05 Dec 2013 09:11:13 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 09:11:12 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 12:11:12 -0500 Message-ID: From: Alia Atlas To: "Jan Medved (jmedved)" Content-Type: multipart/alternative; boundary=047d7b10cf27e0fd8904eccc9d8c Cc: "i2rs@ietf.org" 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.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, 05 Dec 2013 17:11:23 -0000 --047d7b10cf27e0fd8904eccc9d8c Content-Type: text/plain; charset=ISO-8859-1 Hi Jan, Sorry for being so long in replying - but to answer your questions finally... On Thu, Nov 7, 2013 at 3:04 AM, Jan Medved (jmedved) wrote: > 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 questions then: > > - Is an OSPF router or an IS-IS router a 'routing system', as defined > in the WG charter? If yes, would its LSDB 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 router > via a tbd. I2RS protocol be considered 'extraction of information > about topology from the network', as defined in the WG charter? > > Yes - absolutely - but the LSDP is not the only information that needs to be in an OSPF/ISIS IM. > > - Is a BGP Router Reflector a routing system, as defined in the WG > charter of the WG? If yes, would 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 > the latter question is yes, would reading the LSDB information from the RR > be 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 > protocol that would be 'extracting information about topology from > the network'? > > Reading the topology info collected by BGP-LS would qualify. I am torn about having BGP-LS being considered an I2RS protocol. We certainly started I2RS with the idea of being inclusive of multiple protocols that could provide the desired functionality. Since then, I think that the WG has been more focused on a single protocol - though with the potential for "off-loading", such as requesting information but having it delivered via IPFIX or possibly a "log-file" via SCP. BGP-LS, of course, has some of the desired performance characteristics, but certainly isn't quite a data-model driven protocol. What I'd like to see in this space would be an IM for BGP-LS with a mapping to the data in BGP-LS. Then, one could either use I2RS to request the data and information stream or one could simply implement BGP-LS and listen. I say "simply" but I've been given to understand that implementing BGP, even as just a listener, is adding a non-trivial burden for network applications. Of course, how relevant that is for just getting something going or for a model with an I2RS broker is another question. Regards, Alia > 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 > 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 > > --047d7b10cf27e0fd8904eccc9d8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jan,

Sorry for being so long in repl= ying - but to answer your questions finally...

On Thu, Nov 7, 2013 at 3:04 AM, Jan Medv= ed (jmedved) <jmedved@cisco.com> wrote:
Hi Alia,

Thanks for sta= rting the conversation :-)

IMO, the lines= between 'network-centric' and 'device-centric' are a littl= e blurred. For the sake of argument, let me agree with Joel that the I2RS W= G's scope should be limited to a single routing system. Let me ask a few questions then:
  • Is an OSPF rout= er or an IS-IS router a 'routing system', as defined in the WG char= ter? If yes, would its LSDB be considered 'topology information' as= defined in the WG charter? =A0And 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 informa= tion about topology from the network', as defined=A0in the WG charter?
Ye= s - absolutely - but the LSDP is not the only information that needs to be = in an OSPF/ISIS IM.=A0
  • Is a BGP Router Reflector a=A0r= outing system, as defined in the WG charter of the WG? If yes, would the LS= DB information (potentially collected from multiple IGP areas) in RR's = BGP-RIB be considered=A0'topology information' as defined in the WG charter?=A0And if the the answer to the la= tter question is yes, would reading the LSDB information from the RR be con= sidered=A0'extraction of information about topology from the network', as defined in<= span style=3D"font-family:Calibri,sans-serif;font-size:14px">=A0the WG char= ter? 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 =A0that would =A0be 'extracting = information about topology from the network'?
Reading the topology info collected by BGP-LS would qualify. =A0 I am = torn about having BGP-LS being considered an I2RS protocol. =A0We certainly= started I2RS with the idea of being inclusive of multiple protocols that c= ould provide the desired functionality. =A0Since then, I think that the WG = has been more focused on a single protocol - though with the potential for = "off-loading", such as requesting information but having it deliv= ered via IPFIX or possibly a "log-file" via SCP. =A0BGP-LS, of co= urse, has some of the desired performance characteristics, but certainly is= n't quite a data-model driven protocol.=A0

What I'd like to see in this space would be an IM f= or BGP-LS with a mapping to the data in BGP-LS. =A0Then, one could either u= se I2RS to request the data and information stream or one could simply impl= ement BGP-LS and listen. =A0I say "simply" but I've been give= n to understand that implementing BGP, even as just a listener, is adding a= non-trivial burden for network applications. =A0Of course, how relevant th= at is for just getting something going or for a model with an I2RS broker i= s another question.

Regards,
Alia=A0


Thanks,
Jan


From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, November 6, 2013 6= :23 PM
To: "i2rs@ietf.org" <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 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

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

--047d7b10cf27e0fd8904eccc9d8c-- From akatlas@gmail.com Thu Dec 5 09:20:22 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 2E1331AE122 for ; Thu, 5 Dec 2013 09:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 vFDWAL1Nt1qE for ; Thu, 5 Dec 2013 09:20:19 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 477481AE134 for ; Thu, 5 Dec 2013 09:20:19 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id qd12so30366937ieb.15 for ; Thu, 05 Dec 2013 09:20: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=OiT80RocmLn2U5OM991Q70IbJn8e0Bp9gl/re3bhHw0=; b=WHo4nEL3xL8MnmZ5SEXDSoWvp3oA7jxwk0/3d4uHrcg/MmJ79aa9OZWq8o+xdazM3h p0hU289Ilow6FruuFcQtdLlQScp7Xfds1TbCb6o1KtiopOQOf76bA5mexdJUSSx7JbW4 LpE6Sbs8FALgFMtXC4lbkfeg2THUE2H7Tg37O1BBEmqxC/wiRc1Xa2rX40nFucefno0z CSxnIGdpL3VnOtpXW/T1n74FJ8xOrfJtCkFxU4eVRbdMj2JtKRgowsi9Sj3wEiPo1x17 JzdQl108pDLLEwNo62ddr6vaF/RH2vYKYXjyaSvnW3wHSjzuuCkNWPFkIxpr8OBCBE7J QwtA== MIME-Version: 1.0 X-Received: by 10.42.46.80 with SMTP id j16mr820230icf.94.1386264015667; Thu, 05 Dec 2013 09:20:15 -0800 (PST) Received: by 10.64.78.103 with HTTP; Thu, 5 Dec 2013 09:20:15 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 12:20:15 -0500 Message-ID: From: Alia Atlas To: "Jan Medved (jmedved)" Content-Type: multipart/alternative; boundary=90e6ba614d203810fb04ecccbe35 Cc: Russ White , "i2rs@ietf.org" , Nikolay Milovanov , "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.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, 05 Dec 2013 17:20:22 -0000 --90e6ba614d203810fb04ecccbe35 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jan, I think many of these have already been addressed in my other emails, but here are responses to the rest. On Thu, Nov 7, 2013 at 3:51 AM, Jan Medved (jmedved) wro= te: > > > 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 on= ly > 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 the= n > 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. > Yes, part of that information is - but, for instance, knowing the LSA that the data came from for reconciling differences isn't there. That's just data that is needed for the device-perspective vs. a network-wide resolved-perspective. Also, as said elsewhere, it isn't just topology that comes from the IGPs. > 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. > Again - the pieces for reconciliation are missing. I do think that we also want an interface-focused IM but that can have more/different information than what is in the IGP IMs or BGP-LS IMs. > > I'd really like to make significant progress in understanding the > perspectives and thoughts of the WG on this. I understand that all thes= e > 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 han= d, > there is a variety of information (in devices and in other systems) that > can (must be) be used to 'stitch' together a network topology: dynamicall= y > learned neighbor info (LLDP for example for L2, IGP neighbor info for L3, > for example), statically configured neighbor info in device configuration= s, > IGP LSDB, IGP configurations, inventory systems, interface data (interfac= e > type, speed, =85), LAGs, etc. Trying to model all of this can turn out to= be > quite a chunk to bite off. > Oh, it's certainly not small - and I don't think that we have to bite off all of it at once. I think we need a bottoms-up device-centric approach AND the top-down network-centric approach to be sure that each has the necessary details. > 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? > Please see my other summarizing email. > 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 inf= o) > would not be in scope? How would you define 'network-centric'? > I think that device-centric is what a single device would know - which can and does include information learned via routing protocols. > 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? > I certainly hope that we are considering those types of criteria! Regards, Alia > > > 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 t= he >> device centric model will be something hierarchical with a root object t= he >> 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 b= e >> 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 mak= e >>> certain we are getting all the information we need from the models at t= he >>> 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 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 >>> topologies, >>> or that sort of thing. >>> >>> > If Yes: ok, cool. But between link properties (that is, at least som= e >>> 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 problem= s >>> 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 >> > > --90e6ba614d203810fb04ecccbe35 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Jan,

I think many of these have alre= ady been addressed in my other emails, but here are responses
to = the rest.

On T= hu, Nov 7, 2013 at 3:51 AM, Jan Medved (jmedved) <jmedved@cisco.com>= ; wrote:


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.org>, "Er= ic 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= concern and different options are as far as modeling the topology informat= ion from a device. =A0 draft-medved-i2rs-topology-im has changed only minim= ally 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 = topology. =A0Would we then need a different IM - perhaps as part of an IGP-= specific IM - to communicate the topology learned via the IGP? =A0Would that be preferable?

If we decide that=A0topology learned via the IGP is=A0indeed in scope = WG to go, then the IGP-specific IMs are already defined in=A0draft-medved-i= 2rs-topology-im.

Yes, part of t= hat information is - but, for instance, knowing the LSA that the data came = from for reconciling differences isn't there. =A0 That's just data = that is needed for the device-perspective vs. a network-wide resolved-persp= ective. =A0Also, as said elsewhere, it isn't just topology that comes f= rom the IGPs.
=A0
Given tha= t the active IGP topology can be learned via BGP-LS, are we better off focu= sing on an interface-focused IM (whether that is a device model or an inter= faces model or...)?
The same topology I'm model wo= uld apply to BGP-LS and to IGPs.=A0
=A0
Again - the pieces for reconciliation are missing. =A0I do= think that we also want an interface-focused IM but that can have more/dif= ferent information than what is in the IGP IMs or BGP-LS IMs.=A0

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

IMHO, it is actually easier to define the base network topology = IM than the device IMs from which a network topology can be 'stitched t= ogether'. The base network topology IM is simple: it's a directed g= raph 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.=A0

Oh, it's certainly not small - = and I don't think that we have to bite off all of it at once. =A0I thin= k we need a bottoms-up device-centric approach AND the top-down network-cen= tric approach to be sure that each has the necessary details.
=A0
I'm a= lso not comfortable on having only one IM for basing all our requirements o= ff of.
I don't understand what you mean - can you please explain?

Please see my other summarizing = email.
=A0
So - more thoughts?

The charter does not say anything about 'device-centric' or &#= 39;network-centric' IMs - it talks merely about 'topology informati= on'. Can you define what 'device-centric' and 'network-cent= ric' is? =A0Would '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-ce= ntric' 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'?

I think that device-centric is what a single devic= e would know - which can and does include information learned via routing p= rotocols.
=A0
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?

I certainly hope that we are considering those types of criteria!

Regards,
Alia


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=A0Topolog= y API Use Cases my guess would be.=A0

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

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.=A0

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 :)

=A0
BR,=A0
Nikolay Milovanov

Network Engineer




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

> 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, 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 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.milovan= ov@gmail.com

--90e6ba614d203810fb04ecccbe35-- From jmh@joelhalpern.com Thu Dec 5 10:34:38 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 731BA1AE035 for ; Thu, 5 Dec 2013 10:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 MPjJM_Thrj0a for ; Thu, 5 Dec 2013 10:34:34 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C33871AD84D for ; Thu, 5 Dec 2013 10:34:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A36391C623B7; Thu, 5 Dec 2013 10:34:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [81.145.171.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1652C1C623B2; Thu, 5 Dec 2013 10:34:27 -0800 (PST) Message-ID: <52A0C730.40308@joelhalpern.com> Date: Thu, 05 Dec 2013 13:34:24 -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.1 MIME-Version: 1.0 To: Alia Atlas References: <527BBCAE.5050102@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Russ White , "i2rs@ietf.org" , "Jan Medved \(jmedved\)" , Nikolay Milovanov , "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.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, 05 Dec 2013 18:34:38 -0000 Being able to combine information from multiple protocol models is clearly necessary if this is going to work. But as far as I can tell, that really means making sure that the identifiers correlate. Yes, all the models will have links and nodes. But in fact trying to extract the commonalities is rather challenging. BGP does not actually model network links at all. It models reachability and AS abstract connectivity. Similarly, RIP models very differently from OSPF or IS-IS. So I am very concerned that spending time on the aggregation model will actually interfere with our ability to get teh protocol models. And arguably the most important relationship is between the protocol network models and the RIB model. After that, the next most important aspect of the protocol network models is their policy modeling. Yours, Joel On 12/5/13 12:02 PM, Alia Atlas wrote: > Joel, > > On Thu, Nov 7, 2013 at 11: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. > > > We certainly need protocol specific information included to help with > resolving different data in LSDBs. We also need additional > functionality for IGP IMs beyond the topology. > > 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. > > > Agreed - so can we have dependencies or reuse of the aspects in common? > That seems desirable for accurately describing the IMs as well as the > data-models. > > 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. > > > I agree that it is not our workspace - but being able to combine the > information from different device's into a network-wide model is > important and I don't think it will be possible without careful initial > thought and working in parallel. > Regards, > Alia > > > 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 russw@riw.us Thu Dec 5 11:59:22 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 1929E1AE0C5 for ; Thu, 5 Dec 2013 11:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 cA2GymOO3Kkt for ; Thu, 5 Dec 2013 11:59:20 -0800 (PST) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1451AE04F for ; Thu, 5 Dec 2013 11:59:20 -0800 (PST) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:58515 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Vof4j-0008V7-Nk; Thu, 05 Dec 2013 19:59:06 +0000 From: "Russ White" To: "'Joel M. Halpern'" , "'Alia Atlas'" References: <527BBCAE.5050102@joelhalpern.com> <52A0C730.40308@joelhalpern.com> In-Reply-To: <52A0C730.40308@joelhalpern.com> Date: Thu, 5 Dec 2013 14:59:13 -0500 Message-ID: <019601cef1f4$79d3a1f0$6d7ae5d0$@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: AQJdMJANgOs+cT9yg2VJ3CGj4TW+tQFs33GRAMEdQ38CINkssJkHEPmQ 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, "'Jan Medved \(jmedved\)'" , 'Nikolay Milovanov' , "'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.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, 05 Dec 2013 19:59:22 -0000 > And arguably the most important relationship is between the protocol > network models and the RIB model. > After that, the next most important aspect of the protocol network models is > their policy modeling. Agreed -- which is why the RIB model is so important to get right the first time. :-) Russ From jclarke@cisco.com Sun Dec 8 14:15:21 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 A43A31AE140 for ; Sun, 8 Dec 2013 14:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 As4xjFm_u1j5 for ; Sun, 8 Dec 2013 14:15:19 -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 CE27A1AE138 for ; Sun, 8 Dec 2013 14:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2372; q=dns/txt; s=iport; t=1386540915; x=1387750515; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rYu5uOGz+h6X2f8q4Pt36VxQ0MJYRW8t6TMusA3XrRE=; b=hOUpQrpWRIJ6V29y3fM71WOWxgy/y1guBW4iS1ZXOWUgiHNh+WdP231M hFWd5oA8LT6weQIo7ZZj4T9gDXLm0XnQiSV9XI8DD8d7QXhZ19NRcYVYv w4hwegcPYcZPy4IoAWTglv8n5uaOc5vnJ8ufIzoEeK5iDHBieQthi+ZRF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FALXupFKrRDoJ/2dsb2JhbABWA4MHOE2DBbYRgRgWbQeCJQEBAQQjFT8BDQICHAECAQIDAgUMCgsCAgkDAgECAQkiDAQCCAYNBgIBAQWHeAkFsVWOfRcEgSWNBREBLhIXBgQHglqBSAOJQo5SgTCQY4NHHoE1 X-IronPort-AV: E=Sophos;i="4.93,853,1378857600"; d="scan'208";a="99839919" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 08 Dec 2013 22:15:14 +0000 Received: from prosciutto.local ([10.154.66.49]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB8MFCC0028870 for ; Sun, 8 Dec 2013 22:15:12 GMT Message-ID: <52A4EF70.2040807@cisco.com> Date: Sun, 08 Dec 2013 17:15:12 -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.1 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20131208221415.21915.56519.idtracker@ietfa.amsl.com> In-Reply-To: <20131208221415.21915.56519.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131208221415.21915.56519.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [i2rs] Fwd: New Version Notification for draft-clarke-i2rs-traceability-01.txt 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: Sun, 08 Dec 2013 22:15:21 -0000 We have posted rev -01 of our traceability draft taking into account some feedback we got off-list. We would appreciate any other feedback on this ON LIST. Thanks. Joe -------- Original Message -------- Subject: New Version Notification for draft-clarke-i2rs-traceability-01.txt Date: Sun, 8 Dec 2013 14:14:15 -0800 From: To: Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro A new version of I-D, draft-clarke-i2rs-traceability-01.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Filename: draft-clarke-i2rs-traceability Revision: 01 Title: Interface to the Routing System (I2RS) Traceability: Framework and Information Model Creation date: 2013-12-08 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-01.txt Status: http://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability Htmlized: http://tools.ietf.org/html/draft-clarke-i2rs-traceability-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-01 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. 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 -- 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 ----------------------------------------------------------------------------