Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1421F8741; Tue, 30 Oct 2012 10:34:14 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2pvCgXFxYP5; Tue, 30 Oct 2012 10:34:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1921F8671; Tue, 30 Oct 2012 10:34:12 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7E8D31410CD; Tue, 30 Oct 2012 18:34:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1351618450; bh=qXySzrMr0NjPNTCHXerJqOq1R8FJwvAaoctKvqnzFHo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AoUZLQyGNC+nfJZI8NV0ZDgavC8LW7DjbiPwEjoL4nEPz5YTxUuQqrAPgXB8pbFxN 7tfRazcOGqUhWZ/q6/NvGo0//bNgSK2uZTPYrlbeQ/bi7X4CTH3zlwPTJVXK30KX6s z721qZ5CkhvSoUA0DLQY5mRAJuI4SOQNhAei4rZs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121029162930.GA94042@elstar.local> Date: Tue, 30 Oct 2012 18:34:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121029162930.GA94042@elstar.local> To: brijsman@juniper.net X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org, irs-discuss@ietf.org Subject: Re: [irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft. X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:34:17 -0000 Hi Bruno, first of all, I have to apologise that I didn't answer your comments in = a timely manner, the message somehow fell through the cracks. :-( I hope = it's still not too late though the draft is now at revision -05. So, thanks for your comments, please see my responses inline. =20 >=20 > -------- Original Message -------- > Subject: [irs-discuss] A few comments on the = draft-ietf-netmod-routing-cfg-04 draft. > Date: Mon, 3 Sep 2012 07:15:08 -0400 > From: Bruno Rijsman > To: netmod@ietf.org > CC: irs-discuss@ietf.org >=20 > I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft. >=20 > 1) Generalize the concept of a next-hop >=20 > It appears that in the current model, routes can point to an outgoing = interface and a next-hop address. The concept of next-hops needs to be = generalized. Next-hops can have multiple tuples of outgoing interfaces = and next-hop addresses. The most common reasons is Equal Cost Multi Path = (ECMP) where a single route has multiple next-hops. This is not the same = as multi-pathing in the sense of multiple active routes to the same = prefix each contributing one next-hop. A variation of this is NECMP = where the next-hops are different weights. Another reason for multiple = next-hops is fast re-route where the next-hops represent alternatives = (the first one whose interface is up is used). Another needed = generalization of next-hops is the ability to push and pop MPLS labels, = VLAN tags, etc. Another is the ability to add a level of indirection = (e.g. BGP indirect next-hop for fast BGP reconvergence). The OpenFlow = 1.x documents are a good source to look for generalized next-hop = examples. I assume that multiple next-hops to the same destination will appear as = two separate routes. And indeed, the two routes may have different = weights. MPLS is outside the scope for the core routing data model, although the = framework should be ready to incorporate MPLS etc. via augments from = other modules. >=20 >=20 > 2) Generalize the concept of a prefix >=20 > Section 4.2 says that the core routing data model only defines the = following minimal set of route attributes: destination-prefix, next-hop, = outgoing-interface. However, in section 4 there are no = destination-prefix or next-hop. There are only v4ur:dest-prefix, = v4ur:next-hop, v6ur:dest-prefix, v6ur:next-hop. It appears that the Why is it a problem? These parameters are address family specific, so = they are defined in the ietf-ipv[46]-unicast-routing modules. Each = routing table only contains routes of a single address family, so the = ipv4:* and ipv6:* nodes can never appear as sibling elements in a = configuration or state data. > destination-prefix and next-hop were removed from the base object and = moved to the derived object. In my opinion, it would make sense to move = the destination-prefix (as a simple bit-string and length) and the = next-hop back to the base object. The derived object could have a string = object to contain the destination-prefix as a human-readable string = (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes = that the routes are always IP routes (it uses repeatedly uses terms like = "IP prefix"). The routes can be non-IP routes. For example, MPLS routes = which are /20 exact matches on a label, or CLNS routes, or other = protocols > . Some VPLS implemen > tations even use the "routing table" abstraction to represent Ethernet = routes (as exact /48 routes on MAC addresses). Sure, modules for other address families can define their own parameters = of routes. They are supposed to be filled in via YANG augments. The core = routing data model only deals with IP. >=20 > 3) Static (and direct) routes for multiple routing tables. >=20 > Figure 2 appears to imply that static and direct routes can only be = inserted in the main routing table. Is it possible to install static = routes in multiple additional routing tables? This is now better explained in revision -05. Direct routes are always = installed in the main routing table but the static pseudo-protocol can = be connected to any table. Routes from any table can be installed in = other routing tables by means of the mechanism of recipient routing = tables and filters (sec. 4.3). Figure 2 is just an example. >=20 >=20 > 4) More attributes for static routes. >=20 > Configured static routes (routes in the pseudo routing-protocol = "static") need more attributes (e.g. metric). This can be done, although the use case for metrics of static routes is = not very clear to me, unless there is a way for redistributing such = routes to other routing protocols. Such parameters can be added via = augments from other (generic or vendor-specific) modules, if necessary. = In the core routing model, we tried to limit the number of parameters to = a reasonable minimum, or otherwise we will never finish this work. >=20 > 5) Add support for routing-instances. >=20 > Allow the creation of multiple routing-instances (also known as VRFs) = per logical-router. Allow interfaces to be assigned to = routing-instances. Allow multiple instances of routing protocols, scoped = by routing-instance. In rev. -05, each router instance has the "type" parameter so that the = same flat list of router instances may contain VRFs as well as = self-contained logical/virtual routers that differ in the type = parameter. New modules defining a particular router type then have to = specify the rules. e.g., whether/how routing tables can be shared among = router instances. >=20 > 6) Ability for a client to subscribe to RIB changes >=20 > It would be very useful for a client to be able to subscribe to route = table changes. (I am not a YANG expert and I don't know if such a thing = is even possible in YANG.) In the subscription, the client could specify = one or more routing tables in which it is interested and filter(s) to = specify which subset of routes it is interested in. This can be done using a NETCONF notification, but again - I am afraid = of feature creep, so I would leave this extension to a separate module. >=20 > 7) More sophisticated filters >=20 > Section 4.5 explicitly says that the core routing data model only = defines a skeleton for filtering. It would be "good" for the working = group to continue this work and define more sophisticated filtering = mechanisms. When we were discussing the current NETMOD charter, I proposed to work = on route filters but I didn't get support for this idea. Anyway, this = should probably be addressed by routing experts - I will be happy to = help. There is now a draft/module on ACLs = (http://tools.ietf.org/html/draft-huang-netmod-acl-01) that goes in this = direction. Thanks, Lada >=20 > -- Bruno >=20 > PS: Cross-post to the Interface to the Routing System (IRS) mailing = list because they are discussing very similar functionality. > _______________________________________________ > irs-discuss mailing list >=20 > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08921F86FB for ; Sun, 28 Oct 2012 22:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ6uNsHt+kmB for ; Sun, 28 Oct 2012 22:15:05 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by ietfa.amsl.com (Postfix) with ESMTP id 163DE21F85DF for ; Sun, 28 Oct 2012 22:15:04 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9T5F3nT023990 for ; Mon, 29 Oct 2012 14:15:03 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q9T5F3Z01176 for irs-discuss@ietf.org; Mon, 29 Oct 2012 14:15:03 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q9T5F2rJ010227 for ; Mon, 29 Oct 2012 14:15:02 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id q9T5F2t8009916 for ; Mon, 29 Oct 2012 14:15:02 +0900 Received: from [127.0.0.1] (osknet452.sys.biglobe.nec.co.jp [10.84.99.49]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id q9T5F2Cl028371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Oct 2012 14:15:02 +0900 Message-ID: <508E10D1.9030706@mesh.ad.jp> Date: Mon, 29 Oct 2012 14:14:57 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: irs-discuss@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9A8E98BAC5C02CC29F9E90DC" Subject: [irs-discuss] coments on draft-keyupate-irs-bgp-usecases-01 X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 05:15:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9A8E98BAC5C02CC29F9E90DC Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: quoted-printable Hi Authors This is a great draft. Exactly what I want in my ISP network. I have a few comments and thoughts. Section2.2 o "Filter prefixes that are not allocated by Internet Routing Registries.= " IRRs do not allocate prefixes. Do you mean filter prefixes not registered on IRRs, or filter prefixes not allocated by IANA/RIR? I would go for the latter. o "This helps avoid prefix hijacking." I would say "This helps avoid prefix hijacking, including unintentional= misconfiguration announcements." o JPIRR, run by JPNIC in coordination with the Japanes operator community= has quite an accurate record because it requires authorization and yearly updates to the data. However, the complexity of the operation has not caught on with other IRRs. Miscellaneous o I didn't see a section in the document that described the situations for a newly configured BGP session. When you configure a new session, you may want to set BGP passive, especially if the neighbor requests MD5 because that would generate messy logs. When the peer does come up though, that passive needs to be deleted. All this could be done through IRS. After the BGP session comes up, and if the neighbor is advertising unexpected address families and timers IRS could send that information to the controller, and the controller could decide whether to shut it down or not. This will mitigate unwanted BGP session flapping. o Many ISPs use peeringdb.com to exchange peering info these days. Would an API to directly query peeringdb be helpful? I guess this is a question that would be nice to discuss among the operators and the people who maintain peeringdb. Regards, Seiichi --------------enig9A8E98BAC5C02CC29F9E90DC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlCOENMACgkQcrhTYfxyMkIxzACfecjTFJH/9FTp95+vxN6Wq6V0 rPEAnjS1fvODLoeioLb63Wvx7ouRdC2Q =ZDay -----END PGP SIGNATURE----- --------------enig9A8E98BAC5C02CC29F9E90DC-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAD021F8646 for ; Fri, 26 Oct 2012 07:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+mlaeiS44F3 for ; Fri, 26 Oct 2012 07:55:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85AFF21F8639 for ; Fri, 26 Oct 2012 07:55:03 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so3354621vcb.31 for ; Fri, 26 Oct 2012 07:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=msntxyU6Kl/q8d+ro5K5EMp/0s/b5W2kqNh2phdCAck=; b=oaEbN9JiibYCJrkrPOx2vEUQHN/jAtDpE2HIIX3Vy2KapBHqsIT5a3mo2vn+5R9fQp rb71uhuU7gtqWKOqn5ulPu+TGrka4ehBJDCN4eqKzyRlXNIyw5emO8IN7m9wYJR7rZVM jI0rElq5fDrquLeWN5K+/yZVGTKAxiaX4NOJK2Bl0CpDdGPnUlCP3TdkICvnfG+XiDkp i5dKfwLgDxCYeSgIg+RWTR4xKZfhSxLV4tAyAw88FmmPujaTciMbH3U8JnP8b7bFtBga NHucmuLPo24Hy/Vmr06xdlwJNxV5dSJRQcN0FIFIYEYG57XpXCbZ2296ZQ8E/7E0PEvV 9Ewg== MIME-Version: 1.0 Received: by 10.52.27.2 with SMTP id p2mr30367486vdg.85.1351263302992; Fri, 26 Oct 2012 07:55:02 -0700 (PDT) Received: by 10.58.163.138 with HTTP; Fri, 26 Oct 2012 07:55:02 -0700 (PDT) In-Reply-To: <5085874F.1090806@riw.us> References: <5085874F.1090806@riw.us> Date: Fri, 26 Oct 2012 07:55:02 -0700 Message-ID: From: Andy Bierman To: Russ White Content-Type: multipart/alternative; boundary=20cf307d00742c44bd04ccf78184 X-Gm-Message-State: ALoCoQmzbsuh7x2c/mb40iC+qzWEDW/GIfhvsi3jUNOMU9OqRG1GkHtl9jY8knb2qimCD4G60CBq Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:55:04 -0000 --20cf307d00742c44bd04ccf78184 Content-Type: text/plain; charset=UTF-8 Hi, This charter text is very puzzling: ..those mechanisms impose many transactional mechanisms and requirements, that may slow down the interaction What are these "slow path" mechanisms that IRS will not need? Andy On Mon, Oct 22, 2012 at 10:50 AM, Russ White wrote: > > I think this has already been brought up on the list once before, but > I'd just like to repeat my concerns on it: > > == > Thus, the IRS is a "fast path" that can be used to program routing and > policy state in a router using operational paradigms familiar to > operators of traditional distributed devices. This differs from the > programmatic "slow state" that is commonly a device's configuration > interface because those mechanisms impose many transactional mechanisms > and requirements, that may slow down the interaction. > == > > Describing the CLI or other existing interfaces as the "slow path," and > the proposed as the "fast path," is problematic. First, it implies that > there is a specific path already available into all control plane > devices, and that single path is "too slow," for some meaning of "too > slow." Second, it implies, from the start, that we need new path, rather > than a possible structure around existing paths that we can use to make > sense of the routing system as a whole. > > I think 2a needs to be better defined so it doesn't overlap with 2c, or > 2c needs to be made a part of 2a in some way (?). > > Thanks! > > Russ > > > > -- > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > --20cf307d00742c44bd04ccf78184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This charter text = is very puzzling:
<= br>
=C2=A0 =C2=A0 =C2=A0..t= hose mechanisms impose many transactional mechanisms
=C2=A0 =C2=A0 and requirements, that= may slow down the interaction

What a= re these "slow path" mechanisms that IRS will not need?

<= br>
Andy


On Mon, Oct 22, 2012 at 10:50 AM, Russ White <russw@riw.us= > wrote:

I think this has already been brought up on the list once before, but
I'd just like to repeat my concerns on it:

=3D=3D
Thus, the IRS is a "fast path" that can be used to program routin= g and
policy state in a router using operational paradigms familiar to
operators of traditional distributed devices. This differs from the
programmatic "slow state" that is commonly a device's configu= ration
interface because those mechanisms impose many transactional mechanisms
and requirements, that may slow down the interaction.
=3D=3D

Describing the CLI or other existing interfaces as the "slow path,&quo= t; and
the proposed as the "fast path," is problematic. First, it implie= s that
there is a specific path already available into all control plane
devices, and that single path is "too slow," for some meaning of = "too
slow." Second, it implies, from the start, that we need new path, rath= er
than a possible structure around existing paths that we can use to make
sense of the routing system as a whole.

I think 2a needs to be better defined so it doesn't overlap with 2c, or=
2c needs to be made a part of 2a in some way (?).

Thanks!

Russ



--
<><
riwhite@verisign.com
russw@riw.us
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

--20cf307d00742c44bd04ccf78184-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956B221F8A25; Mon, 22 Oct 2012 16:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nti5ApaPWoaa; Mon, 22 Oct 2012 16:02:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4B34521F8980; Mon, 22 Oct 2012 16:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3847; q=dns/txt; s=iport; t=1350946925; x=1352156525; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2RAV22I1G9ey5FDQ9bAdoSkbJcoa6i4JZJxE7WugRr4=; b=CswCfRDgKEHrL1GNp9GAd9+quMIuMzBAY+L7iqu7VtnKtVDJMoHWuDWX QR9sFo+lv3Rynn0G+dTE1ZfQePtJnEp5Gadcmt1NwcE3r5fsk4OimrfgT ToFklg9r0Oor1JPvR71gjVRIknaJJspFG5ldkLSDm/1kmJMXy2FUDL67I k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPvOhVCtJXG9/2dsb2JhbABFwT+BCIIgAQEBBAEBAQ8BJzQLEgEIEQMBAgsCEjcLHQgCBAENBQgBEgeHYgucD6Ani1iEFoF5YAOXCIoVgyKBa4JiDYIY X-IronPort-AV: E=Sophos;i="4.80,632,1344211200"; d="scan'208";a="134274859" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 22 Oct 2012 23:02:00 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9MN20qf032303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 23:02:00 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 18:02:00 -0500 From: "Keyur Patel (keyupate)" To: Robert Raszuk , idr wg , "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt Thread-Index: AQHNsKk9FnybAlUImUel5HkFkQ+9Kg== Date: Mon, 22 Oct 2012 23:01:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [128.107.163.173] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--50.073900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Pedro Marques , "David Ward \(wardd\)" , "rjs@rob.sh" , Kireeti Kompella Subject: Re: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:02:09 -0000 Hi Robert, Thanks for the comments. :) Comments inlined #Keyur. On 10/22/12 3:02 PM, "Robert Raszuk" wrote: >Dear authors, > >After reading this document I would like to observe that BGP seems to >not fit to the proposed application. Not that it is BGP fault, but the >service model required for service dissemination and discovery is much >better to be based on publish, subscribe, search primitives rather >then p2mp data base distribution propagation which is the BGP model. #Keyur: BGP has its own Pub sub model through use of RT. You could use it if you like. :) > >Putting gateways between service providers and service consumers is a >nice try to address the end point BGP protocol language barrier, but >it does not address the discovery model. #Keyur: The draft provides a way to have a service discovery. > >While one could argue that services could have attached RTs and >RT-Constrain could be used to push filter to only receive what is >necessary however current industry have already solved this problem in >a much more elegant way by using MAP servers and IF-MAP protocol >between producers and consumers. The database behind the MAP server >can be build in a very robust way (as compared to today's BGP state of >the art). #Keyur: I haven't seen a solution yet and so cant speak for it. ;) However, the draft provides BGP as a transport for service discovery and service advertisement. > >I would recommend for the authors to consider such alternatives and >possibly rewrite the proposal to make it fit the needs of this very >important class of application which is service discovery. #Keyur: Sure. Regards, Keyur > >Best regards, >R. > >---------- Forwarded message ---------- >From: >Date: Mon, Oct 22, 2012 at 11:13 PM >Subject: I-D Action: draft-keyupate-bgp-services-01.txt >To: i-d-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Service Advertisement using BGP > Author(s) : Keyur Patel > Jan Medved > Rex Fernando > Burjiz Pithawala > Filename : draft-keyupate-bgp-services-01.txt > Pages : 12 > Date : 2012-10-22 > >Abstract: > A variety of services, such as NATs, firewalls, or caches, can be > embedded in a service provider network or instantiated in data > centers attached to the network. This document proposes extensions > to BGP that facilitate discovery of such service instances by > interested clients and allows dissemination of service information, > such as services capabilities or capacities, throughout the network > domain. The proposed extensions allow for optimal routing of > requests to service instances that can optimally serve them. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-keyupate-bgp-services > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-keyupate-bgp-services-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-bgp-services-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >irs-discuss mailing list >irs-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA7F11E80E1; Mon, 22 Oct 2012 15:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x8eFoWE9142; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB7D21F84B2; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so2904596iad.31 for ; Mon, 22 Oct 2012 15:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fxgkgk/jXsvC5FWi0Xv/GZqXprgcbo33eWkZPNtOUxM=; b=VNbdfSq4YRM3JH9wMfPF6IlK8KcRuD3qVY6aaGXAuX0Y8xMjieQQXaQrC953lkmzaE MXG8InMjf/Mh0cEu1KNR/muMAv8xnGcy31cvS7UD5VloKWpnTa+4r9yVxQKuQ8KID5jg eT2JURyaO7eVijXSgS86+g7vgQuJXpjp8TtijopA6ehzWNzWMyU1VvzELDvAsYGcr41Z yhSvBjea5c+t73HtZ526JTTIyxKQtzmZKeW5OnoQgQWd+2HMRSYoDp46MfhGmfx4yt76 cDq21G6VxGREoH4VH7rWnncvUFRGd6KmtWog7CPzGiwEuIBM4lQJOa5HJuenSq8mPQ/9 7Pdg== MIME-Version: 1.0 Received: by 10.50.208.71 with SMTP id mc7mr18036576igc.47.1350943371835; Mon, 22 Oct 2012 15:02:51 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 22 Oct 2012 15:02:51 -0700 (PDT) In-Reply-To: <20121022211358.25006.8180.idtracker@ietfa.amsl.com> References: <20121022211358.25006.8180.idtracker@ietfa.amsl.com> Date: Tue, 23 Oct 2012 00:02:51 +0200 X-Google-Sender-Auth: 35S2ueIcE8DBTtXWbA8gQJT6qU8 Message-ID: From: Robert Raszuk To: idr wg , irs-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Pedro Marques , rjs@rob.sh, Kireeti Kompella Subject: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:02:53 -0000 Dear authors, After reading this document I would like to observe that BGP seems to not fit to the proposed application. Not that it is BGP fault, but the service model required for service dissemination and discovery is much better to be based on publish, subscribe, search primitives rather then p2mp data base distribution propagation which is the BGP model. Putting gateways between service providers and service consumers is a nice try to address the end point BGP protocol language barrier, but it does not address the discovery model. While one could argue that services could have attached RTs and RT-Constrain could be used to push filter to only receive what is necessary however current industry have already solved this problem in a much more elegant way by using MAP servers and IF-MAP protocol between producers and consumers. The database behind the MAP server can be build in a very robust way (as compared to today's BGP state of the art). I would recommend for the authors to consider such alternatives and possibly rewrite the proposal to make it fit the needs of this very important class of application which is service discovery. Best regards, R. ---------- Forwarded message ---------- From: Date: Mon, Oct 22, 2012 at 11:13 PM Subject: I-D Action: draft-keyupate-bgp-services-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Service Advertisement using BGP Author(s) : Keyur Patel Jan Medved Rex Fernando Burjiz Pithawala Filename : draft-keyupate-bgp-services-01.txt Pages : 12 Date : 2012-10-22 Abstract: A variety of services, such as NATs, firewalls, or caches, can be embedded in a service provider network or instantiated in data centers attached to the network. This document proposes extensions to BGP that facilitate discovery of such service instances by interested clients and allows dissemination of service information, such as services capabilities or capacities, throughout the network domain. The proposed extensions allow for optimal routing of requests to service instances that can optimally serve them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-keyupate-bgp-services There's also a htmlized version available at: http://tools.ietf.org/html/draft-keyupate-bgp-services-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-keyupate-bgp-services-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F6E21F8A71 for ; Mon, 22 Oct 2012 10:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX-hsPGjRUK4 for ; Mon, 22 Oct 2012 10:57:14 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28921F8A6E for ; Mon, 22 Oct 2012 10:57:14 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4789697iec.31 for ; Mon, 22 Oct 2012 10:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KJ9Ns9K4IvDOTFnFV1xcAmCngF1Ig+6Z31eBDcfnWas=; b=OHhhjTUx84HqqzBmDOCzxwTUF6nLooCpSZrowsb7QHV+j1JbXdQDA6p0n3CjXehRqm wXKHGangmDG8Mi9zk9h4QLD0xZ1LutOT8lUcNTSlU3rdF7IfpOI6kP/e3aB7pZuWhF+J WM7Wj0Hze6EX0mIf7JifR+pfU0wi4DhQ04HqIVWTlSR0Z5KVaFGebEdJxkroBbYRBvwp tKL9GDcAYEcThhTnqGuxMVxPdUqK7pMJSix219ySLhpF0SZz+NwGm8ZTxqm+UxDLn4Oy ZFYMKP6QH6aZ5N/HzLGdzzxLu3ijiYAISUqvDluNuEbyuBrRDVnBe6e02jDLgohgq9ik RiDQ== MIME-Version: 1.0 Received: by 10.50.53.199 with SMTP id d7mr10199048igp.47.1350928633917; Mon, 22 Oct 2012 10:57:13 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.42.68.133 with HTTP; Mon, 22 Oct 2012 10:57:13 -0700 (PDT) In-Reply-To: <5085874F.1090806@riw.us> References: <5085874F.1090806@riw.us> Date: Mon, 22 Oct 2012 19:57:13 +0200 X-Google-Sender-Auth: 8oE4g39Mrbv7pCY83IGTyGh1-o8 Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:57:15 -0000 It may be also worth to document the conflict resolution mechanism when "fast path" contradicts with "slow path" configurations ... r. On Mon, Oct 22, 2012 at 7:50 PM, Russ White wrote: > > I think this has already been brought up on the list once before, but > I'd just like to repeat my concerns on it: > > == > Thus, the IRS is a "fast path" that can be used to program routing and > policy state in a router using operational paradigms familiar to > operators of traditional distributed devices. This differs from the > programmatic "slow state" that is commonly a device's configuration > interface because those mechanisms impose many transactional mechanisms > and requirements, that may slow down the interaction. > == > > Describing the CLI or other existing interfaces as the "slow path," and > the proposed as the "fast path," is problematic. First, it implies that > there is a specific path already available into all control plane > devices, and that single path is "too slow," for some meaning of "too > slow." Second, it implies, from the start, that we need new path, rather > than a possible structure around existing paths that we can use to make > sense of the routing system as a whole. > > I think 2a needs to be better defined so it doesn't overlap with 2c, or > 2c needs to be made a part of 2a in some way (?). > > Thanks! > > Russ > > > > -- > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55B321F84FE for ; Mon, 22 Oct 2012 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pok2ny21UEOd for ; Mon, 22 Oct 2012 10:49:51 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 730E911E80A4 for ; Mon, 22 Oct 2012 10:49:51 -0700 (PDT) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.52]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TQM8M-0001zG-UM for irs-discuss@ietf.org; Mon, 22 Oct 2012 10:49:51 -0700 Message-ID: <5085874F.1090806@riw.us> Date: Mon, 22 Oct 2012 13:50:07 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: irs-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:49:51 -0000 I think this has already been brought up on the list once before, but I'd just like to repeat my concerns on it: == Thus, the IRS is a "fast path" that can be used to program routing and policy state in a router using operational paradigms familiar to operators of traditional distributed devices. This differs from the programmatic "slow state" that is commonly a device's configuration interface because those mechanisms impose many transactional mechanisms and requirements, that may slow down the interaction. == Describing the CLI or other existing interfaces as the "slow path," and the proposed as the "fast path," is problematic. First, it implies that there is a specific path already available into all control plane devices, and that single path is "too slow," for some meaning of "too slow." Second, it implies, from the start, that we need new path, rather than a possible structure around existing paths that we can use to make sense of the routing system as a whole. I think 2a needs to be better defined so it doesn't overlap with 2c, or 2c needs to be made a part of 2a in some way (?). Thanks! Russ -- <>< riwhite@verisign.com russw@riw.us Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B884021F8200 for ; Fri, 19 Oct 2012 07:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0GyEjTJlqwg for ; Fri, 19 Oct 2012 07:13:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34A21F84F1 for ; Fri, 19 Oct 2012 07:13:34 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0E92F2DC448 for ; Fri, 19 Oct 2012 16:13:34 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E90464C060 for ; Fri, 19 Oct 2012 16:13:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 19 Oct 2012 16:13:30 +0200 From: To: "irs-discuss@ietf.org" Date: Fri, 19 Oct 2012 16:13:29 +0200 Thread-Topic: IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile) Thread-Index: Ac2uA+ne/ZisyYd7RFKHWY1NEq/W+Q== Message-ID: <94C682931C08B048B7A8645303FDC9F36E6556BED6@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: JACQUENET Christian OLNC/OLN Subject: [irs-discuss] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile) X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:13:35 -0000 Dear all, =20 I'm sending this message to this list as I received several comments asking= how to position this I-D vs. IRS.=20 I thought it would be useful to have comments and feedback from this list. =20 =20 Abstract: This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP connectivity requirements to be met in the context of delivery of services (e.g. Voice over IP or IP TV) which are to be plugged upon an IP/MPLS infrastructure. The CPP defines the set of IP transfer parameters to be supported by the underlying IP/MPLS transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics such as one-way delay, one-way delay variation are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Having the generic CPP template allows for (1) automating the process of service negotiation and activation, thus accelerating service provisioning, (2) setting the (traffic) objectives of Traffic Engineering functions and service management functions and (3) enriching service and network management systems with 'decision- making' capabilities based on negotiated/offered CPPs. https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-= profile http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profil= e-02 Comments are welcome. Cheers, Med= Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382CA21F8632 for ; Fri, 19 Oct 2012 05:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMXRJ-2Hy2oB for ; Fri, 19 Oct 2012 05:43:30 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id D984F21F861C for ; Fri, 19 Oct 2012 05:43:29 -0700 (PDT) Content-Type: multipart/mixed; boundary="_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_" Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 19 Oct 2012 14:43:25 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 19 Oct 2012 14:43:25 +0200 From: Maglione Roberta To: 'Ross Callon' , "irs-discuss@ietf.org" Date: Fri, 19 Oct 2012 14:43:25 +0200 Thread-Topic: Rough Draft IRS Charter Thread-Index: Ac2tSPIygvX3jYqNR5qAr0uNe7mBvAArX2tQ Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F264@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 MIME-Version: 1.0 Cc: "dward@cisco.com" , Capello Alessandro Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:43:32 -0000 --_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a question on working item 2: "The working group is chartered to work on the following items: 2. Tightly scoped key use cases for operational use of IRS. These use= cases will include at least: a. Interactions with the RIB b. Association of routing policies with routing state c. The ability to extract information about topology from the network " Does this bullet exclude the possibility to use IRS to gather information a= bout network measurements such as available bandwidth on a link, informatio= n related to jitter delay for specific flows etc. ? Thanks, Roberta ________________________________ From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Ross Callon Sent: Thursday, October 18, 2012 5:55 PM To: irs-discuss@ietf.org Cc: Ross Callon; dward@cisco.com Subject: [irs-discuss] Rough Draft IRS Charter Attached (in Word format) is a very rough initial draft charter (for a pote= ntial IRS WG) that the BOF chairs have been discussing with our friendly sp= onsoring routing area AD. Comments are welcome. We will be discussing the draft IRS WG charter in Atl= anta. Thanks, Ross (with input from Dave and Adrian) Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non ? necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 I have a question on working i= tem 2:

 

“The working group is chartered to work on the f= ollowing items:

 

2.       Tightly scop= ed key use cases for operational use of IRS. These use cases will include a= t least:

a.      Interactions with = the RIB

b.      Association of rou= ting policies with routing state

c.      The ability to ext= ract information about topology from the network

“

Does this bullet exclude the possibi= lity to use IRS to gather information about network measurements such as av= ailable bandwidth on a link, information related to jitter delay for specific flows etc. ?

 

Thanks,

Roberta

From: irs-= discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, October 18, = 2012 5:55 PM
To: irs-discuss@ietf.org
Cc: Ross Callon; dward@cisco= .com
Subject: [irs-discuss] Rough= Draft IRS Charter

 

Attached (in Word format) is a very rough initial draf= t charter (for a potential IRS WG) that the BOF chairs have been discussing= with our friendly sponsoring routing area AD.

 

Comments are welcome. We will be discussing the draft = IRS WG charter in Atlanta= .

 

Thanks, Ross

(with input from Dave and Adrian)

 

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non è necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_-- --_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_ Content-Description: logo Ambiente_foglia2.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000003@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8421F8623 for ; Thu, 18 Oct 2012 17:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VJ99upYjVwV for ; Thu, 18 Oct 2012 17:14:18 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id DA69021F8491 for ; Thu, 18 Oct 2012 17:14:18 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.130]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TP0EC-0005Uq-1n for irs-discuss@ietf.org; Thu, 18 Oct 2012 17:14:16 -0700 Message-ID: <50809B5F.9060505@riw.us> Date: Thu, 18 Oct 2012 20:14:23 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: irs-discuss@ietf.org References: <50804686.2010708@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 00:14:19 -0000 >> It seems to me that the second paragraph of the description is misleading >> and unfortunate. The proposed interface is not inherently any faster (or >> slower) than any other existing interface. It may in fact use existing >> protocols and mechanisms. At the same time, the stated goal is to expose >> information and models that are generalizations or synthesized combinations >> of what the devices currently expose. This is unlikely to be meaningfully >> manipulated using the same paradigms that operators currently use. > > Agree Joel. In addition, there can easily be confusion as terms like > "fast path" are more conventionally used to refer to switching paths. +1 It's always easy to say, "this will be faster," but it's going to wind up being far too implementation dependent to be a really meaningful or useful measure. Russ -- <>< riwhite@verisign.com russw@riw.us Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637E121F8466 for ; Thu, 18 Oct 2012 15:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M56gPGj2RjcD for ; Thu, 18 Oct 2012 15:23:40 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D314921F8448 for ; Thu, 18 Oct 2012 15:23:39 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so11027055oag.31 for ; Thu, 18 Oct 2012 15:23:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=T9YKRVdl/18F+xp5oBlxZ6jZwIfJrKLFXRDdI1my5zQ=; b=ZjV9naZJACThX2neteieFQsbk/z0lXrwmxywr8Piok+nPfjVjNfLP5JvBO396CZ9yG d3D2o+Y0gMCxlryuBUWYnUZLI1yoxD76tFQrJE7DgrQt1BrOaJNz50xs22HQLycw83uu 96+ldULQPp7SEiFazf1m9vOrb6KqlOwcYW2MhbtC8+nxXhBHU0J7rA1xX27XXFbYezPe 9biqBggsUa7Mn8SE9wjWOrGV0xR7KeAHx7YIrgzHfqvClsDOcHIWxqR8IfNVNr8xOIoW dumNQCLHtCVkbUsnIRXUOKlCp8cGHtv3XiQ1CcoBR/j/29JzMwe6FJH1YJdV+EuFhO8B WXmA== MIME-Version: 1.0 Received: by 10.60.171.164 with SMTP id av4mr20106273oec.59.1350599019368; Thu, 18 Oct 2012 15:23:39 -0700 (PDT) Received: by 10.76.130.44 with HTTP; Thu, 18 Oct 2012 15:23:39 -0700 (PDT) X-Originating-IP: [144.49.132.3] In-Reply-To: <50804686.2010708@joelhalpern.com> References: <50804686.2010708@joelhalpern.com> Date: Thu, 18 Oct 2012 15:23:39 -0700 Message-ID: From: David Meyer To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnyIlrPMlxMw7gA6m7xAf326ELE92ZMVXI975i35cRQ4iD72sp3WrxkDqWrHhw8bXnx62CK Cc: Ross Callon , "dward@cisco.com" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:23:40 -0000 On Thu, Oct 18, 2012 at 11:12 AM, Joel M. Halpern wrote: > It seems to me that the second paragraph of the description is misleading > and unfortunate. The proposed interface is not inherently any faster (or > slower) than any other existing interface. It may in fact use existing > protocols and mechanisms. At the same time, the stated goal is to expose > information and models that are generalizations or synthesized combinations > of what the devices currently expose. This is unlikely to be meaningfully > manipulated using the same paradigms that operators currently use. Agree Joel. In addition, there can easily be confusion as terms like "fast path" are more conventionally used to refer to switching paths. --dmm Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0721F85F5 for ; Thu, 18 Oct 2012 15:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.186 X-Spam-Level: X-Spam-Status: No, score=-101.186 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEAtbpzXpkpT for ; Thu, 18 Oct 2012 15:07:28 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 58F4121F85DA for ; Thu, 18 Oct 2012 15:07:28 -0700 (PDT) Received: (qmail 5706 invoked by uid 0); 18 Oct 2012 22:07:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 18 Oct 2012 22:07:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=RL5TXUfSUTCXY74L3qzyBfUwwuGpcC0VZiQTLvHDQbk=; b=gk3TvlFCgnQhnZ9WClP58GeZhuGBaPuqlBsd8XvS/x9jYLBMvJimT4hV3N6mmXaPNDVSjrQwIodFzGBppkhnAGtP4M8a9TWOx/i50rSbZOcxnrUl/N5WcDrne++/XT7F; Received: from box313.bluehost.com ([69.89.31.113]:38935 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TOyF8-0001zw-2r; Thu, 18 Oct 2012 16:07:06 -0600 Message-ID: <50807D84.6020909@labn.net> Date: Thu, 18 Oct 2012 18:07:00 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ross Callon , "dward@cisco.com" References: <50804686.2010708@joelhalpern.com> In-Reply-To: <50804686.2010708@joelhalpern.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 22:07:29 -0000 I have to say I agree with Joel on this. Also, an unrelated comment: do you/we want to scope what is meant by "Topology"? For example, is TE/resource information in or out of scope? What about LFIB? TMF.DM-1 of draft-medved-irs-topology-requirements has a long list, are any out of scope? Lou On 10/18/2012 2:12 PM, Joel M. Halpern wrote: > It seems to me that the second paragraph of the description is > misleading and unfortunate. The proposed interface is not inherently > any faster (or slower) than any other existing interface. It may in > fact use existing protocols and mechanisms. At the same time, the > stated goal is to expose information and models that are generalizations > or synthesized combinations of what the devices currently expose. This > is unlikely to be meaningfully manipulated using the same paradigms that > operators currently use. > > Would it still hang together if he paragraph were simply removed? > > Yours, > Joel > > On 10/18/2012 11:55 AM, Ross Callon wrote: >> Attached (in Word format) is a very rough initial draft charter (for a >> potential IRS WG) that the BOF chairs have been discussing with our >> friendly sponsoring routing area AD. >> Comments are welcome. We will be discussing the draft IRS WG charter in >> Atlanta. >> Thanks, Ross >> (with input from Dave and Adrian) >> >> >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >> > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > > > > Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D1021F8475 for ; Thu, 18 Oct 2012 11:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhVvFGF4eJvX for ; Thu, 18 Oct 2012 11:12:28 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63021F8472 for ; Thu, 18 Oct 2012 11:12:28 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 0EC59A3691 for ; Thu, 18 Oct 2012 11:12:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C5CDD1C0469A; Thu, 18 Oct 2012 11:12:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-221.clppva.btas.verizon.net [71.161.51.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 196D91C0468D; Thu, 18 Oct 2012 11:12:25 -0700 (PDT) Message-ID: <50804686.2010708@joelhalpern.com> Date: Thu, 18 Oct 2012 14:12:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ross Callon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dward@cisco.com" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:12:33 -0000 It seems to me that the second paragraph of the description is misleading and unfortunate. The proposed interface is not inherently any faster (or slower) than any other existing interface. It may in fact use existing protocols and mechanisms. At the same time, the stated goal is to expose information and models that are generalizations or synthesized combinations of what the devices currently expose. This is unlikely to be meaningfully manipulated using the same paradigms that operators currently use. Would it still hang together if he paragraph were simply removed? Yours, Joel On 10/18/2012 11:55 AM, Ross Callon wrote: > Attached (in Word format) is a very rough initial draft charter (for a > potential IRS WG) that the BOF chairs have been discussing with our > friendly sponsoring routing area AD. > Comments are welcome. We will be discussing the draft IRS WG charter in > Atlanta. > Thanks, Ross > (with input from Dave and Adrian) > > > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0380021F852B for ; Thu, 18 Oct 2012 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pslEiLn9s1K5 for ; Thu, 18 Oct 2012 08:55:35 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4E21F87E3 for ; Thu, 18 Oct 2012 08:55:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUIAmcDlv65Hd+zOcKorJQGApZzD9qWbR@postini.com; Thu, 18 Oct 2012 08:55:29 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 18 Oct 2012 08:55:11 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 18 Oct 2012 08:55:10 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 18 Oct 2012 11:55:09 -0400 From: Ross Callon To: "irs-discuss@ietf.org" Date: Thu, 18 Oct 2012 11:55:07 -0400 Thread-Topic: Rough Draft IRS Charter Thread-Index: Ac2tSPIygvX3jYqNR5qAr0uNe7mBvA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_" MIME-Version: 1.0 Cc: Ross Callon , "dward@cisco.com" Subject: [irs-discuss] Rough Draft IRS Charter X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:55:36 -0000 --_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_ Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_" --_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached (in Word format) is a very rough initial draft charter (for a pote= ntial IRS WG) that the BOF chairs have been discussing with our friendly sp= onsoring routing area AD. Comments are welcome. We will be discussing the draft IRS WG charter in Atl= anta. Thanks, Ross (with input from Dave and Adrian) --_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Attached (in Word format) is a very rough initial draft charter (for a= potential IRS WG) that the BOF chairs have been discussing with our friend= ly sponsoring routing area AD.
 
Comments are welcome. We will be discussing the draft IRS WG charter i= n Atlanta.
 
Thanks, Ross
(with input from Dave and Adrian)
 
 
 
 --_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_-- --_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="First-draft-IRS-charter.docx" Content-Description: First-draft-IRS-charter.docx Content-Disposition: attachment; filename="First-draft-IRS-charter.docx"; size=18072; creation-date="Thu, 18 Oct 2012 15:50:01 GMT"; modification-date="Thu, 18 Oct 2012 15:50:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQABLhqfkwEAABMGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lF1PwjAUhu9N/A9Lb81W8MIYw+BC8VJJxHhdujNoXD/SU77+vWcDFhXYiODNkq497/v09G17g5Uu ogV4VNakrJt0WARG2kyZacrex8/xPYswCJOJwhpI2RqQDfrXV73x2gFGVG0wZbMQ3APnKGegBSbW gaGZ3HotAg39lDshP8UU+G2nc8elNQFMiEOpwfq9J8jFvAjRcEW/NyQeCmTR42Zh6ZUy4VyhpAhE yhcm++USbx0SqqzW4Ew5vCEMxg86lDPHDbZ1r9QarzKIRsKHF6EJgy+tz3hm5VzTHpJmmQOcNs+V hLq+VHPeSkCknusiqWe0UGbHf5TDzPUEPFVeHqSWboXAsC4AL0+w0W2yp2aNvHXIKRxn+0MZvwyy mM7DgQ8K6vwc7f8G8UOF2TDPQVLa2wOhMS5PPdmrbdpplTqEEOisTzH5eQfjttTtlFsRAl1x4NW3 e8JemzEqmVbLnF6BsZgUcLbf3mWrpVshljB5+7fufxNvAqnTLq3/QzN2L2RZfSDjvHrS+18AAAD/ /wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNB DIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg 2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJ U4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop 9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7Mv aD4BAAD//wMAUEsDBBQABgAIAAAAIQCuo9dMMgEAAD4EAAAcAAgBd29yZC9fcmVscy9kb2N1bWVu dC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTwU7DMAyG70i8 Q5U7TTtgQ2jtLoC0KwxxTlOnrWiSKvaAvT2haFsLXeHQSyTbyv9/duLl6kPXwRs4rKxJWBxGLAAj bV6ZImHPm4eLGxYgCZOL2hpI2A6QrdLzs+Uj1IL8JSyrBgOvYjBhJVFzyznKErTA0DZgfEVZpwX5 0BW8EfJVFMBnUTTnrqvB0p5msM4T5tb5JQs2u8Y7/61tlaok3Fm51WBowIIjEPnO0GsKVwAlbJ8J PSfjwwiLEwi6ks6iVRRKq/m3+5frot8YR9rVgC8VlfdKgaSu/c/SGMfsBMfAmP8xita5M4g2HrOP p7Q3W52B829xJDikxiDmU0KQ/6ZwBGhD3p7xGMP1lAzKGtqIrO5wHFJjEFdTQrxD9vRrNTrJPQjv bX36CQAA//8DAFBLAwQUAAYACAAAACEAhV0T0BYRAAA5bAAAEQAAAHdvcmQvZG9jdW1lbnQueG1s 7Fxbc+JGFn7fqv0PXTxkk6qxwfcxiUmMsadctdlMebyVZyE1oB3dVmpM2F+/3+luCTWWRIOYjMdx HuIaJNTd53znO1fx089/hAF74mnmx9FV5+iw12E8cmPPj6ZXnX8/3h2877BMOJHnBHHErzpLnnV+ Hvz9bz8t+l7szkMeCYZHRFn/CVdnQiT9bjdzZzx0ssM44REuTuI0dAT+mU67oZN+nicHbhwmjvDH fuCLZfe41zvv6MfEV515GvX1Iw5C303jLJ4I+ko/nkx8l+s/+TdSm3XVN0d6y3LFbsoD7CGOspmf ZPnTwl2fhiPO8oc8NR3iKQzy+xaJzWpe6iygjzBQ217EqZekscuzDJ+O1MXiiUe9prW1AOkRxTds tmCume8kdPyoeAyhY03/hfIOobyuWrtLj1odBLIYAEvj2FvS34Qt+sCi93DV6fVGZ72LcwBSf/QR iu71Lu+Oj0anxYcjPnHmgXh++8fSR/LJH1P6k6o/2f/w1CcnuOoc9zrdwU9dfQV/E31j5bIWj1j0 xeD3OP0M3bAPaTxP2L+ckPdpCaEWkv9P2h735Obo/fVdLojWx7U7mTPWwpK35yIqiTr/yFCW3bMH 95Hg6cQBsJmImZhx9hDPBcnx0zITPGTf3z98+mHvgjRh1k6QhJ+2it3nfgDrVhq5fbxj1yl33uDb zBtk2zlYSV6bQXp+dNo7OcvN98Gwl1xlJXIzb38DacHkYnAzc/z0++yHN4xuxujjcLQZmiYBbYSm eXs7aLbkq7IJspGfclfEb9DYHPYQfV17qe9E7M5JERez7wLxoyM/+SUOPC+eIoQ7nH/+bip+/MsA 6Np78rM43Z5XSrz9+qK0PeLk5uz05HjlA7+22Aa/JTxVGaEMepg9AEw1b6RM8/bWlGkXX8vYnSz9 pTuBVxZE/+qgyoEk5p9+JrLtyWRTZPhy3C9VcPpZggTuqpOkPOPpE+8MmP7vA49gXQHccubOUbqI oz7z0+zAU//+xediQiWivbuXs2Hv+qhgmdbGlgfnhl7sLLBZQI8x+zQfZ27qj3mfGWIohUV7yrWp UpOhVLdYLA5zyaM45wehE3UDINWPJnG3pB9jP/uw0G9FLdepO/Of1go4awq5OT+/Ga6KUvuDhiH1 tUVNwzd9jh0eB7pet1jUrbPDSQZrgDpwlAC7Cz6WgKpbi5C9Vt3bZXmv6fl7kJmiq647R5wcCWkz ZC+HMxEGxtL7MBJzv+2466XtpwTnXfQ84kSVCRXwWTxhRsnVwsuaBRXTenKKLwWk5u1fQBGX78+u b2+LelBp6YpgUd8sK426XN2c+5Pu9Y121FDtqq4ZCtqyIpupiqyfMScIWJyyxEkF6cEpbom4QK3/ M8vm7ow5uDFifl7hfdfo3y7PT26O72RjIG0+F8LZ6p06zI2DAPm/hkexcvZOb5Gn72jf6zfSAdEO O2SNOzTt0kSPnYB3qXbDYuweXi0Thto6NdwcwQ2iameINWuhCBocCD/kJGT+RH1ClBPwV4HAUZpZ +GImK/0mruq2J13ENuAYHLLHGSJRQmm8wNKqFwlQvGNJHPiuzwkQkcfQq1S5H0JUYBktG4JB40aU xbbSCPocY45t/QdI5R6JJpa7SblIfUjNa0Th5fnZ8c37VnbyPQwTqsL5UxbFwkd/VWbAPzQv3P7o kzQOKzTPFjM/4NiSQG+RsqY6DeziMjxHkLlHGfw1utxLKWo3nnF4cndZt5IEXfsDM4c62Whtoa+l SUapWjMqsJk6mUjnrpinXIFyDArlMJkQLU4/gVwkjSnbydiWxrOLxA4NoVRGEKZ7evhyjiv3yjuc o4ajTHBVnq7eLZtXZETw5d3y4HE2B2ERhtALZeR+WWcC2ICzaPxAzBzBXHhasMo8A32ATzArMAWf FX6Z2E5y35ImOwSBqnCJ+BIZ3ToZev40zOA+QrgPJ6WHqjviNCOfL1LH88nTgjuRzoO6xnCiHvP4 E8Y14EsfZ9ip508moFRWWL7eGAYnfJd1MiJouSF9DHwFYwNhHAUwVP2sf9Bn0cSfzhVZK4OgnjFO 7Do4MkQQ4/8hd2dO5GfYth8m8hMnWtJOo0zZD/ZauomEkvL/ztEzoJmWZuLfhnYHpC0oJXQgbjqi Fy8iqcCSLRtWZu3lBxbWaaK0bJ3mlXb4tTEdw2xzWy6xxT73Yy9CRAfSkihSJeRPQc0YQsG/5BAC EMyDOAH+QM4hl/EsQUXmtAJOG1St9LvwEQfzyBmDpbOEu+RJyQRhjRnfJ5x2w0oNA9JZAnL/Mu5g 88iDhdK4l2QBWDbEUwqayGZijwcUzJv2whBYFZNj6jLMW8SIwjMTpqVoU9ayekej4U2rGIZ9CikJ oS0teBAcZC7YyVsJH9riJtWv7WGrOGqArBOEBVFAZhRMgFPAoCQpubAkRPxjhRXUjwAj5EE0veZT JDzBHBqIECKjr5nYw1MhYUTKKWVONOU1mQfBslGIp++PLi5O2glxHVe5iZKSznon16Nzy+cjs4GA IB8pAQpStHjMc0qDgZsK/NAnZ4Fz63sdRk4IduR4IYJAErCAPMCcNHBmCqKSedaysxLJmFf+1DS+ gt/0biiDyLPz5nSXTrtVGo94YR1f5FZnSNYR9CqhU46OGgohcYKcOaZZQwaVhDbNCvNUG/zLzuet 1PLa0rl/Oe8hJcrBW1K9ebvyd3fy5pL8k09iCeDp2UDq2HxELojwKZnRmOCiH81DpQA/eALC1Qyh HCGU1+5BQXquUI8Vrr5A9NQP+ATDiicYa5SP21DeKOkb35WDkcYx7XLPgSxh596KaHLlzIiDEEk2 Gf9t72x42bM0/ho/40duMJdORaZf8DIyy2xadjtSbvSw+zgBwlwdNJMAM476L0aXjQPYoHRbQFoC ZMulR8rpakx9c7ZgCftHfzoTSB50PPDZUNZ6CKCooI2V8WUp5CC7KmdRFAkCQhtMrXdzPByeWZpa Udsqokw4UMRBytbgPQWFdpmwKIbrdfPTl0BqXpFIKW1SO6PdWPOoYNQG1rTEP7RpCYp7KkE/q6A8 3A8NdFTakymLsq+rsKdvW0rXWRa7vuRoFhuSWbOb0jE3qIomTyZFESIvvq4/206LNV5GFsSKSvKz OnelUk3VvWqlUizoqFduKNrmfyCwdkU5v8NlVCNxEeqJp8tVqUb3cta1lROGqsu3LkYfsntZCaee DXlZF5XpvIFT7ElyXONGbs5HN5eWJFqNJFTC95cwVi+BzCcPhRCHowrfdKTe8cXJebskWXbfVF7W tNJ2UZfM8ChVsEjK1thTxbFrH27rePx2MbUd2Qx+Q2qUlnw7lfKgPseLE0pcxygrPsuyVNVyAl/D UDTlmcDbcxmbOUhjx1TRdzxPpV/0VZ2PoYY75RaSvDRjlZLQzCs1cd0GniaWpBSnki3NBcpsaV6p WXq3QOHFp1djKlGsMamqk62bmh3iqhlD8QV1rsSq9VPEfsZKX0V3bYyxcsM6bcudTAnn5pVvDmxW KAgQuj9wKshy7yOIYQhn+FkWDfCqUalTIcuI1Awq6q3Sd+Zv8bLAiaZzfN/MkNsLvJRU26YBe0eI SToPRm3kLwobvMhBwZMTLNHlppST/4EqFpX07ullPgqrYunPNsGFOVNUW9FZJA9Vbo3ZeKjaYaaK Ktyeq4K1zrGCNHZe2jrfrKbyx2fxAnRFQaeeKkTRwqjR5m2oQmfvil7Lyr7lOJMccVC+R46+sHhM syVUPqdGLfVhZdDGJ6hQIPaXXS688kM3UOtYNlz1G/+pV/QoUL2QFeF3DJ1dQgQ+MDxOm7SwWkZy Pdm68Th+R8Ajt6fL1BDDFPPlqvcMUSI38N0MnQQ4x+aJGZ3tWRGwGCAbeqodlaKc5/2oNzw+tUw1 UK/5nWrtuu2Ti7RJjFttt1qMqiaksg0PsyUQkGzHaCAQMaieZylixQwfP9AAbJ7Uux2eDI+GtgIA +XS/8HFRdtPhuUuoxmkpoaUJB5gXhfHrTSjMnxXtWmAqoekgnSNrRRWOVU6y6R/HKMzu0LSDSr9q kl7hpup+yMC8XUY3OxNV5X7003IPmbvNuv2Yt7fbT4knjGUtLfJD7Ojm869FVmVR3zRPsFEB5u3t DvzKFEDvheL9MXoP1JR7SbHEjL3j09OLkSUxyDfTIChknWuP2QMBUqyM/Jsl8zHmPYt6EuohdVS0 CzDvV5Ol6HznP41TtwJJaA9Hw6DARE1JUowGr4jhk1DNUNEQk7H6Gw431D1Qn361OJRAMeCwZmfm y1gmQVpSs5zWJRwas1FFp9lYvRKMmjJsvZJ5uyTpEunkYxLW8xSVy1oevYkU7R4hkVf7MsOfQmHV 4WM1r62IZ6rf6jTUmzN5s/Drj3s/PBhjaq4+lN+FobeolJnQMq0hx0mpGmXe/oZEw4vvoioC3W6A GtAvzelB5Pzn6QonqeY3DuTPvvHa1wR32HC16aw6BsZZ3rhPT0Zpf6y8bj0ZfMXwbUVzRfdxCxYx s4iNLGLe3i7pKHn3HeA8aPJnOf/tFuS/WDUbJloSHx1zD8GREaXLqWijpGqs/gIJwi6IacSN3SNe QByE8WUUfirdiKGmlkGOQsSzLs1ek9Jy1d7Y+wuEWM4r++ar7XAnO2tV1QL2Sf4ILpXEH9HrrZ0l 3GH7NdFDXkMonJChwZboY+YvFJYIb38HaJcaDPyVGaqXTozz2yD4tYfoLxmsz3jMzg4Hckyp4F+l eOqYGMr/InBdX8Fyw5gcPTC+aoNMw8hy5vtycLU7ilH9QjExntym6Jf0xTLBDzrRK6TgwFToFxfs njmQebwhH4wXVT37NvK2enINa64tRfs3XpuQPQ7LvW8R65+eXJyeXVS9dvIaiwP/BwAA///kV8tu 4jAU/RUri+6qBgiP0hJppqFSFyMh4AdM4oRogp2xHSjz9XPtYBpToG6pVFWzICR24vs4514fy3BK /lRESFRWiyKPsczZ/c1mKEN15eE9XBD8RJ5MR57vB51+0O17enyip8VfmF/jYuS1fe+m/qyekSFF LEUYzSSmCeaJQHOO498O6xuTE66M3j62W1HgaBQ9r4qhKHFMRl7JiSB8TbwQJSyuVoRKlJA0pznN kIMbjmFiinKaMr5S2aNoxRJSIHg+tOC23IkArMUAm1KtVppEqTT57SDoR54ZsnJnBiOS4qqQDSh3 M5PGCnrlGkN+HmTlx+5Ft+DwYkcRbYMzlo65IpjcloBXxvEKyMKlItIB83bRuZkJSwZk3l5zUmBJ Eit34PIxu2OanLZq0mfl1M2VE3BWgqAYCyIs347iuqs540MDQhvxiyE0Fj4QZXhVyLv5z+gqk3dD KyTTRc4TCRigqQH/xxP2uk3RT6zg/6FNHc/rqd5lJ/coL232TS3WGCo1yGrT+GKyulXfxf3GBGJF 52Y7lAzaEMu2B/XwzdrPYOxHfme/rTQQtWc0olHX7/d8vVWbjeF84b97B/mSTqP6w+l+8xFuPL0I Blzs1ckBU7TAemMLPtkxEfBsnSdK6oDvmOJiK3KhFBl5zoVU40/j+SPMJA7FbmM9/WoWvK+uHeuV ySU5FG1vFKvbysdbrwJIspgVQmNAaMw0WgWmWYUzAsMZziloc/ALcdDpOSdKwzpoht5tqxf5+6K1 GGpaWgPDhqz/rmX7wCgcUgiHRF3HS9CQhL9S+WYbEySWEyU79+cah3zN4CMlkjsPQevHbd3ispk6 /WxGXqvdDnS6l3DfHcC9VrBl9gtrectKGA/qV3ieLWGl1sDXXyyYlGz1Ml2QtDG7JBiCGnl9OF2B qZQxCGz/mFVSP+7MaS5tzOlHfVKr7TpefTZbsGSrb8yBKPwHAAD//wMAUEsDBBQABgAIAAAAIQCd XIu+EAcAAIcdAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPbxtFFL8j8R1Ge28TJ06aRHWq 2LEJtGmj2C3qcbw79k4zu7OaGSfxDbVHJCREQRyoxI0DAiq1EpfyaQJFUKR+Bd7M7K534nHjlAAV NIfWO/t7b977vT/zZ69eO04YOiRCUp42gtrlxQCRNOQRTYeN4Havc2ktQFLhNMKMp6QRjIkMrm2+ +85VvKFikhAE8qncwI0gVirbWFiQIQxjeZlnJIV3Ay4SrOBRDBcigY9Ab8IWlhYXVxcSTNMApTgB tbcGAxoS1NMqg81CeZvBY6qkHgiZ6GrVxJEw2OigphFyLFtMoEPMGgHME/GjHjlWAWJYKnjRCBbN X7CweXUBb+RCTM2Qrch1zF8ulwtEB0tmTjHsl5PWOvX1K9ulfgNgahrXbrdb7VqpzwBwGIKn1paq znpnrdYsdFZA9ue07tbiymLdxVf0L0/ZvN5sNlfWc1usUgOyP+tT+LXF1frWkoM3IItfmcLXm1ut 1qqDNyCLX53Cd66sr9ZdvAHFjKYHU2gd0E4n115CBpzteOFrAF9bzOETFGRDmV16igFP1axcS/A9 LjoA0ECGFU2RGmdkgEPI4hZmtC+ongBvEFx5Y4dCOTWk50IyFDRTjeCDDENFTPS9fPbdy2dP0Mn9 pyf3fzx58ODk/g9WkSO1g9NhVerFN5/+8egj9PuTr188/NyPl1X8L99//PNPn/mBUD4Tc55/8fjX p4+ff/nJb98+9MC3BO5X4T2aEIlukiO0zxNwzLDiWk764nwSvRjTqsRWOpQ4xXoWj/62ih30zTFm 2INrEpfBOwLahw/43uieY3A3FiOVx9vx7HqcOMBdzlmTCy8L1/VcFZp7o3Ton1yMqrh9jA99c7dw 6sS3Pcqgb1KfylZMHDP3GE4VHpKUKKTf8QNCPHzdpdThdZeGgks+UOguRU1MvZT0aN/JponQDk0g LmOfgRBvh5vdO6jJmc/rbXLoIqEqMPMY3yPMofE9PFI48ans4YRVCb+BVewzsjsWYRXXlgoiPSSM o3ZEpPTJ3BLgbyXo16F1+MO+y8aJixSKHvh03sCcV5Hb/KAV4yTzYbs0javY9+UBpChGe1z54Lvc rRD9DHHA6cxw36HECffZ3eA2HTomTRJEvxkJHUto1U4HTmj6qnacQDfO3bm4dgwN8PlXjzyZ9aY2 4i0gwVcJO6fa7yzc6abb4iKib37P3cajdI9Amk8vPG9b7tuWG/znW+6sep630U56K7Rdvb2xm2Kz RU5m7pAHlLGuGjNyQ5pNsoR1IurAoJYzp0NSnpiyGH7mfd3BDQU2Mkhw9SFVcTfGGWywa4FWMpS5 6qFEGZdwsDPDXt0aD5t0ZY+FK/rAYPuBxGqXR3Z4WQ8X54JSjVlthubwWUy0rBXMO9nylVwpuP06 k9W0UXPPVjOmmVbnzFa6DDGcdg0GSzZhA4Jg2wIsr8L5XE8NBxPMSKR5t2tvERYThb8nRLnX1pEY R8SGyBmusFkzsStSyFwQQEp5Qnc+NkvWgLSzjTBpMTt/5iS5UDAhWZfdqWpiabW2WIqOGsH6ytJK gEKcNYIBHEnhZ5JB0KTesmE2hHudUAmbtWfWoinSicfr/qyqwS3DjIJxyjgTUm1jGdsYmld5qFiq Z7L2L63UdbJdjAM2UV/DiuU1SJF/zQoItRtaMhiQUFWDXRnR3NnHvBPykSKiG0dHqM9GYh9D+IFT 7U9EJdwsmILWD3ANptk2r9zemnea6uWTwdlxzLIY591SX6MUFWfhpt5KG8xTxTzwzWu7ce78ruiK vyhXqmn8P3NFLwdw0F+OdARCuIUVGOl6bQRcqJhDF8piGnYErPumd0C2wFUqvAby4S7Y/C/Iof7f 1pzVYcoazmtqnw6RoLCcqFgQsgdtyWTfGcpq+dJjVbJckcmoirkys2b3ySFhPd0DV3UPDlAMqW66 Sd4GDO50/rnPeQX1h3qPUq03p4eUS6etgX9642KLGZw6tZfQ+VvwX5roWf2svBEv1siqI/rFZJdU L6rCWfzW1/OpXtOEeRbgylprO9aUx0srhXEQxWmPYbDcz2RwXYP0P7D+UREy+2FBL6g9vg+9FcF3 Assfgqy+pLsaZJBukPZXH/Y9dtAmk1Zlqc13Ppq1YrG+4I1qOe8psrVl88T7nGSXmyh3OqcWL5Ls nGGHazs2k2qI7OkShaFBcQ4xgTFfpKofjXj/HgR6G67nR8x+RpIZPJk6yPaEya4+j8b5Tybtgmuz Tp9hNJKl+2SAaHRcnD9KJmwJ2U8ZxRbZoLWYTrRScNl3aHAFc7wWtatlKbx0tnApYWaGll0Kmxsy nwL4kJU3bn20A7xtstZrXVwFUyz9K5TNYbyfMu/JZ17K7EHxlYF6DcrU8aspy5kC8qYTDz5FCgxH k67pv7Do2Ew3Kbv5JwAAAP//AwBQSwMEFAAGAAgAAAAhAEGAYpq9BAAABA0AABEAAAB3b3JkL3Nl dHRpbmdzLnhtbJxX23LbNhB970z/QcPn2gLvEidyhjclaZ3WE8WZvkIkJGFMEBwAsqx8fRe8RLaz TTN9ErhnbzgLEkdv3j6JZvbIlOayXTnuNXFmrK1kzdv9yrn/vL5aODNtaFvTRrZs5ZyZdt7e/PrL m1OimTHgpmeQotWJXDlH1Sa6OjBB9ZXglZJa7sxVJUUidztesfHHGSPUyjkY0yXz+Rh0LTvWQrad VIIafS3Vfj5EFrI6CtaauUdINFesoQYa1gfe6Smb+L/ZoNRhSvL4o008imbyO7nkR57jdk9S1d8i fqY9G9ApWTGtgVnRDNsVlLdTGt38TJ6Bz1u+VVSdnyW5gbF9lVLMTknHVAWEwsy90JlbgIktqzdn bZhYy9bo3gjdyN3GUMMgRnesafqTUTWMQk+nZK+oEBQmOVj6mJrt6LExn+l2Y2QHTo8Uuo49MtSp ue4aen4vFf8KdWhTKHqCrO8Ur0s4iucp4qX/F6YMr/7bW/4pzb1mH6na81avpXqW/i/Fwdg32cq7 Y1uZY3+Q/mCqhQ56oDpQRSvD1KajFRhz6FHJZmqqtvlzKToFQxo3ZE1faMNroCndw7S02fSvwUCH hQt4KVQF+IcW2OD13zBcSzq8HB01dnXUbF3e0rM8GkDmzyF4O2ttfezik5RmaoaQIiRxNBJl0QtC 3DgNyqHDV4gXBHGBI7Ef5SjikzJOUST3smw8Qq/q5FE4Df0Vsg7dBRrjRl7qB1gdL4zy3EORiBA/ whF36cUoUsYLssQQP3BLz8WRyC3QOn4cxAu0az/1ggLPlruLdI3WyQM3RXsLoFCI7idYuHHsY9kC 4NNFJxfkflAs0JgyXATofELipzgHYUZSF42JSAQgVidyA+LjMUs3KtCY2A9iH+UtjkmITy4uvChE JxeXsRegjC4KknnoTBclKQjK9TLycw/tbQmvQo5yvVyEaVli7CzzqMjRc7Bce26B9rZcRwSvk3ph 4GVYnTR2wxxFstINffTs5ISEEcpo7vvxEu06DwN/umxefg/yKMozdD8FcYsM/SL9+5evSCMf/yYW eRhnBcZBScJsiZ63Mgwi/PSWcRgX6NkpMz9zUUbXLgESsA7WJRzs/l2Ab7+lB774IrHi5E5NK3sv z8Rwn+ZUbBWns49WvsCNIZKtesh4O+FbBjKKPUc2x+0EXl0NgBa0adZw300AKJcBsbd0wXbf2Zvh Yp3sPWUiUagVhMDv3zJbtcHUOyWP3VDhpGj3ie8P9roTCW/NLRdTWn3cbia/FjQMCs0v9JwSA7KT WX5uabufbkHWXt1vbDW4TRvV38kgDLoOrnVw2e7dldPYDlwrZQw81VQ99A/bvTdiXo/Bk8X6B1rZ vYD3uLAOwxK8xsXF5k82/2ILJltwsYWTLbzYoskWWdvhDKIN9NcDSMBpae072TTyxOr3k3HlfGca SOjFS3o0chIwdxwkECiZniJ9oB2DmVvxBodPJr1hVHN69piwJ9CLrOYG/hN0vBb0aeV4JOzPwOgN wg4EzAtfm8k6dy+sMxBLFNSnbWz+IrgXP696OSV962UvUUFJgbjcD03XrOJwiDdnsb2ItOthuw0H IcY60HNGKiCq16G/9RUvf19u/gEAAP//AwBQSwMEFAAGAAgAAAAhALm+ds+zAAAA+gAAABQAAAB3 b3JkL3dlYlNldHRpbmdzLnhtbIzOsQrCMBDG8V3wHcrtmuogUtq6iG4iqA8Q06sNJHclF42+vQFd 3ByP7/jxrzdP74oHBrFMDSzmJRRIhjtLtwYu591sDYVETZ12TNjACwU27XRSpyrh9YQx5k8pskJS hQaGGMdKKTEDei1zHpHy1nPwOuYz3BT3vTW4ZXP3SFEty3KlAjodc4EMdhT4aukfLXHoxsAGRXKI dx/Pa0vQ5kbtHKfjYa/aWv0Ut28AAAD//wMAUEsDBBQABgAIAAAAIQD3a702kgcAAKE7AAAPAAAA d29yZC9zdHlsZXMueG1stJttU9s4EMff38x9B4/fc3miSWGadiiUg5s+0AbmXiu2QnQ4ds5WCtyn P2llK44dxbux2zcltqT/rnb1kwjadx9eVpH3k6eZSOKpP/ij73s8DpJQxI9T/+H++uSt72WSxSGL kphP/Vee+R/e//7bu+fzTL5GPPPUAHF2nk79pZTr814vC5Z8xbI/kjWP1btFkq6YVB/Tx16yWIiA XyXBZsVj2Rv2++NeyiMmlXi2FOvMz0d7xoz2nKThOk0CnmXK2lVkxlsxEfvvlXlhElzxBdtEMtMf 07s0/5h/gv+uk1hm3vM5ywIh7pXhysWViJP05iLOhK/ecJbJi0yw8stP+TP9fqkbll/ankEmSwN+ FKHwe1o0YvGj6viTRVOfxycPs7LM1P+Hnfx1px/NVY+pz9KT2YXu2AMfiv9LvqytZ6ZVxXE1vWqy ZyZYalr44nMSPPFwJtWLqa8CDg8fbu9SkaRCvk79s7P84YyvxI0IQ65zo2gYL0XI/17y+CHj4fb5 92uIdD5ikGxiOfWH4wkEI8rCTy8BX+tIK72Y6Yn+qjtEetispAMGbcTWGvOgogoP/y0kB/nM7lNZ cqaz2QP7DwqB15vWQkPtUdkBGJdk66j9EKfth3jTfohx+yEm7YdQDGsbEZMbpazEB1UmgUm+ck6M zg6krO5Ry6LGHrWkaexRy5HGHrWUaOxRy4DGHrWAN/aoxbexRy2cB3sEDMBVzaIRzAZqYd8LGXHd /yCABi1Rl28K3h1L2WPK1ktP729Vsw/BcraZS5ypgNPjYTmTaRI/Ns7I0CyDo5n8abVeskyog0XD 1A9bTv09m0fc+zMVYaPUG5N8NZ/M4WDfFnYXsYAvkyjkqXfPX0xECf2/Jt5szQK1C9ZzQZOxNpR6 iErrz+JxKb3ZEnbYRsfHjjl2O27G/ywycPng2hk7ErJpcFTIxo40dA/+hYdisyqmBnH4GBt810KB lgATD0/RKYSfLqEDgHHB7A5Hjo+w3+wl9PF1jDH2m53nyPER9pt96sjxIT8Ox5cMliuWPnmo5TUh r93LJErSxSYq1kAjHibkFWwlcC6QF7EdHwWJCXkF7+DTuwgC9YsaJk/JsdhylKBCDodRgcWG94Uc lCpZCR6RA1TRGhK02rGWIESG7g/+U+ive6ibAewC9mjZuJxHjhnAni2+bxLZfGQeOpiHVbmN1bcj GfdwaiPHysOq5fkEM0lJpnYbHyGZ2u2ABKF2WyFByJEf7mOV3RPxIu03R4IWGct2F4O0Q5N5Qiaz FaJtAR3tm4jzl2P1unOhvm8iVMgBqu+bCBVydCp72aBIOYRWZ/smQsuxa7hjVGYqxSnyvlkWsvBG eNQNvBFC3cAbIdQNvBFC7eHdLNIdvBFaZDZYppbhjRCCJvUvdtzLyAqV4Y0QIrPB0C7/zqiAEIxy +JfbDuCNUCEHqA5vhAo5Oi54I7SgCSUTKloWdQitbuCNEOoG3gihbuCNEOoG3gihbuCNEGoP72aR 7uCN0CKzwTK1DG+EEBkPVqgMb4QQNKGwYS+8YdX/cngjVMgBqsMboUKOTgWo9pCK0CIHqKJl4Y3Q giaUZMi1ILkpTnUDb4RH3cAbIdQNvBFC3cAbIdQe3s0i3cEboUVmg2VqGd4IITIerFAZ3gghMhv2 whsW4y+HN0KFHKA6vBEq5OhUgGo5h9AiB6iiZeGN0IJ8aQ1vhBA0OVaI4lE38EZ41A28EULdwBsh 1B7ezSLdwRuhRWaDZWoZ3gghMh6sUBneCCEyG/bCG9bIL4c3QoUcoDq8ESrk6FSAauGN0CIHqKJl UYfQ6gbeCCFIzNbwRghBkyOEYBVRwtQNvBEedQNvhFB7eDeLdAdvhBaZDZapZXgjhMh4sEJleCOE yGzQ12rV9VD0bdSBIwmw9wyKWw1owaEjSFjB3MEffMFTVT/Em2+HtBQsPCQoOtID6+LHJHnycPe4 R44EQUuJeSQSuMH9Crd0SnUHo8mBwoH7b5fejal3qfWDlNq91atKisrVQbo4CYq6lJ3yda0qdNbF RXI9mqoc0tVUecUPNLxV9T95FY/urMt6VEOobMofwx+cclX4WVWahUWbfn90eTq4yEshVIUWWPBf 8Xp4Wql7As26lcFSmRlInh6wMr8ab68vwcX4qs2O+/Ng97Z4ozAvv0e/PX6ZdjvXO9UjNckOu6W+ M37AZrhTfnB6PWhiEqJuoCrjApOaLLSXvaG1nEcmEOqH21jHSlXjwR/fTE6EL8wMq95f8ij6wiBs Mlm7m0Z8Ic3bQR820spQ80TKZOXun8I9c7Bk3wBqisvGmI/aCffcx5vVnKf5jXhnZusNCOrXdjPb XJk14bZLU1kPiY+ddbdtO/ls19mNWpFpJOKnmkHbN2DSnKm6vG+6zA7s2Zv5Dbbvntyg8e66vXrT n6jr/OaNSZdA3/ctRPvq3/W1zm2ogYSNVtV0WheMftFa12+qlaAeqkkBDLgnZwdJdnJ0oOzark0Q nCO2r0G8MktlXNVXkrrLCJ3cIDu7Hvcv35pWqiBTk0XA4tGpP/Unqr4ERghUQY6q4NiwKK/IME5D l63TxU/Z+/8BAAD//wMAUEsDBBQABgAIAAAAIQB8tiTC7AEAAOsDAAAQAAgBZG9jUHJvcHMvYXBw LnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTwW7bMAy9D9g/GL43StIg CwJGxZBi6IBtDRC3PWsynQizJUFig2ZfP8puUqXbaTqRj8TT0yMFNy9dWxwwROPsqpyMxmWBVrva 2N2qfKi+XC3KIpKytWqdxVV5xFjeyI8fYBOcx0AGY8EUNq7KPZFfChH1HjsVR1y2XGlc6BRxGnbC NY3ReOv0c4eWxHQ8ngt8IbQ11lf+TFgOjMsD/S9p7XTSFx+ro2fBEirsfKsI5Y8kpwVxBqBypNrK dCinDJ8T2KgdxoQNATy5UEc5ny9ADCGs9yooTWyevF5MZiAyAD573xqtiH2V340OLrqGivvegSIR gMhbgF3Zon4Oho5yDCJP4ZuxLOV6AmKIWFtQu6D8PkqWk2Ww1arFNb9dNqqNCOINgDtUaa4bZVgx HGh5QE0uFNH85slOy+KnipgcW5UHFYyyxM6ltiHp49ZHCrIy1DI314a8D/O2PDYzycq5l4PLxgQO Grhwqa6/Id43/Db6h9hJLrbXMEjN5GTh+Y53rGvXeWWPcm2idsX2GAm7WHy1mkf5Wkre/4oPvnK3 aX1eTb0Es0V4MrTfeqV5XLPZp4uVyEqw5c3Bmmd8InwD4I4HENp0K6+T3WF96vm7kJbscfi7cjId jfn0W3XCeDXOn0r+AQAA//8DAFBLAwQUAAYACAAAACEAfmMlRVIBAACCAgAAEQAIAWRvY1Byb3Bz L2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJfa8MgFMXfB/sO wfdETekoIbGwlj6tMLaOjr2J3rayaERd/3z7maTNWranPeo59+c5NymnR10ne3BeNaZCNCMoASMa qcy2Qm+rRTpBiQ/cSF43Bip0Ao+m7P6uFLYQjYNn11hwQYFPIsn4QtgK7UKwBcZe7EBzn0WHieKm cZqHeHRbbLn45FvAOSEPWEPgkgeOW2BqByI6I6UYkPbL1R1ACgw1aDDBY5pR/OMN4LT/c6BTrpxa hZONnc5xr9lS9OLgPno1GA+HQ3YYdTFiforfl0+vXdVUmXZXAhArpSiEAx4ax+Z8r2Sy5k6W+Oq6 XWHNfVjGbW8UyMcTe2m8T2a8jrsu8W+5nXCwV+3HYnnnGI7xwa5f/yrIJCYu+n4XZT2azVcLxHJC 85SSlE5WdFyMSUHIR5vsZr5t0F/oc75/Ey8A1iW+/WvYNwAAAP//AwBQSwMEFAAGAAgAAAAhAE1o 9OoYAgAAZQYAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzclLFu2zAQhvcCfQeBeyNKUW3FiBzEbtUp Gdr0AWiKsgiIpEAyVrI6e+cO7SMEHVqgS97GQNa8Qk+UbASQ1TYtulSCAOl4dzp+/O+OT65E6a2Y NlzJBAUHGHlMUpVxuUzQ+4v0RYw8Y4nMSKkkS9A1M+hk+vzZcT3JlbTGg3hpJjpBhbXVxPcNLZgg 5kBVTMJarrQgFj710ld5zil7peilYNL6IcYjX7OSWPi3KXhlUJet/p1stdJZpRVlxkCxomzzCcIl mnbVefVEEgFVX3DBjHfOau+tEqR1qIhUhgXgsyJlgnAI9wgf4pc4gieEtwj5TSZaEG2Y3Tni1pwT wcvrrVW7vM6/4pYWW/uKaE4WJWtjDF/CwqVZ4ATB9nF4Go9RawkSFIOluTpLCEW1F5yBizrcWZwP dXmcS5CmjQ9YIE8X5er023PqEZkTsYDKHKo+iYZAS6IhEv5jEqdNweFrtwNgAzuI3BaiWY/Els0w CXz0RBJn77wzLmmhHAtS2nOQDLB0qni4u324++rdf/xw/+lze4Z9Wo1ujkA1IVCLB3UT79WNUBnT ssv8WDg5v2JZXzUtq9kjVqN4Pk7naY9V8CtWIMA/YPVG2YLTn7DarL9t1t83Nzeb9ZchYjNHbNwR G9LX/0BsTkoOjTbQZ6mbNM3kiZ7cZ6bmxuwRzvDE2d9nIR73tLObQX/TZ93oMdMfAAAA//8DAFBL AwQUAAYACAAAACEAmhskiB4DAADfEgAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxYW2/aMBR+n7T/ gCLtscQJAQIqrXoZUqd2mqbuB5jEEGu+RI6B8u93HCcZpGkKkfqwiRcgPjd/Od85x+by+oWz3oao jEoxc7w+cnpERDKmYjVzfj3PL0Knl2ksYsykIDNnRzLn+urzp8vtVKz5gihQ7IEPkU03IE60Tqeu m0UJ4Tjry5QIEC6l4ljDo1q5HKvf6/QikjzFmi4oo3rn+giNnMKNnDlrJaaFiwtOIyUzudTGZCqX SxqR4qu0UMfEtZb3MlpzInQe0VWEwR6kyBKaZqU33tUbQExKJ5s2EBvOSr1teky0WOEtvGfO7La3 UsWpkhHJMli9t8LKo4faYhcv0LioLI7ZwmHMciccU1G5MfSo5b9KXh+S59rYrnH1Fwi8iysgE15k WuFIf1/z3sHTQzxzUK4iMhqDbIMZrNwG3ujODx3XGPM10/SRbAh73qWk1El2C0XjJyNjRmZ1NU9Z qTGYoBG6vxlZCdsYAYUvExF+6pRF8DNEE4TQPN8DlILSpbln7aAO5rxajElEOS6Cga9n8lLJvnj9 KtS3qHTDyFLb5fSHMnCoMDjN8swZ+/lWEixWeUkORsjouttpoaysjZpLoTMwS6gAs5gsMQAvVHMd MIHtGP/7QL06UG9yJFAmt0Q9Eq2JqkAdgPVPBusFQSvaZgj+Kwi3+QqUOVS36UreKZB+So5FM6JB EyJFV8nb+fM9SJhJS5lALzxIYDOkQR0S0A+c6NMhtdIxaMLTSkc/hO3vw6nxsRlOUIcDJOsG513S DU+GBAg6QBq+gvRRpBs1IWonXTCodY2jSAcT+FXP65alVtKNm/C0km6IurSFcR3Ox5EuPB3SuNYW jqojOIsdZsj7KNJNmhC1k24U1FrDG6SDFrE37N+d/bZ378/+AfKHwc3dV9uju85+5N8E4TC8qzo9 vNp/a/Y399qmgd6tit/ttecBDyet84CH4/J5wNtrSeONIK+jllPlecCfB3wxev7TAQ83ZBhB8Gku 83ag7x0BHsxtN7/V5+UDYw00zbngwMzP73CNZuWFKjez5vaPqas/AAAA//8DAFBLAwQUAAYACAAA ACEAK/HbsUQIAAAHPwAAGgAAAHdvcmQvc3R5bGVzV2l0aEVmZmVjdHMueG1stFvbcts2EH3vTP+B w3dHFztW4qnSSe24cScXJ3KmzxAFWWhIgiUpO+7Xd7EgIYoUxV2TebJMAnv2ehaWsb/9/iMKvQeZ ZkrHc3/yYux7Mg70SsX3c//b3fXJK9/LchGvRKhjOfefZOb//ubXX357vMjyp1BmHgiIs4vHJJj7 mzxPLkajLNjISGQvIhWkOtPr/EWgo5Fer1UgR486XY2m48kYPyWpDmSWAdqliB9E5hfioqY0ncgY sNY6jUSevdDp/SgS6fdtcgLSE5GrpQpV/gSyx+elGD33t2l8USh04hQyWy6sQsWPckfasOIArt15 pYNtJOMcEUepDEEHHWcblezMeK40MHFTqvRwzIiHKCzXPSaTswaeM5kSg6tUPEIodgIb4g44Y2U3 RaH1g4nvLqp1iZPxMWOKiBgRTgeKCvuYpSaRULET8zzXVJ0L9dAnv/9M9TZx6iSqn7Sb+LuTZcqS odn4HCuvalrGEtAo3cVGJNL3ouDi5j7WqViGoNHj5MwzGem/AapY6eBKrsU2zDPza3qbFr8Wv+GP ax3nmfd4IbJAqTugEJASKRD4/m2cKR/eSJHlbzMlqi/fFc/M+41ZWH3pdgZZXhH4h1opf2RAQxHf w8YHEc59GZ98W1Rh5v4/4uSvW/NoCTvmvkhPFm/NxhHaUP6s2JI4y+yqmuFAEUAYC0uc4Ba5/qCD 73K1yOHF3AfyxYffbm5TpVNgs7n/+nXxcCEj9V6tVtLwdLkw3qiV/Hsj42+ZXO2ef7lGliwkBnob 53N/ej7DYITZ6t2PQCaGrQAvFsbRn8wGoBKg9QoOKrRVO23sgxoqPvy3hJwUnj2EspHCdBYP9T8K hFZvewNNjUVVA1AuS9fT/iLO+ot42V8EdMW+vpj1FwHnib5a2NyoZCU9qLkObPJVc+L09ZGUNTsa WdS5o5E0nTsaOdK5o5ESnTsaGdC5oxHwzh2N+HbuaITz6I5AIHHVs+gUvUEq7DuVh9CuOphu0pPq iqbg3YpU3Kci2Ximv9XVPkaWi+0yp6mKdPp8slzkqTanvg6PTG0ZPJuT30XJRmQKDsddQD1df2dO IN6fqYJTZAfUS5t8DZvs4eBQC7sNRSA3OlzJ1LuTP2xEGfs/aW+RiACP2ftE2DOKH9T9JvfgLGY6 bKfh5y0+bjfcyv+gMjT5aPM+bzGlSzgpZOctadgu/KNcqW1UuoZw+Di39M2Iag0CVTzuojMTombN dlphAkAxwXYHvgkon6C/7SV8+SbGFP1t53mmfIL+tk89Uz7mx/H4sonlCr7M8EjlNWPX7qUOdbre hmUNdNLDjF3BDoJmAruInXwSSczYFbxHn97bIIA/1Ch5yo7FjkcZKOxwWBQsNrot7KDUaG/CsIgd oBrWlIHVj2sZQGzS/SoflPnqldsMkKXd0bKznE9bPAAtiHRk/rLVefeRedrCeVSUmxi+HcmkR0M7 bak8KlqRT7bfMWLcr/ExgPp1QAZQv1bIAGrJj/Yzj+uJdJD+zZGBxaZl18Uw7cjMPGMzswPitYCB +ibh/NVSve250OybBBR2gJp9k4DCjk6tl7m+ScAarG8SsFq6RnuMqpzKMYrdN6tA7iRAsGgY8iYA DUPeBKBhyJsA1J+8u0GGI28CFpsbHKdWyZsAhEs4f+o7oCp5E4DY3GDZrvjOqOx7KOX4H7cDkDcB hR2gJnkTUNjRaSNvAhYu4WRCDctRHQFrGPImAA1D3gSgYcibADQMeROAhiFvAlB/8u4GGY68CVhs bnCcWiVvAhCbHhxQlbwJQLiEww0HyRur/qeTNwGFHaAmeRNQ2NGpEao7pBKw2AGqYTnyJmDhEk4y FFiY3ByjhiFvgkXDkDcBaBjyJgANQ94EoP7k3Q0yHHkTsNjc4Di1St4EIDY9OKAqeROA2NxwkLyx GH86eRNQ2AFqkjcBhR2dGqE6niNgsQNUw3LkTcDCfOlN3gQgXPJcII5Fw5A3waJhyJsANAx5E4D6 k3c3yHDkTcBic4Pj1Cp5E4DY9OCAquRNAGJzw0Hyxhr56eRNQGEHqEneBBR2dGqE6sibgMUOUA3L UR0BaxjyJgBhYvYmbwIQLnkGEFYRJ0zDkDfBomHImwDUn7y7QYYjbwIWmxscp1bJmwDEpgcHVCVv AhCbG8y1WrgeSr6NOmlJAuo9g/JWAxlw2hIkKmBh4Fe5linM8snu2yE9AUsLGYgt6UE18Q+tv3u0 e9ynLQlChlLLUGm8wf2Et3QqcwensyODA3efL733dt6lsQ9Tav/mDYwUVaeDzHASDliCnvlTAhM6 SXmR3EiDySEzTVVM/ODCG5j/KaZ4zGYz1gMLcbKpeIz/ty1Q8TPMYSHOf+XC6VltugklN3UJNqBM kMv0iC7FBXh3SQmvv9c1a7klj9rtRjRK9Yrb8rtDll23d4kTHoErW/TOzc3wIzrjzfGjTvRwiQ17 U0EY1kKVujSEmC5D63z4cBOvwMLHYlrLRnv1Q1hR8P5ShuFHgaHKddK+NJTr3L6djLFF1kQtdZ7r qH1/ijfIUZNDAsCtVWXsr8aIdn/H22gp0+I+emvOmtaCk2n7OWsvw7akAtXT7brt5bCroPdQa2mo YLyynqq7N6jSUsDE3WczQIcldjDbO3TfP5PhYpjDNrmAIsfjq5fjGVzUt29sugTmJu9uxXh8fW3y GacbsYXCKKczweKXq82UNWQ/PASnYOm3O2ePbJxzTKBcPTcchCeE3WsEr3mpSkTN6oFbirhpj6L2 HPL6+nx8+cquglFLEyKFxWNSf+7PpoWzAhi1gdmMrQiLWQtrNG7ZGV1+yt78DwAA//8DAFBLAQIt ABQABgAIAAAAIQABLhqfkwEAABMGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAB6RGrfzAAAATgIAAAsAAAAAAAAAAAAAAAAAzAMAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAK6j10wyAQAAPgQAABwAAAAAAAAAAAAAAAAA8AYAAHdvcmQvX3Jl bHMvZG9jdW1lbnQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAhV0T0BYRAAA5bAAAEQAAAAAAAAAA AAAAAABkCQAAd29yZC9kb2N1bWVudC54bWxQSwECLQAUAAYACAAAACEAnVyLvhAHAACHHQAAFQAA AAAAAAAAAAAAAACpGgAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEGAYpq9 BAAABA0AABEAAAAAAAAAAAAAAAAA7CEAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAh ALm+ds+zAAAA+gAAABQAAAAAAAAAAAAAAAAA2CYAAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0A FAAGAAgAAAAhAPdrvTaSBwAAoTsAAA8AAAAAAAAAAAAAAAAAvScAAHdvcmQvc3R5bGVzLnhtbFBL AQItABQABgAIAAAAIQB8tiTC7AEAAOsDAAAQAAAAAAAAAAAAAAAAAHwvAABkb2NQcm9wcy9hcHAu eG1sUEsBAi0AFAAGAAgAAAAhAH5jJUVSAQAAggIAABEAAAAAAAAAAAAAAAAAnjIAAGRvY1Byb3Bz L2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAE1o9OoYAgAAZQYAABIAAAAAAAAAAAAAAAAAJzUAAHdv cmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQCaGySIHgMAAN8SAAASAAAAAAAAAAAAAAAA AG83AAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEAK/HbsUQIAAAHPwAAGgAAAAAA AAAAAAAAAAC9OgAAd29yZC9zdHlsZXNXaXRoRWZmZWN0cy54bWxQSwUGAAAAAA0ADQBJAwAAOUMA AAAA --_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5521F8681 for ; Wed, 17 Oct 2012 11:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPU5p6GmNJob for ; Wed, 17 Oct 2012 11:07:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0841C21F867C for ; Wed, 17 Oct 2012 11:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4432; q=dns/txt; s=iport; t=1350497257; x=1351706857; h=from:to:cc:subject:date:message-id:mime-version; bh=YhR15w0SOyVZQgxBsRrFrQ47ZFkUtSKieHUPETBnpCI=; b=PldWDaOmzYW0KTCd+bcA7zIP3dMw2zDfQ88f7Ta/dR57Za3CgMXCc0kD Mq5XO+7Z9IjeZNW+SsMJbT3ztr0PdlVje9wV9pU+4hUxgBUK5XK8Et81t v+WYH+mUWI9DiBojmhA98rleuJQ+RBUnuMd41Hnju99BwtaC+0Xq7yXzy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFLyflCtJV2a/2dsb2JhbABFgkq0fAGIX4EIgiIBBBIBGkwSASpWJgEEDg0MDodiC5tEoCmROmADlwCNNIFrgm+CFw X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208,217";a="132688753" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2012 18:07:36 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9HI7Zpf031440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 18:07:35 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 13:07:35 -0500 From: "Rex Fernando (rex)" To: "irs-discuss@ietf.org" Thread-Topic: IRS framework requirements Thread-Index: Ac2skdCyLr5smU6+QUGg0fOHDqB5Qg== Date: Wed, 17 Oct 2012 18:07:34 +0000 Message-ID: <868851912C182241B686E0BD4D73BC17142C97@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.18.250] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--33.702100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_" MIME-Version: 1.0 Cc: Ross Callon , "adrian@olddog.co.uk" Subject: [irs-discuss] IRS framework requirements X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 18:07:37 -0000 --_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We've submitted a framework requirements draft for IRS. Its located here, http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement-00 The draft tries to outline the various concerns and requirements to be addr= essed in making the IRS framework. It also establishes a vocabulary so tha= t we speak the same language when describing matters related to IRS. This i= s a preliminary version and expected to evolve (quite a bit) to its final = form with community input. Please review and provide comments. Cheers, - Rex --_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We've submitted a framework requirements draft fo= r IRS. Its located here,

 

http://tools.ietf.org/html/draft-rfernan= do-irs-framework-requirement-00

 

The draft tries to outline the various concerns a= nd requirements to be addressed in making the IRS framework. It also establ= ishes a  vocabulary so that we speak the same language when describing= matters related to IRS. This is a preliminary version and expected to evolve (quite a bit)  to its final form with = community input.

 

Please review and provide comments.

 

Cheers,

- Rex

--_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9712D21F8833 for ; Wed, 17 Oct 2012 03:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZ3xbDyCre8H for ; Wed, 17 Oct 2012 03:00:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web.hickoryhill-consulting.com [64.9.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48E21F87F1 for ; Wed, 17 Oct 2012 03:00:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; Received: from SKH2012HPLT (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 8494-1945496 for multiple; Tue, 30 Oct 2012 20:01:11 -0500 From: "Susan Hares" To: "'Ross Callon'" , References: In-Reply-To: Date: Wed, 17 Oct 2012 06:00:11 -0400 Message-ID: <005d01cdac4e$32fe3700$98faa500$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CDAC2C.ABEE1DA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJQnKjwlI4lMZDF0F5Qr9FsqkPefpa3Ysfg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [irs-discuss] Spam:*******, IRS Internet Drafts X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 10:00:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005E_01CDAC2C.ABEE1DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ross: Please add draft-hares-use-case-vn-vc-00 to you list. Sue From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Ross Callon Sent: Tuesday, October 16, 2012 11:45 PM To: irs-discuss@ietf.org Subject: Spam:*******, [irs-discuss] IRS Internet Drafts We now have nine Internet Drafts related to IRS. This is a great start! (and given that the -00 deadline has passed, I am guessing that this might be the number until the IETF starts). Thanks to all of the authors for their work. I would like to encourage the authors of these nine drafts to introduce them to the IRS-discuss email list. The nine drafts are follows (please let the list know if I am missing any): draft-amante-irs-topology-use-cases-00 draft-atlas-irs-policy-framework-00 draft-atlas-irs-problem-statement-00 draft-dimitri-irs-arch-frame-00 draft-keyupate-irs-bgp-usecases-00 draft-medved-irs-topology-requirements-00 draft-rfernando-irs-framework-requirement-00 draft-ward-irs-framework-00 draft-white-irs-use-case-00 Thanks, Ross ------=_NextPart_000_005E_01CDAC2C.ABEE1DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ross:


Please add draf= t-hares-use-case-vn-vc-00 to you list.

 

Sue =

 

From:= = irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On = Behalf Of Ross Callon
Sent: Tuesday, October 16, 2012 = 11:45 PM
To: irs-discuss@ietf.org
Subject: = Spam:*******, [irs-discuss] IRS Internet = Drafts

 

We now = have nine Internet Drafts related to IRS. This is a great start! (and = given that the -00 deadline has passed, I am guessing that this might be = the number until the IETF starts). Thanks to all of the authors for = their work.

 =

I would = like to encourage the authors of these nine drafts to introduce them to = the IRS-discuss email list.

 =

The nine = drafts are follows (please let the list know if I am missing any): =

 =

draft-amante-irs-topology-use-cases-00=

draft-atlas-irs-policy-framework-00=

draft-atlas-irs-problem-statement-00=

draft-dimitri-irs-arch-frame-00=

draft-keyupate-irs-bgp-usecases-00=

draft-medved-irs-topology-requirements-00=

draft-rfernando-irs-framework-requirement-00=

draft-ward-irs-framework-00=

draft-white-irs-use-case-00=

 =

Thanks, = Ross

 =

------=_NextPart_000_005E_01CDAC2C.ABEE1DA0-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2EA1F041F for ; Tue, 16 Oct 2012 20:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98z5nWU5qojm for ; Tue, 16 Oct 2012 20:47:53 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id B9CD41F040A for ; Tue, 16 Oct 2012 20:47:53 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUH4qaY/YFijJQqGD0tCM1OflM8lD0Yxc@postini.com; Tue, 16 Oct 2012 20:47:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Oct 2012 20:44:47 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 16 Oct 2012 23:44:46 -0400 From: Ross Callon To: "irs-discuss@ietf.org" Date: Tue, 16 Oct 2012 23:44:44 -0400 Thread-Topic: IRS Internet Drafts Thread-Index: Ac2sGb9UeidgWe+zTzKuySGQubF7aw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_" MIME-Version: 1.0 Subject: [irs-discuss] IRS Internet Drafts X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 03:47:54 -0000 --_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We now have nine Internet Drafts related to IRS. This is a great start! (an= d given that the -00 deadline has passed, I am guessing that this might be = the number until the IETF starts). Thanks to all of the authors for their w= ork. I would like to encourage the authors of these nine drafts to introduce the= m to the IRS-discuss email list. The nine drafts are follows (please let the list know if I am missing any): draft-amante-irs-topology-use-cases-00 draft-atlas-irs-policy-framework-00 draft-atlas-irs-problem-statement-00 draft-dimitri-irs-arch-frame-00 draft-keyupate-irs-bgp-usecases-00 draft-medved-irs-topology-requirements-00 draft-rfernando-irs-framework-requirement-00 draft-ward-irs-framework-00 draft-white-irs-use-case-00 Thanks, Ross --_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We now have nine Internet Drafts related to IRS. This is a great start= ! (and given that the -00 deadline has passed, I am guessing that this migh= t be the number until the IETF starts). Thanks to all of the authors for th= eir work.
 
I would like to encourage the authors of these nine drafts to introduc= e them to the IRS-discuss email list.
 
The nine drafts are follows (please let the list know if I am missing = any):
 
draft-amante-irs-topo= logy-use-cases-00
draft-atlas-irs-polic= y-framework-00
draft-atlas-irs-probl= em-statement-00
draft-dimitri-irs-arc= h-frame-00
draft-keyupate-irs-bg= p-usecases-00
draft-medved-irs-topo= logy-requirements-00
draft-rfernando-irs-f= ramework-requirement-00
draft-ward-irs-framew= ork-00
draft-white-irs-use-c= ase-00
 
Thanks, Ross
 
 --_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FFB21F8722 for ; Wed, 10 Oct 2012 08:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7W2h4FI-vwa for ; Wed, 10 Oct 2012 08:22:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1621F87D2 for ; Wed, 10 Oct 2012 08:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6844; q=dns/txt; s=iport; t=1349882526; x=1351092126; h=from:to:subject:date:message-id:mime-version; bh=6LfOVTH4KtmsaOG03hOxjJamHh37PJ7WF9lzzjhyH9E=; b=Ztji+OasGBV4VHCw1vo4A7Xo9+7T7o1HWy8Pdx8IZ0+cQH6LBkgEYRX3 /HJO6Gv04pF/nRYZ8e30Bay15j1g4GGdv9JPzuPEDTp4oNFsn9gjkUS5v 7sQllGCJZvxT+UuOSEn74XpluT8Xvpn7RRfgaiFJzlgH+QdhLqf84hDdz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABKSdVCtJXG+/2dsb2JhbABEgku8Y4EIgiIBBBIBGl4BKlYmAQQbARmHYguWPYEooCeRB2ADpDGBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208,217";a="129971367" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 10 Oct 2012 15:22:05 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9AFM5PE014086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 10 Oct 2012 15:22:05 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.162]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Wed, 10 Oct 2012 10:22:05 -0500 From: "Kausik Majumdar (kmajumda)" To: "irs-discuss@ietf.org" Thread-Topic: [irs-discuss] central membership computation for mpls VPNs Thread-Index: Ac2m+wCD0x2GxGt7S+q7EuhRKdEMLw== Date: Wed, 10 Oct 2012 15:22:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.186.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19258.000 x-tm-as-result: No--35.566400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: [irs-discuss] central membership computation for mpls VPNs X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:22:18 -0000 --_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am new in irs alias. I was looking through the draft http://www.ietf.org/= id/draft-white-irs-use-case-00.txt to find out some more details on the cen= tral membership computation for MPLS VPNs as mentioned in the doc - MPLS based VPNs use route target extended communities to express membership information. Every PE router holds incoming BGP NLRI and processes them to determine membership and then import the NLRI into the appropriate MPLS/VPN routing tables. This consumes resources, both memory and compute on each of the PE devices. An alternative approach is to monitor routing updates on every PE from the attached CEs and then compute membership in a central manner. Once computed the routes are pushed to the VPN RIBs of the participating PEs. Are we talking about exporting the route updates from each PEs to a central= server out of hw devices and compute BGP membership centrally and then dow= nloading the selective/optimized routes to the respective PEs ? Can someone= point me some details on how to compute membership in a central manner. Thanks in advance, Kausik --_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I am new in irs alias. I was looking through the dra= ft http://www.ietf.org/id/draft-white-irs-use-case-00.txt to find out some= more details on the central membership computation for MPLS VPNs as mentio= ned in the doc –

 

   MPLS based VPNs use route target extended com= munities to express

   membership information.  Every PE router= holds incoming BGP NLRI and

   processes them to determine membership and th= en import the NLRI into

   the appropriate MPLS/VPN routing tables. = ; This consumes resources,

   both memory and compute on each of the PE dev= ices.

 

   An alternative approach is to monitor routing updates on every PE

   from t= he attached CEs and then compute membership in a central<= /p>

   manner= .  Once computed the routes are pushed to the VPN RIBs of the

   partic= ipating PEs.

 

Are we talking about exporting the route updates fro= m each PEs to a central server out of hw devices and compute BGP membership= centrally and then downloading the selective/optimized routes to the respe= ctive PEs ? Can someone point me some details on how to compute membership in a central manner.

 

Thanks in advance,

Kausik  

 

--_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002E21F87CA for ; Mon, 8 Oct 2012 15:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oecZUX2ojOoV for ; Mon, 8 Oct 2012 15:33:29 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 428DA21F87C8 for ; Mon, 8 Oct 2012 15:33:29 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUHNUuJx30Lgynf/qaFJSQufCZ8mlL0mX@postini.com; Mon, 08 Oct 2012 15:33:29 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Oct 2012 15:31:38 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Oct 2012 15:31:37 -0700 Received: from AM1EHSOBE003.bigfish.com (213.199.154.208) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Oct 2012 15:37:03 -0700 Received: from mail123-am1-R.bigfish.com (10.3.201.230) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 8 Oct 2012 22:31:36 +0000 Received: from mail123-am1 (localhost [127.0.0.1]) by mail123-am1-R.bigfish.com (Postfix) with ESMTP id 3498E200BC for ; Mon, 8 Oct 2012 22:31:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zf7Iz9371Ic85eh4015Izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh172c6chz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail123-am1 (localhost.localdomain [127.0.0.1]) by mail123-am1 (MessageSwitch) id 1349735494767287_18210; Mon, 8 Oct 2012 22:31:34 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.247]) by mail123-am1.bigfish.com (Postfix) with ESMTP id B8668460070; Mon, 8 Oct 2012 22:31:34 +0000 (UTC) Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Oct 2012 22:31:31 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.188]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0207.009; Mon, 8 Oct 2012 22:31:24 +0000 From: Thomas Nadeau To: Iftekhar Hussain , "" Thread-Topic: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt Thread-Index: AQHNpZladXPoRw/EXk6j+euSMIlef5ev+zKA//+/2oA= Date: Mon, 8 Oct 2012 22:31:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CC98CC62FC18tnadeaujunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 22:33:30 -0000 --_000_CC98CC62FC18tnadeaujunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Will do. Also, hopefully the forthcoming requirements draft that Jan is publishing t= omorrow morning, should help too. --Tom From: Iftekhar Hussain = > Date: Monday, October 8, 2012 6:21 PM To: Thomas Nadeau >, ">" > Subject: RE: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi Tom, Okay, I see. I think, it would be helpful to: =B7 Clarify the context of this example as currently it is a little= unclear. For example, ROADM layer =91active=92 topology would normally be = =91visible=92 to the IGP=92s LSDB (i.e., IGPs with GMPLS extensions). =B7 Add few multi-layer topology examples and their use by network = applications (e.g., what type of info one would like to reveal etc.). Thanks, Iftekhar From: Thomas Nadeau [mailto:tnadeau@juniper.net] Sent: Monday, October 08, 2012 2:11 PM To: Iftekhar Hussain; > Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi! The IRS topology effort is not about what is visible to what devices per se= ; its about revealing different topological components in a normalized topo= logy database. So in this example, capturing the active information (which = is visible via LSDB/IGP routing protocols), is complimented with other inac= tive (or passive) topological components. --Tom From: Iftekhar Hussain = > Date: Sunday, October 7, 2012 6:00 PM To: ">" > Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi Authors, =93=85and visible within the Link State Database (LSDB) of an active IGP, b= ut also network elements who are active, but invisible to a LSDB (e.g.: L2 = Ethernet switches, ROADM's, etc.)=94 Shouldn=92t ROADMs topology be visible to IGP? Perhaps you intend to say op= tical line amplifier (OLA). Regards, Iftekhar --_000_CC98CC62FC18tnadeaujunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <731127F65E137F458C82660C08D202F9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Will d= o.

Also, = hopefully the forthcoming requirements draft that Jan is publishing tomorro= w morning, should help too.

--Tom<= /div>



From: Iftekhar Hussain <IHussain@infinera.com>
Date: Monday, October 8, 2012 6:21 = PM
To: Thomas Nadeau <tnadeau@juniper.net>, "<irs-discuss@ietf.org>" <irs-discuss@ietf.org>
Subject: RE: [irs-discuss] Fwd: New= Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Tom,

 

Okay, I see.  I think, it wou= ld be helpful to:

=B7    =      Clarify the context of= this example as currently it is a little unclear. For example, ROADM layer= =91active=92 topology would normally be =91visible=92 to the IGP=92s LSDB (i.e., IGPs with GMPLS extensions).

=B7    =      Add few multi-layer to= pology examples and their use by network applications (e.g., what type of i= nfo one would like to reveal etc.).

Thanks,

Iftekhar

From: Thomas Nadeau [mailto:tnadeau@juniper.net]
Sent: Monday, October 08, 2012 2:11 PM
To: Iftekhar Hussain; <ir= s-discuss@ietf.org>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-a= mante-irs-topology-use-cases-00.txt

 

 

Hi!

 

The IRS topology effort is not about w= hat is visible to what devices per se; its about revealing different topolo= gical components in a normalized topology database. So in this example, capturing the active information (which is v= isible via LSDB/IGP routing protocols), is complimented with other inactive= (or passive) topological components. 

 

--Tom

 

 

From: Iftekhar Hussain <IHussain@infinera.com>
Date: Sunday, October 7, 2012 6:00 PM
To: "<irs-discuss@ie= tf.org>" <irs-discus= s@ietf.org>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-a= mante-irs-topology-use-cases-00.txt

 

Hi Authors,

=93=85and visible within the Link State Database (LSDB) of an active= IGP, but also network elements who are active, but invisible to a LSDB (e.= g.: L2 Ethernet switches, ROADM's, etc.)=94

Shouldn=92t ROADMs topology be visible to IGP? Perhaps you intend to= say optical line amplifier (OLA).

Regards,

Iftekhar

 

 

 --_000_CC98CC62FC18tnadeaujunipernet_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA78D1F0423 for ; Mon, 8 Oct 2012 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFeC4XkZsvyF for ; Mon, 8 Oct 2012 15:21:03 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 404EA1F0417 for ; Mon, 8 Oct 2012 15:21:03 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0298.004; Mon, 8 Oct 2012 15:21:02 -0700 From: Iftekhar Hussain To: Thomas Nadeau , "" Thread-Topic: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt Thread-Index: AQHNpZmaYmOwEScpT0CHbpU9w3a82Zev95JQ Date: Mon, 8 Oct 2012 22:21:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 22:21:04 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Okay, I see. I think, it would be helpful to: * Clarify the context of this example as currently it is a little u= nclear. For example, ROADM layer 'active' topology would normally be 'visib= le' to the IGP's LSDB (i.e., IGPs with GMPLS extensions). * Add few multi-layer topology examples and their use by network ap= plications (e.g., what type of info one would like to reveal etc.). Thanks, Iftekhar From: Thomas Nadeau [mailto:tnadeau@juniper.net] Sent: Monday, October 08, 2012 2:11 PM To: Iftekhar Hussain; Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi! The IRS topology effort is not about what is visible to what devices per se= ; its about revealing different topological components in a normalized topo= logy database. So in this example, capturing the active information (which = is visible via LSDB/IGP routing protocols), is complimented with other inac= tive (or passive) topological components. --Tom From: Iftekhar Hussain = > Date: Sunday, October 7, 2012 6:00 PM To: ">" > Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi Authors, "...and visible within the Link State Database (LSDB) of an active IGP, but= also network elements who are active, but invisible to a LSDB (e.g.: L2 Et= hernet switches, ROADM's, etc.)" Shouldn't ROADMs topology be visible to IGP? Perhaps you intend to say opti= cal line amplifier (OLA). Regards, Iftekhar --_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tom,=

 <= /p>

Okay, I see.  I thin= k, it would be helpful to:

·      = ;   Clarify the conte= xt of this example as currently it is a little unclear. For example, ROADM = layer ‘active’ topology would normally be ‘visible’= to the IGP’s LSDB (i.e., IGPs with GMPLS extensions).=

·      = ;   Add few multi-lay= er topology examples and their use by network applications (e.g., what type= of info one would like to reveal etc.).

Thanks,=

Iftekhar

From: Thomas N= adeau [mailto:tnadeau@juniper.net]
Sent: Monday, October 08, 2012 2:11 PM
To: Iftekhar Hussain; <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-a= mante-irs-topology-use-cases-00.txt

 

 

Hi!

 

The IRS topology effort is&= nbsp;not about what is visible to what devices per se; its about revealing = different topological components in a normalized topology database. So in this example, capturing the active information (which is visible via= LSDB/IGP routing protocols), is complimented with other inactive (or passi= ve) topological components. 

 

--Tom

 

 

From: Iftekhar Hussain <IHussain@infinera.com>
Date: Sunday, October 7, 2012 6:00 PM
To: "<irs-discuss@ie= tf.org>" <irs-discus= s@ietf.org>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-a= mante-irs-topology-use-cases-00.txt

 

Hi Authors,

“…and visible within the Link State Database (LSDB) of a= n active IGP, but also network elements who are active, but invisible to a = LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)”

Shouldn’t ROADMs topology be visible to IGP? Perhaps you inten= d to say optical line amplifier (OLA).

Regards,

Iftekhar

 

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9841F042A for ; Mon, 8 Oct 2012 14:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMI8yVL3t1XT for ; Mon, 8 Oct 2012 14:10:39 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id DBC4B1F041F for ; Mon, 8 Oct 2012 14:10:38 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUHNBTh/+8gPTkNExiEbguiiSAlHgHEQE@postini.com; Mon, 08 Oct 2012 14:10:38 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Oct 2012 14:10:38 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Oct 2012 14:10:37 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Oct 2012 14:16:03 -0700 Received: from mail125-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE011.bigfish.com (10.243.66.74) with Microsoft SMTP Server id 14.1.225.23; Mon, 8 Oct 2012 21:10:37 +0000 Received: from mail125-co1 (localhost [127.0.0.1]) by mail125-co1-R.bigfish.com (Postfix) with ESMTP id 3EE79540080 for ; Mon, 8 Oct 2012 21:10:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zf7Iz9371Ic85ehzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail125-co1 (localhost.localdomain [127.0.0.1]) by mail125-co1 (MessageSwitch) id 1349730635696440_1026; Mon, 8 Oct 2012 21:10:35 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.236]) by mail125-co1.bigfish.com (Postfix) with ESMTP id A8552A8004B; Mon, 8 Oct 2012 21:10:35 +0000 (UTC) Received: from CH1PRD0511HT001.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Oct 2012 21:10:35 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.188]) by CH1PRD0511HT001.namprd05.prod.outlook.com ([10.255.159.36]) with mapi id 14.16.0207.009; Mon, 8 Oct 2012 21:10:34 +0000 From: Thomas Nadeau To: Iftekhar Hussain , "" Thread-Topic: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt Thread-Index: AQHNpZladXPoRw/EXk6j+euSMIlefw== Date: Mon, 8 Oct 2012 21:10:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CC98B91CFBF1tnadeaujunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 21:10:39 -0000 --_000_CC98B91CFBF1tnadeaujunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! The IRS topology effort is not about what is visible to what devices per se= ; its about revealing different topological components in a normalized topo= logy database. So in this example, capturing the active information (which = is visible via LSDB/IGP routing protocols), is complimented with other inac= tive (or passive) topological components. --Tom From: Iftekhar Hussain = > Date: Sunday, October 7, 2012 6:00 PM To: ">" > Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-i= rs-topology-use-cases-00.txt Hi Authors, =93=85and visible within the Link State Database (LSDB) of an active IGP, b= ut also network elements who are active, but invisible to a LSDB (e.g.: L2 = Ethernet switches, ROADM's, etc.)=94 Shouldn=92t ROADMs topology be visible to IGP? Perhaps you intend to say op= tical line amplifier (OLA). Regards, Iftekhar --_000_CC98B91CFBF1tnadeaujunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4B3F13B3746F5C4D96191ECFD6E85F46@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi!

The IR= S topology effort is not about what is visible to what devices per se;= its about revealing different topological components in a normalized topol= ogy database. So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), = is complimented with other inactive (or passive) topological components.&nb= sp;

--Tom<= /div>


From: Iftekhar Hussain <IHussain@infinera.com>
Date: Sunday, October 7, 2012 6:00 = PM
To: "<irs-discuss@ietf.org>" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Fwd: New= Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Authors,

=93=85and visible wit= hin the Link State Database (LSDB) of an active IGP, but also network eleme= nts who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, RO= ADM's, etc.)=94

Shouldn=92t ROADMs to= pology be visible to IGP? Perhaps you intend to say optical line amplifier = (OLA).

Regards,

Iftekhar

 

 

 --_000_CC98B91CFBF1tnadeaujunipernet_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EEA21F8681 for ; Sun, 7 Oct 2012 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE7oyAmbsX+d for ; Sun, 7 Oct 2012 15:00:16 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4709E21F8679 for ; Sun, 7 Oct 2012 15:00:15 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0298.004; Sun, 7 Oct 2012 15:00:15 -0700 From: Iftekhar Hussain To: "" Thread-Topic: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt Thread-Index: AQHNoWAVFV7fWENG8EC+qoYcmocQLJeuaUgg Date: Sun, 7 Oct 2012 22:00:14 +0000 Message-ID: References: <20121002221835.25341.54971.idtracker@ietfa.amsl.com> <4C43CAD2-093B-4795-8CB9-3A713B914B44@juniper.net> In-Reply-To: <4C43CAD2-093B-4795-8CB9-3A713B914B44@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 22:00:17 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, "...and visible within the Link State Database (LSDB) of an active IGP, but= also network elements who are active, but invisible to a LSDB (e.g.: L2 Et= hernet switches, ROADM's, etc.)" Shouldn't ROADMs topology be visible to IGP? Perhaps you intend to say opti= cal line amplifier (OLA). Regards, Iftekhar --_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

“…and vis= ible within the Link State Database (LSDB) of an active IGP, but also netwo= rk elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet swit= ches, ROADM's, etc.)”

Shouldn’t ROADM= s topology be visible to IGP? Perhaps you intend to say optical line amplif= ier (OLA).

Regards,

Iftekhar

 

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_-- Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC39A21F8512 for ; Wed, 3 Oct 2012 21:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mz9iLtBNnshI for ; Wed, 3 Oct 2012 21:24:46 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C261621F8507 for ; Wed, 3 Oct 2012 21:24:46 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id EB58FA3ABE for ; Wed, 3 Oct 2012 21:24:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3194E1A2FAC; Wed, 3 Oct 2012 21:24:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F00B91A2FA9; Wed, 3 Oct 2012 21:24:42 -0700 (PDT) Message-ID: <506D0F86.1050201@joelhalpern.com> Date: Thu, 04 Oct 2012 00:24:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Shane Amante References: <506BA52E.2060008@joelhalpern.com> <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> <506C3F71.2020106@joelhalpern.com> <2DE36DA3-AA9A-4071-A34F-CA46F73708FC@castlepoint.net> In-Reply-To: <2DE36DA3-AA9A-4071-A34F-CA46F73708FC@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 04:24:47 -0000 I agreethat we need to look at using existing protocols / mechaisms. My concern is merely that the wording in the raft, in trying to raise that, describes using existing configuration protocols and direct manipulation of the routing protocol internals. There are significantly more alternatives, both i the extant category and in the new category. Hence, I am merely asking that the use case not get cluttered with text on the specifics. (All solving this takes is removing one or two sentences.) Yours, Joel On 10/3/2012 11:46 PM, Shane Amante wrote: > Hi Joel, > > On Oct 3, 2012, at 7:36 AM, Joel M. Halpern wrote: >> Thanks for the prompt and helpful response Shane. >> >> With regard to the hierarchical topology model, I strongly agree that we need a model that supports hierarchy / layering / service dependence. >> My concern is that the text currently says that the ISO layers are a good starting point for this. As far as I can tell, the ISO model is a very bad pace o start developing such a model. > > OK; however, we need some way to address it. I'd welcome your and others opinions on a better alternative. > > >> With regard to the configuration protocol, the text talks about injecting information into the routing protocol instance, or using the existing configuration tools. Other drafts have talked about the IRS agent as a new channel, which provides a similar but distinguished set of configuration. There have also been discussions of how information gets intoIGPs (directly telling the GP to emit a route vs configuring a class of static route and having it imported.) It seems to methat this is an important area, with much work to be done. Thus, it seems simpler if this draft simply said it would use IRS related confiuration mechanisms to make its changes, and did not try to categorize or approximate those. > > Actually, before submitting the draft we (co-authors) had been having a debate on this very subject. I think this will be an area of "lively" discussion, both on the mailing list and in-person. > > Ultimately, there's likely several dimensions we need to evaluate to determine what the possibly-to-be-formed IRS WG will work on, what other (existing) IETF WG's will work on, what _already_exists_ by other IETF WG's that can get re-used, etc. With respect to the latter, we tried to recognize that "IRS" does not have to solve for every single use case. Rather, there are likely classes of use cases where existing (IETF) protocols are more than adequate to fulfill that need -- some immediate examples that comes to mind are: NETCONF & YANG. These protocols seem adequate for use cases where there is no requirement for (near-)real-time communication/transactions, there is not a substantial concern about on-the-wire-overhead, etc. Example use cases in this draft that may fit this criteria are: Cap Planning and Traffic Engineering, assuming their intervals are defined in terms of hours or longer. That said, there still is a critical need to recognize that these use cases cou ld use NETCONF/YANG, *but* we need to "encourage" the work to define an appropriate data-model within, probably, NETMOD to carry/exchange the required set of information to/from NE's. Likewise, there's also a need to have a data-model that can work from the Topology Manager to/from the Applications/Client that consume this information. With respect to the latter, is that something that the maybe to-be-formed IRS WG will get tasked with? Or, is there another WG already set-up to do this? If not, can we possibly consider re-chartering an existing WG to do this ... even if the WG doesn't exist in the Routing Area? > > OTOH, where there is a critical requirement for (near-)real-time communication, that's where things get more interesting. As has been pointed out in the past, there was /a lot/ of discussion on the need for a "streaming interface" -- however, the conversation got muddy & stalled out, seemingly because there was an assertion on the need for such a thing, but not the use cases and articulation of what is required in a "streaming interface". IMO, I think that this draft, and others, are hopefully bringing more light to specific use cases to help move the conversation forward. In particular, I think some use cases that are definitely in this category of requiring (near-)real-time communication is: detecting & mitigating DDoS attacks, reactionary Traffic Engineering (i.e.: due to unplanned events), etc. through IRS. I'm sure others can add more to that list. > > Anyway, I hope this helps shed light on why we've chosen, for now, to try to articulate that there may be existing mechanisms/protocols that *could* be used to solve *some* of these use cases, but that more work still needs to be done (i.e.: defining data-models) and we should discuss whether to do that work and, of course, where. Obviously, for those use cases that require (near-)real-time communication, and possibly other requirements that can't be accommodated by today's protocols, that will likely lead to a more focused set of requirements, etc. that will drive a set of short-term deliverables for maybe-to-be-formed IRS WG ... > > Thanks, > > -shane > > >> >> Yours, >> Joel >> >> On 10/3/2012 12:56 AM, Shane Amante wrote: >>> Hi Joel, >>> >>> Thanks for your review. Please see below. >>> >>> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern wrote: >>>> Overall, this looks very helpful. >>>> >>>> In the terminology section, two things struck me: >>>> First, we probably need to consistently qualify the term "Policy Manager". What is described in this document as the "Policy Manager" is a very interesting and powerful function. it is a policy function. But it is no more the entire policy manager than a security policy manager is the entire policy manager. It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree. (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.) >>> >>> We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3. >>> >>> Indeed, a "Policy Management" function is indeed critical. Arguably, it's in the top two most critical elements of this work, IMO. And, you're right that we need to align on definitions for what it is for fear or forever qualifying it. The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc. Is that part clear? Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes. >>> >>> >>>> I have to disagree with the definition of Multi-Layer Topology. I agree that topologies are layered. However, the OSI topology abstraction is absolutely wrong. As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ... >>> >>> Hrm. Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network. The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1]. Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment. In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/. Instead, we need to take the next step. Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*. Only once we do that will it be possible to: >>> a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and, >>> b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding. >>> Ultimately, this is the core essence of SDN/IRS. >>> >>> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc. >>> >>> >>>> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system. (The number of stories of operators failing to meet diversity guarantees are legion.) >>> >>> Really!?!? ;-) >>> >>> More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering": >>> ---snip--- >>> [...] Due to this inefficiency, the >>> underlying physical network inventory information, (containing SRLG >>> and corresponding critical network asset information), used by the >>> IP/MPLS Capacity Planning and TE applications is not updated >>> frequently, thus exposing the network to, at minimum, inefficient >>> utilization and, at worst, critical impairments. >>> ---snip--- >>> >>> >>>> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts. Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described? (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned. >>> >>> I'm not sure I understand the above comment. Can you elaborate? >>> >>> -shane >>> _______________________________________________ >>> irs-discuss mailing list >>> irs-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/irs-discuss >>> >> > > Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D11F0C80 for ; Wed, 3 Oct 2012 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJBeYixY+Pev for ; Wed, 3 Oct 2012 20:45:27 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5401C21F8554 for ; Wed, 3 Oct 2012 20:45:27 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id 09F86EF; Wed, 3 Oct 2012 21:45:23 -0600 (MDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <506C3F71.2020106@joelhalpern.com> Date: Wed, 3 Oct 2012 21:46:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2DE36DA3-AA9A-4071-A34F-CA46F73708FC@castlepoint.net> References: <506BA52E.2060008@joelhalpern.com> <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> <506C3F71.2020106@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1498) Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 03:45:28 -0000 Hi Joel, On Oct 3, 2012, at 7:36 AM, Joel M. Halpern wrote: > Thanks for the prompt and helpful response Shane. >=20 > With regard to the hierarchical topology model, I strongly agree that = we need a model that supports hierarchy / layering / service dependence. > My concern is that the text currently says that the ISO layers are a = good starting point for this. As far as I can tell, the ISO model is a = very bad pace o start developing such a model. OK; however, we need some way to address it. I'd welcome your and = others opinions on a better alternative. > With regard to the configuration protocol, the text talks about = injecting information into the routing protocol instance, or using the = existing configuration tools. Other drafts have talked about the IRS = agent as a new channel, which provides a similar but distinguished set = of configuration. There have also been discussions of how information = gets intoIGPs (directly telling the GP to emit a route vs configuring a = class of static route and having it imported.) It seems to methat this = is an important area, with much work to be done. Thus, it seems simpler = if this draft simply said it would use IRS related confiuration = mechanisms to make its changes, and did not try to categorize or = approximate those. Actually, before submitting the draft we (co-authors) had been having a = debate on this very subject. I think this will be an area of "lively" = discussion, both on the mailing list and in-person. Ultimately, there's likely several dimensions we need to evaluate to = determine what the possibly-to-be-formed IRS WG will work on, what other = (existing) IETF WG's will work on, what _already_exists_ by other IETF = WG's that can get re-used, etc. With respect to the latter, we tried to = recognize that "IRS" does not have to solve for every single use case. = Rather, there are likely classes of use cases where existing (IETF) = protocols are more than adequate to fulfill that need -- some immediate = examples that comes to mind are: NETCONF & YANG. These protocols seem = adequate for use cases where there is no requirement for = (near-)real-time communication/transactions, there is not a substantial = concern about on-the-wire-overhead, etc. Example use cases in this = draft that may fit this criteria are: Cap Planning and Traffic = Engineering, assuming their intervals are defined in terms of hours or = longer. That said, there still is a critical need to recognize that = these use cases could use NETCONF/YANG, *but* we need to "encourage" the = work to define an appropriate data-model within, probably, NETMOD to = carry/exchange the required set of information to/from NE's. Likewise, = there's also a need to have a data-model that can work from the Topology = Manager to/from the Applications/Client that consume this information. = With respect to the latter, is that something that the maybe = to-be-formed IRS WG will get tasked with? Or, is there another WG = already set-up to do this? If not, can we possibly consider = re-chartering an existing WG to do this ... even if the WG doesn't exist = in the Routing Area? OTOH, where there is a critical requirement for (near-)real-time = communication, that's where things get more interesting. As has been = pointed out in the past, there was /a lot/ of discussion on the need for = a "streaming interface" -- however, the conversation got muddy & stalled = out, seemingly because there was an assertion on the need for such a = thing, but not the use cases and articulation of what is required in a = "streaming interface". IMO, I think that this draft, and others, are = hopefully bringing more light to specific use cases to help move the = conversation forward. In particular, I think some use cases that are = definitely in this category of requiring (near-)real-time communication = is: detecting & mitigating DDoS attacks, reactionary Traffic Engineering = (i.e.: due to unplanned events), etc. through IRS. I'm sure others can = add more to that list. Anyway, I hope this helps shed light on why we've chosen, for now, to = try to articulate that there may be existing mechanisms/protocols that = *could* be used to solve *some* of these use cases, but that more work = still needs to be done (i.e.: defining data-models) and we should = discuss whether to do that work and, of course, where. Obviously, for = those use cases that require (near-)real-time communication, and = possibly other requirements that can't be accommodated by today's = protocols, that will likely lead to a more focused set of requirements, = etc. that will drive a set of short-term deliverables for = maybe-to-be-formed IRS WG ... Thanks, -shane >=20 > Yours, > Joel >=20 > On 10/3/2012 12:56 AM, Shane Amante wrote: >> Hi Joel, >>=20 >> Thanks for your review. Please see below. >>=20 >> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern = wrote: >>> Overall, this looks very helpful. >>>=20 >>> In the terminology section, two things struck me: >>> First, we probably need to consistently qualify the term "Policy = Manager". What is described in this document as the "Policy Manager" is = a very interesting and powerful function. it is a policy function. But = it is no more the entire policy manager than a security policy manager = is the entire policy manager. It seems to me that this is a discipline = we need to acquire early, or we will forever find ourselves arguing = about the meaning of terms when we actually agree. (The later = description of the Policy Manager edges into the broader perspective, = but isn't really the same.) >>=20 >> We'll look at making the text in terminology section better align = with the broader definition of a Policy Manager in Section 3.3. >>=20 >> Indeed, a "Policy Management" function is indeed critical. Arguably, = it's in the top two most critical elements of this work, IMO. And, = you're right that we need to align on definitions for what it is for = fear or forever qualifying it. The reason we chose "Policy Manager" is = that it seemed the closest match to what are (likely) considered routine = functions in networking today, namely, "routing policies" (cf: BGP), = "security policies" (cf: ACL preventing/allowing packets through), etc. = Is that part clear? Note, at this stage, we're depicting this as a = single "Policy Manager" function; however, if this work evolves it's = likely this will get broken down into sub-components (security, routing, = etc.) to more precisely define their domain-specific attributes. >>=20 >>=20 >>> I have to disagree with the definition of Multi-Layer Topology. I = agree that topologies are layered. However, the OSI topology = abstraction is absolutely wrong. As was pointed out to me many years = ago, and has become more prevalent ever sine, w run L2 VPN services on = MPLS infrastructure on IP infrastructure, which is in term supported by = Ethernet, some which may actually be emulated Ethernet on MPLS on ... >>=20 >> Hrm. Ultimately, what I think you're describe is a perfect example = of building a specific hierarchical network. The problem is, today, we = *DO NOT* have any (standards-based) way to represent the reality of = those hierarchical relationships /outside of/ the data-plane and = control-plane[1]. Over the years, we've clearly engineered such = hierarchy directly into the routing (and, forwarding) planes of network = equipment. In addition, we've barely enumerated some attributes of = *individual* protocols or network components, (cf: SNMP MIB's), but they = are entirely /standalone/. Instead, we need to take the next step. = Specifically, we need to fully enumerate attributes and, more = importantly, metadata of individual control & data-plane protocols (and, = related network components) using a common, standards-based = *vocabulary*. Only once we do that will it be possible to: >> a) Define hierarchical relationships between network components = (protocols, services, etc.), using the aforementioned = attributes/metadata as filtering/selection criteria, as appropriate; = and, >> b) Summarize all of this vocabulary into schemas/data-models that can = then be exchanged between systems that *DO NOT* (cannot *and* will not) = directly participate in routing & forwarding. >> Ultimately, this is the core essence of SDN/IRS. >>=20 >> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to = determine shortest-path, etc. >>=20 >>=20 >>> While I appreciate the importance of the Inventory function in = evaluating SRLGs, I think the document should probably point out that = this often depends upon physical realities not visible to any automated = system. (The number of stories of operators failing to meet diversity = guarantees are legion.) >>=20 >> Really!?!? ;-) >>=20 >> More seriously, I thought this was made clear in the first two = paragraphs of Section 4.1.1, "Capacity Planning and Traffic = Engineering": >> ---snip--- >> [...] Due to this inefficiency, the >> underlying physical network inventory information, (containing = SRLG >> and corresponding critical network asset information), used by the >> IP/MPLS Capacity Planning and TE applications is not updated >> frequently, thus exposing the network to, at minimum, inefficient >> utilization and, at worst, critical impairments. >> ---snip--- >>=20 >>=20 >>> I find it strange that this draft describes change application using = a different paradigm than the other IRS drafts. Is this deliberate, = indicating that these use cases need a different mechanism than is = elsewhere described? (I wold have simply indicated that the Topology = manager will need to apply changes, and left it there as far as this = document is concerned. >>=20 >> I'm not sure I understand the above comment. Can you elaborate? >>=20 >> -shane >> _______________________________________________ >> irs-discuss mailing list >> irs-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/irs-discuss >>=20 >=20 Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72EF21F846C for ; Wed, 3 Oct 2012 06:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AguDZgQiw-TX for ; Wed, 3 Oct 2012 06:37:01 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E9DFB21F8458 for ; Wed, 3 Oct 2012 06:37:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id B8D7A558057 for ; Wed, 3 Oct 2012 06:37:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8F8D91BD7137; Wed, 3 Oct 2012 06:36:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8F0241BD7133; Wed, 3 Oct 2012 06:36:55 -0700 (PDT) Message-ID: <506C3F71.2020106@joelhalpern.com> Date: Wed, 03 Oct 2012 09:36:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Shane Amante References: <506BA52E.2060008@joelhalpern.com> <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> In-Reply-To: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:37:02 -0000 Thanks for the prompt and helpful response Shane. With regard to the hierarchical topology model, I strongly agree that we need a model that supports hierarchy / layering / service dependence. My concern is that the text currently says that the ISO layers are a good starting point for this. As far as I can tell, the ISO model is a very bad pace o start developing such a model. With regard to the configuration protocol, the text talks about injecting information into the routing protocol instance, or using the existing configuration tools. Other drafts have talked about the IRS agent as a new channel, which provides a similar but distinguished set of configuration. There have also been discussions of how information gets intoIGPs (directly telling the GP to emit a route vs configuring a class of static route and having it imported.) It seems to methat this is an important area, with much work to be done. Thus, it seems simpler if this draft simply said it would use IRS related confiuration mechanisms to make its changes, and did not try to categorize or approximate those. Yours, Joel On 10/3/2012 12:56 AM, Shane Amante wrote: > Hi Joel, > > Thanks for your review. Please see below. > > On Oct 2, 2012, at 8:38 PM, Joel M. Halpern wrote: >> Overall, this looks very helpful. >> >> In the terminology section, two things struck me: >> First, we probably need to consistently qualify the term "Policy Manager". What is described in this document as the "Policy Manager" is a very interesting and powerful function. it is a policy function. But it is no more the entire policy manager than a security policy manager is the entire policy manager. It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree. (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.) > > We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3. > > Indeed, a "Policy Management" function is indeed critical. Arguably, it's in the top two most critical elements of this work, IMO. And, you're right that we need to align on definitions for what it is for fear or forever qualifying it. The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc. Is that part clear? Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes. > > >> I have to disagree with the definition of Multi-Layer Topology. I agree that topologies are layered. However, the OSI topology abstraction is absolutely wrong. As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ... > > Hrm. Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network. The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1]. Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment. In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/. Instead, we need to take the next step. Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*. Only once we do that will it be possible to: > a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and, > b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding. > Ultimately, this is the core essence of SDN/IRS. > > [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc. > > >> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system. (The number of stories of operators failing to meet diversity guarantees are legion.) > > Really!?!? ;-) > > More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering": > ---snip--- > [...] Due to this inefficiency, the > underlying physical network inventory information, (containing SRLG > and corresponding critical network asset information), used by the > IP/MPLS Capacity Planning and TE applications is not updated > frequently, thus exposing the network to, at minimum, inefficient > utilization and, at worst, critical impairments. > ---snip--- > > >> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts. Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described? (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned. > > I'm not sure I understand the above comment. Can you elaborate? > > -shane > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss > Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293DA21F8680 for ; Wed, 3 Oct 2012 05:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=2.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p48UCU8T+sV for ; Wed, 3 Oct 2012 05:49:30 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7C72121F867F for ; Wed, 3 Oct 2012 05:49:29 -0700 (PDT) Received: from mail21-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 12:49:27 +0000 Received: from mail21-am1 (localhost [127.0.0.1]) by mail21-am1-R.bigfish.com (Postfix) with ESMTP id 89A72240104; Wed, 3 Oct 2012 12:49:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:204.154.129.150; KIP:(null); UIP:(null); IPV:NLI; H:usnvwwmspedge02.tellabs-west.tellabsinc.net; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz98dI9371I8fcdK542M1432I604Izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2ei2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: neutral (mail21-am1: 204.154.129.150 is neither permitted nor denied by domain of tellabs.com) client-ip=204.154.129.150; envelope-from=Jonathan.Sadler@tellabs.com; helo=usnvwwmspedge02.tellabs-west.tellabsinc.net ; llabsinc.net ; Received: from mail21-am1 (localhost.localdomain [127.0.0.1]) by mail21-am1 (MessageSwitch) id 1349268565449221_2420; Wed, 3 Oct 2012 12:49:25 +0000 (UTC) Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.249]) by mail21-am1.bigfish.com (Postfix) with ESMTP id 69CF5220109; Wed, 3 Oct 2012 12:49:25 +0000 (UTC) Received: from usnvwwmspedge02.tellabs-west.tellabsinc.net (204.154.129.150) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 12:49:23 +0000 Received: from usnvwwmspht01.tellabs-west.tellabsinc.net (172.23.211.69) by usnvwwmspedge02.tellabs-west.tellabsinc.net (204.154.131.191) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 3 Oct 2012 07:49:09 -0500 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Wed, 3 Oct 2012 07:49:22 -0500 From: "Sadler, Jonathan B." To: Shane Amante , Joel M.Halpern Date: Wed, 3 Oct 2012 07:49:21 -0500 Thread-Topic: [irs-discuss] Comments on Topology API use case document Thread-Index: Ac2hI4bmdhAAIg9XShKxS1diNRROpQAPWIdg Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B01417B01B449@EX-NAP.tellabs-west.tellabsinc.net> References: <506BA52E.2060008@joelhalpern.com> <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> In-Reply-To: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: tellabs.com Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:49:31 -0000 Shane, Joel, et al - You may be interested in modeling work that was done at ITU-T discussing mu= lti-layer topology relationships. The specific document to look at is G.80= 0 (2012): Unified Functional Architecture of Transport Networks. (http://ww= w.itu.int/rec/T-REC-G.800) The specific component in this approach to describing networks that describ= es multi-layer topology relationships is the Transitional Link. See Sectio= n 6.2.1. There was a liaison sent from ITU-T SG 15 to CCAMP that described how this = topological component can be used in multi-layer ODU networks. Please see = SG15 LS221 - Examples of the use of Transitional Links (ITU-T G.709) (https= ://datatracker.ietf.org/liaison/953/). >From this, work has been started on how a transitional link can be represen= ted in link-state routing protocols thereby providing detail of the hierarc= hical relationships to path computation entities. I see strong value in including this in IRS style applications as it enable= s the entity interested in topology to be able to understand all of the det= ails where the service provider wishes it to be known (i.e. subject to poli= cy controls). Jonathan Sadler -----Original Message----- From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On= Behalf Of Shane Amante Sent: Tuesday, October 02, 2012 11:57 PM To: Joel M.Halpern Cc: irs-discuss@ietf.org Subject: Re: [irs-discuss] Comments on Topology API use case document Hi Joel, Thanks for your review. Please see below. On Oct 2, 2012, at 8:38 PM, Joel M. Halpern wrote: > Overall, this looks very helpful. > > In the terminology section, two things struck me: > First, we probably need to consistently qualify the term "Policy Manager"= . What is described in this document as the "Policy Manager" is a very int= eresting and powerful function. it is a policy function. But it is no mor= e the entire policy manager than a security policy manager is the entire po= licy manager. It seems to me that this is a discipline we need to acquire = early, or we will forever find ourselves arguing about the meaning of terms= when we actually agree. (The later description of the Policy Manager edge= s into the broader perspective, but isn't really the same.) We'll look at making the text in terminology section better align with the = broader definition of a Policy Manager in Section 3.3. Indeed, a "Policy Management" function is indeed critical. Arguably, it's = in the top two most critical elements of this work, IMO. And, you're right= that we need to align on definitions for what it is for fear or forever qu= alifying it. The reason we chose "Policy Manager" is that it seemed the cl= osest match to what are (likely) considered routine functions in networking= today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL = preventing/allowing packets through), etc. Is that part clear? Note, at t= his stage, we're depicting this as a single "Policy Manager" function; howe= ver, if this work evolves it's likely this will get broken down into sub-co= mponents (security, routing, etc.) to more precisely define their domain-sp= ecific attributes. > I have to disagree with the definition of Multi-Layer Topology. I agree = that topologies are layered. However, the OSI topology abstraction is abso= lutely wrong. As was pointed out to me many years ago, and has become more= prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP in= frastructure, which is in term supported by Ethernet, some which may actual= ly be emulated Ethernet on MPLS on ... Hrm. Ultimately, what I think you're describe is a perfect example of buil= ding a specific hierarchical network. The problem is, today, we *DO NOT* h= ave any (standards-based) way to represent the reality of those hierarchica= l relationships /outside of/ the data-plane and control-plane[1]. Over the= years, we've clearly engineered such hierarchy directly into the routing (= and, forwarding) planes of network equipment. In addition, we've barely en= umerated some attributes of *individual* protocols or network components, (= cf: SNMP MIB's), but they are entirely /standalone/. Instead, we need to t= ake the next step. Specifically, we need to fully enumerate attributes and= , more importantly, metadata of individual control & data-plane protocols (= and, related network components) using a common, standards-based *vocabular= y*. Only once we do that will it be possible to: a) Define hierarchical relationships between network components (protocols,= services, etc.), using the aforementioned attributes/metadata as filtering= /selection criteria, as appropriate; and, b) Summarize all of this vocabulary into schemas/data-models that can then = be exchanged between systems that *DO NOT* (cannot *and* will not) directly= participate in routing & forwarding. Ultimately, this is the core essence of SDN/IRS. [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine s= hortest-path, etc. > While I appreciate the importance of the Inventory function in evaluating= SRLGs, I think the document should probably point out that this often depe= nds upon physical realities not visible to any automated system. (The numb= er of stories of operators failing to meet diversity guarantees are legion.= ) Really!?!? ;-) More seriously, I thought this was made clear in the first two paragraphs o= f Section 4.1.1, "Capacity Planning and Traffic Engineering": ---snip--- [...] Due to this inefficiency, the underlying physical network inventory information, (containing SRLG and corresponding critical network asset information), used by the IP/MPLS Capacity Planning and TE applications is not updated frequently, thus exposing the network to, at minimum, inefficient utilization and, at worst, critical impairments. ---snip--- > I find it strange that this draft describes change application using a di= fferent paradigm than the other IRS drafts. Is this deliberate, indicating= that these use cases need a different mechanism than is elsewhere describe= d? (I wold have simply indicated that the Topology manager will need to ap= ply changes, and left it there as far as this document is concerned. I'm not sure I understand the above comment. Can you elaborate? -shane _______________________________________________ irs-discuss mailing list irs-discuss@ietf.org https://www.ietf.org/mailman/listinfo/irs-discuss =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089CA21F86C2 for ; Wed, 3 Oct 2012 05:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGC2VnvA-Bzf for ; Wed, 3 Oct 2012 05:10:22 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DB21F86C4 for ; Wed, 3 Oct 2012 05:10:22 -0700 (PDT) Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id C3C3A22D5629; Wed, 3 Oct 2012 08:10:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Thomas Nadeau In-Reply-To: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> Date: Wed, 3 Oct 2012 08:10:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506BA52E.2060008@joelhalpern.com> <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> To: Shane Amante X-Mailer: Apple Mail (2.1498) Cc: "Joel M. Halpern" , "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 12:10:25 -0000 On Oct 3, 2012:12:56 AM, at 12:56 AM, Shane Amante = wrote: > Hi Joel, >=20 > Thanks for your review. Please see below. >=20 > On Oct 2, 2012, at 8:38 PM, Joel M. Halpern = wrote: >> Overall, this looks very helpful. >>=20 >> In the terminology section, two things struck me: >> First, we probably need to consistently qualify the term "Policy = Manager". What is described in this document as the "Policy Manager" is = a very interesting and powerful function. it is a policy function. But = it is no more the entire policy manager than a security policy manager = is the entire policy manager. It seems to me that this is a discipline = we need to acquire early, or we will forever find ourselves arguing = about the meaning of terms when we actually agree. (The later = description of the Policy Manager edges into the broader perspective, = but isn't really the same.) >=20 > We'll look at making the text in terminology section better align with = the broader definition of a Policy Manager in Section 3.3.=20 >=20 > Indeed, a "Policy Management" function is indeed critical. Arguably, = it's in the top two most critical elements of this work, IMO. And, = you're right that we need to align on definitions for what it is for = fear or forever qualifying it. The reason we chose "Policy Manager" is = that it seemed the closest match to what are (likely) considered routine = functions in networking today, namely, "routing policies" (cf: BGP), = "security policies" (cf: ACL preventing/allowing packets through), etc. = Is that part clear? Note, at this stage, we're depicting this as a = single "Policy Manager" function; however, if this work evolves it's = likely this will get broken down into sub-components (security, routing, = etc.) to more precisely define their domain-specific attributes. >=20 >=20 >> I have to disagree with the definition of Multi-Layer Topology. I = agree that topologies are layered. However, the OSI topology = abstraction is absolutely wrong. As was pointed out to me many years = ago, and has become more prevalent ever sine, w run L2 VPN services on = MPLS infrastructure on IP infrastructure, which is in term supported by = Ethernet, some which may actually be emulated Ethernet on MPLS on ... >=20 > Hrm. Ultimately, what I think you're describe is a perfect example of = building a specific hierarchical network. The problem is, today, we *DO = NOT* have any (standards-based) way to represent the reality of those = hierarchical relationships /outside of/ the data-plane and = control-plane[1]. Over the years, we've clearly engineered such = hierarchy directly into the routing (and, forwarding) planes of network = equipment. In addition, we've barely enumerated some attributes of = *individual* protocols or network components, (cf: SNMP MIB's), but they = are entirely /standalone/. Instead, we need to take the next step. = Specifically, we need to fully enumerate attributes and, more = importantly, metadata of individual control & data-plane protocols (and, = related network components) using a common, standards-based = *vocabulary*. Only once we do that will it be possible to: > a) Define hierarchical relationships between network components = (protocols, services, etc.), using the aforementioned = attributes/metadata as filtering/selection criteria, as appropriate; = and, > b) Summarize all of this vocabulary into schemas/data-models that can = then be exchanged between systems that *DO NOT* (cannot *and* will not) = directly participate in routing & forwarding. > Ultimately, this is the core essence of SDN/IRS. >=20 > [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to = determine shortest-path, etc. Just to add to this. Joel, while I agree with you RE: the "OSI = topology", we are not trying to enumerate EVERYTHING in the network nor = are we out to incarnate those theoretical layers. Ultimately what we = want is to represent different abstractions of topology that are used = for routing/switching. This is really a matter of grouping = links/ports/nodes, their facets, and then connecting or relating them = together. This then can represent active and inactive topological = elements in arbitrary ways, but more importantly, how they really exist = within one's network versus a theoretical model (i.e.: OSI).=20 >> While I appreciate the importance of the Inventory function in = evaluating SRLGs, I think the document should probably point out that = this often depends upon physical realities not visible to any automated = system. (The number of stories of operators failing to meet diversity = guarantees are legion.) >=20 > Really!?!? ;-) >=20 > More seriously, I thought this was made clear in the first two = paragraphs of Section 4.1.1, "Capacity Planning and Traffic = Engineering": > ---snip--- > [...] Due to this inefficiency, the > underlying physical network inventory information, (containing SRLG > and corresponding critical network asset information), used by the > IP/MPLS Capacity Planning and TE applications is not updated > frequently, thus exposing the network to, at minimum, inefficient > utilization and, at worst, critical impairments. > ---snip--- >=20 >=20 >> I find it strange that this draft describes change application using = a different paradigm than the other IRS drafts. Is this deliberate, = indicating that these use cases need a different mechanism than is = elsewhere described? (I wold have simply indicated that the Topology = manager will need to apply changes, and left it there as far as this = document is concerned. >=20 > I'm not sure I understand the above comment. Can you elaborate? I agree; I am confused. The draft does not (intentionally) = describe any specific mechanisms; the aim was to describe how normalized = topology could be used. We have a forth coming requirements draft that = further elaborates on what components need to exist in order for these = use cases to work. --Tom >=20 > -shane > _______________________________________________ > irs-discuss mailing list > irs-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/irs-discuss >=20 Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6821F86A1 for ; Tue, 2 Oct 2012 21:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuRVSD5dvSXR for ; Tue, 2 Oct 2012 21:56:37 -0700 (PDT) Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1329321F869E for ; Tue, 2 Oct 2012 21:56:37 -0700 (PDT) Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id E65C46BF; Tue, 2 Oct 2012 22:56:33 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Shane Amante In-Reply-To: <506BA52E.2060008@joelhalpern.com> Date: Tue, 2 Oct 2012 22:56:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net> References: <506BA52E.2060008@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1498) Cc: "irs-discuss@ietf.org" Subject: Re: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 04:56:37 -0000 Hi Joel, Thanks for your review. Please see below. On Oct 2, 2012, at 8:38 PM, Joel M. Halpern wrote: > Overall, this looks very helpful. >=20 > In the terminology section, two things struck me: > First, we probably need to consistently qualify the term "Policy = Manager". What is described in this document as the "Policy Manager" is = a very interesting and powerful function. it is a policy function. But = it is no more the entire policy manager than a security policy manager = is the entire policy manager. It seems to me that this is a discipline = we need to acquire early, or we will forever find ourselves arguing = about the meaning of terms when we actually agree. (The later = description of the Policy Manager edges into the broader perspective, = but isn't really the same.) We'll look at making the text in terminology section better align with = the broader definition of a Policy Manager in Section 3.3.=20 Indeed, a "Policy Management" function is indeed critical. Arguably, = it's in the top two most critical elements of this work, IMO. And, = you're right that we need to align on definitions for what it is for = fear or forever qualifying it. The reason we chose "Policy Manager" is = that it seemed the closest match to what are (likely) considered routine = functions in networking today, namely, "routing policies" (cf: BGP), = "security policies" (cf: ACL preventing/allowing packets through), etc. = Is that part clear? Note, at this stage, we're depicting this as a = single "Policy Manager" function; however, if this work evolves it's = likely this will get broken down into sub-components (security, routing, = etc.) to more precisely define their domain-specific attributes. > I have to disagree with the definition of Multi-Layer Topology. I = agree that topologies are layered. However, the OSI topology = abstraction is absolutely wrong. As was pointed out to me many years = ago, and has become more prevalent ever sine, w run L2 VPN services on = MPLS infrastructure on IP infrastructure, which is in term supported by = Ethernet, some which may actually be emulated Ethernet on MPLS on ... Hrm. Ultimately, what I think you're describe is a perfect example of = building a specific hierarchical network. The problem is, today, we *DO = NOT* have any (standards-based) way to represent the reality of those = hierarchical relationships /outside of/ the data-plane and = control-plane[1]. Over the years, we've clearly engineered such = hierarchy directly into the routing (and, forwarding) planes of network = equipment. In addition, we've barely enumerated some attributes of = *individual* protocols or network components, (cf: SNMP MIB's), but they = are entirely /standalone/. Instead, we need to take the next step. = Specifically, we need to fully enumerate attributes and, more = importantly, metadata of individual control & data-plane protocols (and, = related network components) using a common, standards-based = *vocabulary*. Only once we do that will it be possible to: a) Define hierarchical relationships between network components = (protocols, services, etc.), using the aforementioned = attributes/metadata as filtering/selection criteria, as appropriate; = and, b) Summarize all of this vocabulary into schemas/data-models that can = then be exchanged between systems that *DO NOT* (cannot *and* will not) = directly participate in routing & forwarding. Ultimately, this is the core essence of SDN/IRS. [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to = determine shortest-path, etc. > While I appreciate the importance of the Inventory function in = evaluating SRLGs, I think the document should probably point out that = this often depends upon physical realities not visible to any automated = system. (The number of stories of operators failing to meet diversity = guarantees are legion.) Really!?!? ;-) More seriously, I thought this was made clear in the first two = paragraphs of Section 4.1.1, "Capacity Planning and Traffic = Engineering": ---snip--- [...] Due to this inefficiency, the underlying physical network inventory information, (containing SRLG and corresponding critical network asset information), used by the IP/MPLS Capacity Planning and TE applications is not updated frequently, thus exposing the network to, at minimum, inefficient utilization and, at worst, critical impairments. ---snip--- > I find it strange that this draft describes change application using a = different paradigm than the other IRS drafts. Is this deliberate, = indicating that these use cases need a different mechanism than is = elsewhere described? (I wold have simply indicated that the Topology = manager will need to apply changes, and left it there as far as this = document is concerned. I'm not sure I understand the above comment. Can you elaborate? -shane= Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673C21F846C for ; Tue, 2 Oct 2012 19:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.092 X-Spam-Level: X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFljlVEsRl5b for ; Tue, 2 Oct 2012 19:38:50 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 891CB21F845D for ; Tue, 2 Oct 2012 19:38:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 422C7A6B60 for ; Tue, 2 Oct 2012 19:38:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9386A1814C3 for ; Tue, 2 Oct 2012 19:38:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 20FAF1814C2 for ; Tue, 2 Oct 2012 19:38:42 -0700 (PDT) Message-ID: <506BA52E.2060008@joelhalpern.com> Date: Tue, 02 Oct 2012 22:38:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "irs-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [irs-discuss] Comments on Topology API use case document X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 02:38:51 -0000 Overall, this looks very helpful. In the terminology section, two things struck me: First, we probably need to consistently qualify the term "Policy Manager". What is described in this document as the "Policy Manager" is a very interesting and powerful function. it is a policy function. But it is no more the entire policy manager than a security policy manager is the entire policy manager. It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree. (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.) I have to disagree with the definition of Multi-Layer Topology. I agree that topologies are layered. However, the OSI topology abstraction is absolutely wrong. As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ... While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system. (The number of stories of operators failing to meet diversity guarantees are legion.) I find it strange that this draft describes change application using a different paradigm than the other IRS drafts. Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described? (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned. Yours, Jo9el M. Halpern Return-Path: X-Original-To: irs-discuss@ietfa.amsl.com Delivered-To: irs-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7B121F861E for ; Tue, 2 Oct 2012 15:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRVwwMlCZdYC for ; Tue, 2 Oct 2012 15:45:56 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62721F8602 for ; Tue, 2 Oct 2012 15:45:56 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUGtuo1iyAfTT/lP/iOPwEPZ7rHS558DM@postini.com; Tue, 02 Oct 2012 15:45:56 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Oct 2012 15:39:44 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Oct 2012 15:39:44 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Oct 2012 15:41:41 -0700 Received: from mail71-co1-R.bigfish.com (10.243.78.239) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 22:39:43 +0000 Received: from mail71-co1 (localhost [127.0.0.1]) by mail71-co1-R.bigfish.com (Postfix) with ESMTP id 9815AB401B1 for ; Tue, 2 Oct 2012 22:39:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zf7Iz9371I936eIc85fhzz1202h1d1ah1d2ahz31iz8275ch1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail71-co1 (localhost.localdomain [127.0.0.1]) by mail71-co1 (MessageSwitch) id 1349217581223162_11472; Tue, 2 Oct 2012 22:39:41 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.237]) by mail71-co1.bigfish.com (Postfix) with ESMTP id 32D8FB80044 for ; Tue, 2 Oct 2012 22:39:41 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 22:39:38 +0000 Received: from CH1PRD0511MB420.namprd05.prod.outlook.com ([169.254.1.143]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0190.008; Tue, 2 Oct 2012 22:39:35 +0000 From: Thomas Nadeau To: "" Thread-Topic: New Version Notification for draft-amante-irs-topology-use-cases-00.txt Thread-Index: AQHNoOvkrNrRhTLtiEma3CnFkbBMzpemm8BJ Date: Tue, 2 Oct 2012 22:39:35 +0000 Message-ID: <4C43CAD2-093B-4795-8CB9-3A713B914B44@juniper.net> References: <20121002221835.25341.54971.idtracker@ietfa.amsl.com> In-Reply-To: <20121002221835.25341.54971.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.196.224] Content-Type: multipart/alternative; boundary="_000_4C43CAD2093B47958CB93A713B914B44junipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt X-BeenThere: irs-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 22:45:57 -0000 --_000_4C43CAD2093B47958CB93A713B914B44junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: From: > Date: October 2, 2012, 6:18:35 PM EDT To: > Cc: >, > Subject: New Version Notification for draft-amante-irs-topology-use-cases-0= 0.txt A new version of I-D, draft-amante-irs-topology-use-cases-00.txt has been successfully submitted by Jan Medved and posted to the IETF repository. Filename: draft-amante-irs-topology-use-cases Revision: 00 Title: Topology API Use Cases Creation date: 2012-10-02 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-amante-irs-topol= ogy-use-cases-00.txt Status: http://datatracker.ietf.org/doc/draft-amante-irs-topology-= use-cases Htmlized: http://tools.ietf.org/html/draft-amante-irs-topology-use-c= ases-00 Abstract: This document describes use cases for gathering routing, forwarding and policy information, (hereafter referred to as topology information), about the network and reflecting changes to the topology back into the network and related systems. It describes several applications that need to view or change the topology of the underlying physical or logical network. This document further demonstrates a need for a "Topology Manager" and related functions that collects topology data from network elements and other data sources, coalesces the collected data into a coherent view of the overall network topology, and normalizes the network topology view for use by clients -- namely, applications that consume or want to change topology information. The IETF Secretariat --_000_4C43CAD2093B47958CB93A713B914B44junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable



Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: October 2, 2012, 6:18:35 PM EDT
To: <jmedved@cisco.com&g= t;
Cc: <tnadeau@juniper.net>, <shane@level3.net> Subject: New Version Notification for draft-amante-irs-topology-u= se-cases-00.txt


A new version of I-D, draft-amante-irs-topology-use-cases-00.txt
has been successfully submitted by Jan Medved and posted to the
IETF repository.

Filename:     draft-amante-irs-topology-use-cases Revision:     00
Title:         Topology API Use Cases
Creation date:     2012-10-02
WG ID:         Individual Submission
Number of pages: 21
URL:           &nbs= p; http://www.ietf.org/internet-drafts/draft-amante-ir= s-topology-use-cases-00.txt
Status:          ht= tp://datatracker.ietf.org/doc/draft-amante-irs-topology-use-cases
Htmlized:        http://tools.i= etf.org/html/draft-amante-irs-topology-use-cases-00


Abstract:
  This document describes use cases for gathering routing, = forwarding
  and policy information, (hereafter referred to as topolog= y
  information), about the network and reflecting changes to= the
  topology back into the network and related systems.  = ;It describes
  several applications that need to view or change the topo= logy of the
  underlying physical or logical network.  This docume= nt further
  demonstrates a need for a "Topology Manager" an= d related functions
  that collects topology data from network elements and oth= er data
  sources, coalesces the collected data into a coherent vie= w of the
  overall network topology, and normalizes the network topo= logy view
  for use by clients -- namely, applications that consume o= r want to
  change topology information.




The IETF Secretariat


--_000_4C43CAD2093B47958CB93A713B914B44junipernet_--