From shane@castlepoint.net Sat Dec 1 07:42:26 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399421F0C5C for ; Sat, 1 Dec 2012 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, 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 Vm6jdR4LUhgA for ; Sat, 1 Dec 2012 07:42:25 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 73C581F0C49 for ; Sat, 1 Dec 2012 07:42:25 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8B5D82412 for ; Sat, 1 Dec 2012 15:42:24 +0000 (UTC) Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 9A20D240D; Sat, 1 Dec 2012 08:42:23 -0700 (MST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D76CF1E-FD5C-4655-B85E-F46DAD7A58D7" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Shane Amante In-Reply-To: Date: Sat, 1 Dec 2012 08:42:22 -0700 Message-Id: References: <00ef01cdc64a$37284d00$a578e700$@olddog.co.uk> <50B4F55E.5000503@riw.us> To: Alia Atlas X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Dec 1 08:42:24 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 50ba2560199632166987402 X-DSPAM-Factors: 27, should+#+#+to, 0.40000, should+#+#+to, 0.40000, to+#+#+#+an, 0.40000, to+#+#+#+an, 0.40000, to+#+#+#+to, 0.40000, to+#+#+#+to, 0.40000, easily+#+#+#+forwarding, 0.40000, easily+#+#+#+forwarding, 0.40000, is+#+#+part, 0.40000, is+#+#+part, 0.40000, know+#+#+#+it, 0.40000, know+#+#+#+it, 0.40000, 27+#+#+11, 0.40000, 27+#+#+11, 0.40000, complete+#+of, 0.40000, complete+#+of, 0.40000, I+#+#+#+include, 0.40000, I+#+#+#+include, 0.40000, think+that, 0.40000, think+that, 0.40000, is+#+#+#+of, 0.40000, is+#+#+#+of, 0.40000, plane+#+#+that, 0.40000, plane+#+#+that, 0.40000, network+such, 0.40000, network+such, 0.40000, 1+#+#+#+Tue, 0.40000 Cc: Russ White , i2rs@ietf.org Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:42:26 -0000 --Apple-Mail=_4D76CF1E-FD5C-4655-B85E-F46DAD7A58D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 27, 2012, at 11:50 AM, Alia Atlas wrote: > I think it should include control plane protocols as well. The first = focus is RIB-based use-cases, which seem to be easily tied to a = forwarding plane. However, the BGP-based policy cases and topology = cases do not need to be co-located with a forwarding plane and, if that = portion of the routing system is supported by a software entity, I think = that I2RS should be able to handle that as well. >=20 > I feel that restricting the routing system to only those with an = attached forwarding plane (physical or virtual) is unnecessarily = restrictive and we already know of cases where it may not be sufficient. +1. -shane > Alia=20 >=20 >=20 > On Tue, Nov 27, 2012 at 12:16 PM, Russ White wrote: >=20 > This looks good --nice, well defined scope and strong requirements > language. The only question I have is: >=20 > =3D=3D > A routing system is all or part of a routing network such as an > interface, a collection of interfaces, a router, or a collection of = routers. > =3D=3D >=20 > Should this include the control plane protocols, as well? The positive > would be to provide a (more) complete description of a routing system, > the negative is this might be seen as bringing interaction with > protocols into the charter. >=20 > Thoughts? >=20 > :-) >=20 > Russ >=20 > -- > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_4D76CF1E-FD5C-4655-B85E-F46DAD7A58D7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Nov 27, 2012, at 11:50 AM, Alia Atlas <akatlas@gmail.com> wrote:
I think it should include control plane protocols as well.  The first focus is RIB-based use-cases, which seem to be easily tied to a forwarding plane.  However, the BGP-based policy cases and topology cases do not need to be co-located with a forwarding plane and, if that portion of the routing system is supported by a software entity, I think that I2RS should be able to handle that as well.

I feel that restricting the routing system to only those with an attached forwarding plane (physical or virtual) is unnecessarily restrictive and we already know of cases where it may not be sufficient.

+1.

-shane



Alia


On Tue, Nov 27, 2012 at 12:16 PM, Russ White <russw@riw.us> wrote:

This looks good --nice, well defined scope and strong requirements
language. The only question I have is:

==
A routing system is all or part of a routing network such as an
interface, a collection of interfaces, a router, or a collection of routers.
==

Should this include the control plane protocols, as well? The positive
would be to provide a (more) complete description of a routing system,
the negative is this might be seen as bringing interaction with
protocols into the charter.

Thoughts?

:-)

Russ

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

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--Apple-Mail=_4D76CF1E-FD5C-4655-B85E-F46DAD7A58D7-- From daniel@olddog.co.uk Sat Dec 1 15:03:33 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3623411E80A5 for ; Sat, 1 Dec 2012 15:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwrHScbI1cGV for ; Sat, 1 Dec 2012 15:03:32 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7AF11E8099 for ; Sat, 1 Dec 2012 15:03:32 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB1N3UGB014992; Sat, 1 Dec 2012 23:03:30 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB1N3TcM014985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 23:03:29 GMT From: "Daniel King" To: Date: Sat, 1 Dec 2012 23:03:23 -0000 Message-ID: <002501cdd018$10b9d8a0$322d89e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3QF9CAMbjzlPS2TMags2UXfVKSKw== Content-Language: en-gb Cc: adrian@olddog.co.uk, daniel@olddog.co.uk Subject: [i2rs] A new draft on an architecture for application-based network operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 23:03:33 -0000 Dear i2rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of the puzzle seem to have been coagulating, we thought it might be nice to build a framework in which the jelly (jello) can set. It is at a really early stage, so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them. - An attempt to supply pointers to existing work (tool kit) where that may be applicable and there are some use case examples to give a feel for how it all works. - Various ABNO use cases. A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status. We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outside the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian From mohamed.boucadair@orange.com Mon Dec 3 04:19:55 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4274121F86CF for ; Mon, 3 Dec 2012 04:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.037, 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 28SkSGX73BNy for ; Mon, 3 Dec 2012 04:19:54 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id F06A821F86C0 for ; Mon, 3 Dec 2012 04:19:53 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DA87C22CDA1; Mon, 3 Dec 2012 13:19:51 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 8C89E23805C; Mon, 3 Dec 2012 13:19:51 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 3 Dec 2012 13:19:49 +0100 From: To: Daniel King , "i2rs@ietf.org" Date: Mon, 3 Dec 2012 13:19:46 +0100 Thread-Topic: [i2rs] A new draft on an architecture for application-based network operations Thread-Index: Ac3QF9CAMbjzlPS2TMags2UXfVKSKwBLJhgQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2DB36@PUEXCB1B.nanterre.francetelecom.fr> References: <002501cdd018$10b9d8a0$322d89e0$@olddog.co.uk> In-Reply-To: <002501cdd018$10b9d8a0$322d89e0$@olddog.co.uk> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" 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.12.3.113318 Cc: "adrian@olddog.co.uk" , JACQUENET Christian OLNC/OLN Subject: Re: [i2rs] A new draft on an architecture for application-based network operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 12:19:55 -0000 Dear Daniel, I read this draft and I was interested in Section 3.1 (http://tools.ietf.or= g/html/draft-farrkingel-pce-abno-architecture-00#section-3.1).=20 The current text makes no assumption whether administrative setup is needed= before sending any request to reserve some inter-domain resources. FWIW, w= e have edited in the past this document: http://tools.ietf.org/html/draft-b= oucadair-pce-interas-01. Two types of agreements are needed for such model:= (1) between adjacent domains and (2) between the entities managing the end= ASes which will terminate LSPs. This document uses COPS to put into effect= computed inter-domain LSPs. The document proposes also: a solution to disc= over a remote AS is supporting the PCE service, a solution to avoid adverti= sing the IP addresses of routers which are candidate to be tail/head end of= an inter-domain LSP, etc. A demo of the full system can be found here: htt= p://www.ist-mescal.org/roadmap/pcs-demo.avi Since 2005 (at the edited that document), there are several advances. It wo= uld be valuable to explain what is the added value of the i2rs approach for= this use case compared to what was proposed in the document cited above.=20 Cheers, Med =20 >-----Message d'origine----- >De : i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] De=20 >la part de Daniel King >Envoy=E9 : dimanche 2 d=E9cembre 2012 00:03 >=C0 : i2rs@ietf.org >Cc : adrian@olddog.co.uk; daniel@olddog.co.uk >Objet : [i2rs] A new draft on an architecture for=20 >application-based network operations > >Dear i2rs, > >Adrian and I posted an I-D which is a rather grandiose attempt to pull >together a number of existing architectural components (PCE,=20 >VNTM, I2RS, >policy, etc., etc.). This is a sort of meta-SDN PCE-based=20 >architect-thingy. >It needed a name, so we called it Application-Based Network Operations >(ABNO), warning it's not house trained and may answer to various other >names: > >A PCE-based Architecture for Application-based Network Operations >http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 > >As some of you will know this is the result of numerous=20 >discussions we have >had with a number of people over the last three months. Where=20 >pieces of the >puzzle seem to have been coagulating, we thought it might be=20 >nice to build a >framework in which the jelly (jello) can set. It is at a=20 >really early stage, >so we are convinced you will all throw stuff at us, but what the hell! > >As it stands, the current draft includes: > >- A brief description of abstraction functional components and the >interfaces between them.=20 >- An attempt to supply pointers to existing work (tool kit)=20 >where that may >be applicable and there are some use case examples to give a=20 >feel for how it >all works. >- Various ABNO use cases.=20 > >A number of areas need further discussion, especially the use cases. We >decided to submit with the few we do have, in order to generate some >feedback - anyone who wants to supply use case(s) and text,=20 >would receive >hero status.=20 > >We have pitched the document as a PCE working group document=20 >because PCE is >a central component, but the document doesn't really fall=20 >inside the PCE >charter. For the time being it might be best to send comments=20 >direct to us >rather than clutter up any WG mailing list with discussions=20 >that are outside >the charter (but if some WG chair wants to claim the work, then...) > >Thanks, >Dan and Adrian > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs >= From adrian@olddog.co.uk Mon Dec 3 06:22:18 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5206721F86D8 for ; Mon, 3 Dec 2012 06:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 DTlYoG+c3Jb9 for ; Mon, 3 Dec 2012 06:22:17 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBD21F86D2 for ; Mon, 3 Dec 2012 06:22:16 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB3EMF8W009252; Mon, 3 Dec 2012 14:22:15 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB3EMD6g009209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 14:22:14 GMT From: "Adrian Farrel" To: , "'Daniel King'" References: <002501cdd018$10b9d8a0$322d89e0$@olddog.co.uk> <94C682931C08B048B7A8645303FDC9F36E99E2DB36@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2DB36@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 3 Dec 2012 14:22:11 -0000 Message-ID: <01d201cdd161$9679ccd0$c36d6670$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIRerrt+F97dCOSYhxSn1UglXyplgJ5RAYcl2wBV4A= Content-Language: en-gb Cc: i2rs@ietf.org, 'JACQUENET Christian OLNC/OLN' Subject: Re: [i2rs] A new draft on an architecture for application-based network operations X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 14:22:18 -0000 Hi Med, Thanks for your comments. Because you responded on the I2RS list, I will as well, but maybe we = should take this off-list to avoid gumming up the charter discussions with something = that is pretty-much off-topic. In short, you are right that there are commercial and administrative = policies that come into play. If I recall right, your I-D was by way of an = applicability statement showing how the PCE blocks could fit together. It might be = interesting to review your work in the light of hierarchical PCE to see how that all = bolts together. We will look at how we can add some further explanation of the = interactions of policy in this process to the example in Section 3.1 (without turning = this into a full and detailed blow-by-blow explanation). Would surely welcome your = input. You ask what value is added by the I2RS approach to the inter-AS setup = described in Section 3.1. My answer: none. And that is why the example in 3.1 does = not mention I2RS. Cheers, Adrian > I read this draft and I was interested in Section 3.1 > = (http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00#sec= tion- > 3.1). >=20 > The current text makes no assumption whether administrative setup is = needed > before sending any request to reserve some inter-domain resources. = FWIW, we > have edited in the past this document: = http://tools.ietf.org/html/draft- > boucadair-pce-interas-01. Two types of agreements are needed for such = model: > (1) between adjacent domains and (2) between the entities managing the = end > ASes which will terminate LSPs. This document uses COPS to put into = effect > computed inter-domain LSPs. The document proposes also: a solution to = discover > a remote AS is supporting the PCE service, a solution to avoid = advertising the IP > addresses of routers which are candidate to be tail/head end of an inter-domain > LSP, etc. A demo of the full system can be found here: http://www.ist- > mescal.org/roadmap/pcs-demo.avi >=20 > Since 2005 (at the edited that document), there are several advances. = It would be > valuable to explain what is the added value of the i2rs approach for = this use case > compared to what was proposed in the document cited above. >=20 > Cheers, > Med >=20 >=20 > >-----Message d'origine----- > >De : i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] De > >la part de Daniel King > >Envoy=E9 : dimanche 2 d=E9cembre 2012 00:03 > >=C0 : i2rs@ietf.org > >Cc : adrian@olddog.co.uk; daniel@olddog.co.uk > >Objet : [i2rs] A new draft on an architecture for > >application-based network operations > > > >Dear i2rs, > > > >Adrian and I posted an I-D which is a rather grandiose attempt to = pull > >together a number of existing architectural components (PCE, > >VNTM, I2RS, > >policy, etc., etc.). This is a sort of meta-SDN PCE-based > >architect-thingy. > >It needed a name, so we called it Application-Based Network = Operations > >(ABNO), warning it's not house trained and may answer to various = other > >names: > > > >A PCE-based Architecture for Application-based Network Operations > >http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 > > > >As some of you will know this is the result of numerous > >discussions we have > >had with a number of people over the last three months. Where > >pieces of the > >puzzle seem to have been coagulating, we thought it might be > >nice to build a > >framework in which the jelly (jello) can set. It is at a > >really early stage, > >so we are convinced you will all throw stuff at us, but what the = hell! > > > >As it stands, the current draft includes: > > > >- A brief description of abstraction functional components and the > >interfaces between them. > >- An attempt to supply pointers to existing work (tool kit) > >where that may > >be applicable and there are some use case examples to give a > >feel for how it > >all works. > >- Various ABNO use cases. > > > >A number of areas need further discussion, especially the use cases. = We > >decided to submit with the few we do have, in order to generate some > >feedback - anyone who wants to supply use case(s) and text, > >would receive > >hero status. > > > >We have pitched the document as a PCE working group document > >because PCE is > >a central component, but the document doesn't really fall > >inside the PCE > >charter. For the time being it might be best to send comments > >direct to us > >rather than clutter up any WG mailing list with discussions > >that are outside > >the charter (but if some WG chair wants to claim the work, then...) > > > >Thanks, > >Dan and Adrian > > > >_______________________________________________ > >i2rs mailing list > >i2rs@ietf.org > >https://www.ietf.org/mailman/listinfo/i2rs > >=3D From ramk@Brocade.com Mon Dec 3 08:56:19 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F2921F849A for ; Mon, 3 Dec 2012 08:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_MOSTLY=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 1Q5hNfdK4FYP for ; Mon, 3 Dec 2012 08:56:19 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05C21F847F for ; Mon, 3 Dec 2012 08:56:19 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id qB3GlkgM015089 for ; Mon, 3 Dec 2012 08:56:19 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1901t5rkgu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 03 Dec 2012 08:56:18 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 3 Dec 2012 08:56:18 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 3 Dec 2012 08:56:17 -0800 From: ramki Krishnan To: "i2rs@ietf.org" Date: Mon, 3 Dec 2012 08:56:10 -0800 Thread-Topic: test message - please ignore Thread-Index: Ac3RdxhGabRxnF61SSOTVP07LALvgA== 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_C7634EB63EFD984A978DFB46EA5174F2BF4FA69E87HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=4 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1212030128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185, 1.0.431, 0.0.0000 definitions=2012-12-03_04:2012-12-03, 2012-12-03, 1970-01-01 signatures=0 Subject: [i2rs] test message - please ignore X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 16:56:20 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FA69E87HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FA69E87HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

<= /html>= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4FA69E87HQ1EXCH01corp_-- From lberger@labn.net Thu Dec 6 03:48:29 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B899021F869C for ; Thu, 6 Dec 2012 03:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.805 X-Spam-Level: X-Spam-Status: No, score=-101.805 tagged_above=-999 required=5 tests=[AWL=0.460, 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 f2-aJfZ5ZriK for ; Thu, 6 Dec 2012 03:48:28 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 6B8CD21F859A for ; Thu, 6 Dec 2012 03:48:28 -0800 (PST) Received: (qmail 11207 invoked by uid 0); 6 Dec 2012 11:48:06 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 6 Dec 2012 11:48: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=DU8p1xJOn0AxMZiwz8LLOhlsv+wcKNCAT+zlMOALQk0=; b=pJxR28h55PJR1c0axNaKN0LX8wQPBkFrc5Jj/QVG5QGrD7+rK03Mf+AiRn1990QzcCpaTf6iQeLvEqag4EsmmLjYaA8Ntx1pWGju/alsUzFEmGTCrggWFGL/lASGNRZ+; Received: from box313.bluehost.com ([69.89.31.113]:42845 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TgZvx-0002W8-SC; Thu, 06 Dec 2012 04:48:06 -0700 Message-ID: <50C085F6.1080502@labn.net> Date: Thu, 06 Dec 2012 06:48:06 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Nagendra Kumar (naikumar)" References: <20121128024106.C4F1D18C089@mercury.lcs.mit.edu> <47E76F08F1BCF5458111C1939C7B9C460FEC24C8@xmb-rcd-x03.cisco.com> In-Reply-To: <47E76F08F1BCF5458111C1939C7B9C460FEC24C8@xmb-rcd-x03.cisco.com> X-Enigmail-Version: 1.4.6 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: "i2rs@ietf.org" , Noel Chiappa Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 11:48:29 -0000 Why not data plane interface? (Control plane and data plane, and their distinction, are not exactly new terms/concepts...) Lou On 11/27/2012 10:30 PM, Nagendra Kumar (naikumar) wrote: > Or May be some thing like Control Plane interface (CPi) and Data Forwarding/Forwarder interface (DFi)?. > > -Nagendra > > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Noel Chiappa > Sent: Wednesday, November 28, 2012 8:11 AM > To: i2rs@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [i2rs] Progressing the chartering effort > > > From: "Zach Seils (seils)" > > > What about simple "control interface" and "data interface" designations? > > "Control interface" I like. I'm a lot less sold on "data interface" - it sonuds like some sort of programmatic thing, rather that (usually) a piece of hardware over which user data packets are sent. > > 'Physical interface' for the latter is probably not optimal, now that I think about it; we probably want to support virtual interfaces as well. How about 'network interface', though? > > Noel > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > From russw@riw.us Thu Dec 6 09:10:48 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E095721F87D4 for ; Thu, 6 Dec 2012 09:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkIP8aTRzWqV for ; Thu, 6 Dec 2012 09:10:48 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7361321F87D2 for ; Thu, 6 Dec 2012 09:10:48 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TgeyF-0004RS-Ec for i2rs@ietf.org; Thu, 06 Dec 2012 09:10:47 -0800 Message-ID: <50C0D1A5.6080405@riw.us> Date: Thu, 06 Dec 2012 12:11:01 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <20121128024106.C4F1D18C089@mercury.lcs.mit.edu> <47E76F08F1BCF5458111C1939C7B9C460FEC24C8@xmb-rcd-x03.cisco.com> <50C085F6.1080502@labn.net> In-Reply-To: <50C085F6.1080502@labn.net> 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: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:10:49 -0000 > Why not data plane interface? (Control plane and data plane, and their > distinction, are not exactly new terms/concepts...) Several thoughts... First, I see this as a scoping problem. Trying to create both a control plane and a data plane interface at the same time opens an entire can of worms that I don't know if we want to address. Chewable chunks. Second, there's a lot of other "stuff" going on in the data plane interface area, while there's almost none (or rather none) going on in the control plane interface area. Third, a control plane interface assumes an underlying hybrid model, which fits most of the unique use cases articulated to this point. So, I wouldn't say we should rule out a data plane interface forever, but rather that we should rule it out for right now --focus on that which is different, and then move towards the more common if the need arises or the work seems worth doing at some point in the future. At least that's my thinking. :-) Russ -- <>< riwhite@verisign.com russw@riw.us From jnc@mercury.lcs.mit.edu Thu Dec 6 09:21:02 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE57621F87DD for ; Thu, 6 Dec 2012 09:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPLJk-caq7Eo for ; Thu, 6 Dec 2012 09:21:02 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7E29D21F87C0 for ; Thu, 6 Dec 2012 09:21:02 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5FFC218C167; Thu, 6 Dec 2012 12:21:01 -0500 (EST) To: i2rs@ietf.org Message-Id: <20121206172101.5FFC218C167@mercury.lcs.mit.edu> Date: Thu, 6 Dec 2012 12:21:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:21:03 -0000 > From: Lou Berger >> How about 'network interface', though? > Why not data plane interface? The problem is that that's facially ambiguous: does it mean 'an interface to the data plane to allow control plane entities to manage the operation of the data plane', or does it mean 'an interface over which the data plane transfers user data'? I know, I know, technically "network interface" has the same potential ambiguities, but I think there's enough history in that term that most people's first thought on seeing it is "thing that attaches a box into a particulr network". Noel From lberger@labn.net Thu Dec 6 10:45:30 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0711021F8826 for ; Thu, 6 Dec 2012 10:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[AWL=0.427, 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 j6uxSft8B-Tx for ; Thu, 6 Dec 2012 10:45:29 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 591C621F8545 for ; Thu, 6 Dec 2012 10:45:29 -0800 (PST) Received: (qmail 17051 invoked by uid 0); 6 Dec 2012 18:45:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 6 Dec 2012 18:45:07 -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=3Ifwe3OWFh4lYd06DMQng9JmUbG6AvVchii8WNFVHBs=; b=YrU43TRYpktVt/mniBZXAbVi5B6VjngWhKSnHnL7yx4b+e2E8bZRrDpAFw8aKBwfHF5tn2pdPJn8mbxvU/4eO273hgFTV7AJ1GpUzLka8V+6Mze/jivxR8i9yO8wucpo; Received: from box313.bluehost.com ([69.89.31.113]:45160 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TggRX-0005w1-HC; Thu, 06 Dec 2012 11:45:07 -0700 Message-ID: <50C0E7B4.6040602@labn.net> Date: Thu, 06 Dec 2012 13:45:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Noel Chiappa References: <20121206172101.5FFC218C167@mercury.lcs.mit.edu> In-Reply-To: <20121206172101.5FFC218C167@mercury.lcs.mit.edu> X-Enigmail-Version: 1.4.6 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: i2rs@ietf.org Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:45:30 -0000 On 12/6/2012 12:21 PM, Noel Chiappa wrote: > > From: Lou Berger > > >> How about 'network interface', though? > > > Why not data plane interface? > > The problem is that that's facially ambiguous: does it mean 'an interface to > the data plane to allow control plane entities to manage the operation of the > data plane', or does it mean 'an interface over which the data plane > transfers user data'? I intended the latter, i.e. an interface used to transmit traffic in the data plane > > I know, I know, technically "network interface" has the same potential > ambiguities, but I think there's enough history in that term that most > people's first thought on seeing it is "thing that attaches a box into a > particulr network" so where do virtual interfaces (e.g., supported via tunnels) fit in? Lou > > Noel > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > From russw@riw.us Thu Dec 6 10:48:34 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81021F8814 for ; Thu, 6 Dec 2012 10:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlS-mcmWiKa9 for ; Thu, 6 Dec 2012 10:48:34 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6DB21F87CC for ; Thu, 6 Dec 2012 10:48:34 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TggUo-0002jg-0v for i2rs@ietf.org; Thu, 06 Dec 2012 10:48:33 -0800 Message-ID: <50C0E882.5030206@riw.us> Date: Thu, 06 Dec 2012 13:48:34 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <20121206172101.5FFC218C167@mercury.lcs.mit.edu> <50C0E7B4.6040602@labn.net> In-Reply-To: <50C0E7B4.6040602@labn.net> 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: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:48:34 -0000 > I intended the latter, i.e. an interface used to transmit traffic in the > data plane >> I know, I know, technically "network interface" has the same potential >> ambiguities, but I think there's enough history in that term that most >> people's first thought on seeing it is "thing that attaches a box into a >> particulr network" > > so where do virtual interfaces (e.g., supported via tunnels) fit in? IMHO, they should fit in along with normal interfaces --anything that's layer 3 on those interfaces can be configured. Forwarding information, however, should not be modeled on the interface, but rather in the RIB. I know there might be implementations that connect the forwarding information to the interface itself, but I'd see that as a special case of a VRF (with which you can associate specific interfaces), rather than actually trying to manage the forwarding plane on a per-interface basis. :-) Russ -- <>< riwhite@verisign.com russw@riw.us From lberger@labn.net Fri Dec 7 06:30:42 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7334221F8925 for ; Fri, 7 Dec 2012 06:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=0.286, 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 TEPfvqXgSxx7 for ; Fri, 7 Dec 2012 06:30:41 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id C728C21F867A for ; Fri, 7 Dec 2012 06:30:41 -0800 (PST) Received: (qmail 20481 invoked by uid 0); 7 Dec 2012 14:30:18 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 7 Dec 2012 14:30:18 -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=EwVZkbp/6S4QtZ/S1HxNhG9MHLOiZ4kRnf9GupA0qwA=; b=e1VeGI7q5kHvo3r4NQzCWpDmRGKaHokXZMlsqvhv96kx3O4bose3F50Z0llOkRfIBMBYs6zdZnYlrVP6tBVB36ESeB1GQrleYGXk1+5wOsXias28+wlKRwkV5kjCk2/+; Received: from box313.bluehost.com ([69.89.31.113]:58057 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TgywU-00062W-4j; Fri, 07 Dec 2012 07:30:18 -0700 Message-ID: <50C1FD7C.7070105@labn.net> Date: Fri, 07 Dec 2012 09:30:20 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Russ White References: <20121206172101.5FFC218C167@mercury.lcs.mit.edu> <50C0E7B4.6040602@labn.net> <50C0E882.5030206@riw.us> In-Reply-To: <50C0E882.5030206@riw.us> X-Enigmail-Version: 1.4.6 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: i2rs@ietf.org Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:30:42 -0000 Sounds like the distinction between (managing) tunnels and encapsulations. Either way, both are data plane (/forwarding) constructs that need to be allowed for in the terminology. Lou On 12/6/2012 1:48 PM, Russ White wrote: > >> I intended the latter, i.e. an interface used to transmit traffic in the >> data plane > >>> I know, I know, technically "network interface" has the same potential >>> ambiguities, but I think there's enough history in that term that most >>> people's first thought on seeing it is "thing that attaches a box into a >>> particulr network" >> >> so where do virtual interfaces (e.g., supported via tunnels) fit in? > > IMHO, they should fit in along with normal interfaces --anything that's > layer 3 on those interfaces can be configured. Forwarding information, > however, should not be modeled on the interface, but rather in the RIB. > I know there might be implementations that connect the forwarding > information to the interface itself, but I'd see that as a special case > of a VRF (with which you can associate specific interfaces), rather than > actually trying to manage the forwarding plane on a per-interface basis. > > :-) > > Russ > > From cpignata@cisco.com Fri Dec 7 07:27:15 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3B221F8767 for ; Fri, 7 Dec 2012 07:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.548 X-Spam-Level: X-Spam-Status: No, score=-109.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kwdKTpbmwdrL for ; Fri, 7 Dec 2012 07:27:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F521F8762 for ; Fri, 7 Dec 2012 07:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3272; q=dns/txt; s=iport; t=1354894034; x=1356103634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XuGYTZcuB7wrNVgV9vd9ibMFZI+c426L07YEXwN2e0c=; b=cqPsAJ9n46XvC9gFZ1HiIi87m5JSQjaiK4UttWKbZ/y0GbtYCSo3Ue5q 2MH3r840y6KqRE+xOzw2K6mo07f3JFS7pDPGu4mxXep4UK0/htcT8q43q RSQlZcojocx5ighfjDAMysZSBR+lyM1e9d3giZ8mQWyMJcR74OMnENFJM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEoKwlCtJXG//2dsb2JhbABEvjYWc4IeAQEBAwEBAQE3NAQHBQsCAQgiFBAnCyUCBA4FCBOHcAYMwiQEjD8bg0dhA6ZNgnOBbTU X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="147510845" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 07 Dec 2012 15:27:13 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB7FRD5v010740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 15:27:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.252]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 09:27:13 -0600 From: "Carlos Pignataro (cpignata)" To: "George, Wes" Thread-Topic: [i2rs] Progressing the chartering effort Thread-Index: AQHN1I9UtgcGamvqfEK+DpF6OGs4ww== Date: Fri, 7 Dec 2012 15:27:12 +0000 Message-ID: <95067C434CE250468B77282634C96ED32276CCFD@xmb-rcd-x02.cisco.com> References: <00ef01cdc64a$37284d00$a578e700$@olddog.co.uk> <2671C6CDFBB59E47B64C10B3E0BD5923033897C4F9@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923033897C4F9@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "adrian@olddog.co.uk" , "i2rs@ietf.org" Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:27:15 -0000 I had noticed the same potential ambiguity of different meanings for the sa= me term "interface", but I did not have a good proposal to address it (othe= r than leave it as-is). I've done a bit of browsing and scanning through RF= Cs, and frankly this issue has existed in the past in many occasions -- gre= p for /interface/i in RFC 791, RFC 2133, RFC 6418, etc. -- many of which us= e plain "interfaces" for both. To disambiguate, qualifying each use (one or both) is always an option. In = the charter's paragraph quoted below, the former meaning can be a "network = interface", whereas the latter can be a "programmatic interface". "Network = interface" seems to fit nicely as the we are defining a "routing network", = the Interfaces Group MIB calls these "network interfaces", and so does NIC. Another option is to find a non-colliding synonym for one or both uses, but= history seems to weight heavily in both terms (e.g., it is not a "link", i= t is not a ...) I think that the most direct solution is as follows: "A routing system is all or part of a routing network such as _a network_ i= nterface, a collection of _network interfaces_, a router, or a collection of routers. _Programmatic_= Interfaces to the Routing System..." Thanks, -- Carlos. On Nov 27, 2012, at 4:38 PM, "George, Wes" wrot= e: > Can someone clarify for me? >=20 > We have an unfortunate overloading of the term "interface" here: > "A routing system is all or part of a routing network such as an interfac= e, a collection of > interfaces, a router, or a collection of routers. Interfaces to the Rout= ing System..." >=20 > These are not the same sort of interfaces, and their proximity can lead t= o confusion. One moves packet traffic, the other is more of an information = interface or even an API. Do we need to modify the first one to refer to it= as "an interface or collection of interfaces to transmit/receive packet da= ta" or some such? Or am I inferring a distinction where none is desired? >=20 > Thanks >=20 > Wes George >=20 >> I have taken the charter text and milestones discussed at the BoF (minus >> the paragraph we agreed to delete) and added it into the data tracker at >> https://datatracker.ietf.org/doc/charter-ietf-i2rs/ >>=20 >> This is our starting point for further charter discussions. >>=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable prop= rietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the= use of the individual or entity to which it is addressed. If you are not t= he intended recipient of this E-mail, you are hereby notified that any diss= emination, distribution, copying, or action taken in relation to the conten= ts of and attachments to this E-mail is strictly prohibited and may be unla= wful. If you have received this E-mail in error, please notify the sender i= mmediately and permanently delete the original and any copy of this E-mail = and any printout. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From cpignata@cisco.com Fri Dec 7 07:27:25 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D8021F8799 for ; Fri, 7 Dec 2012 07:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ADmKlQlTPrLk for ; Fri, 7 Dec 2012 07:27:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 40EFA21F8762 for ; Fri, 7 Dec 2012 07:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5205; q=dns/txt; s=iport; t=1354894044; x=1356103644; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SOOTcrIFeBG/NVWh/4s8/iCoKSrrtgIW1FjPYdhyuuo=; b=bh46hlPid7o5nncBuyhsb56a348pjR5k6IvloDkRlT6P/kp1EvgbFCFY fO/0Vo+rHE6/0waGQqQqWUMi/UWnXE/yQgSUSunNUarq4QaHB4Z5hmoZS 7Vo1qI2B5tJXFPDN15/CI/qYYKfbAfZb/lA8+JkRZDXPJ9gGxQyzLKnUF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEoKwlCtJXG8/2dsb2JhbABEvjYWc4IfAQEEAQEBawsQAgEIBAoUHQchBgsUEQIEDgUIh3cDDwy4Rw2JUASLVmmDYmEDiCqMBY0NhRGCc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150488530" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 07 Dec 2012 15:27:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB7FRNnI005767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 15:27:23 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.252]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 09:27:23 -0600 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Progressing the chartering effort Thread-Index: AQHN1I9atgcGamvqfEK+DpF6OGs4ww== Date: Fri, 7 Dec 2012 15:27:22 +0000 Message-ID: <95067C434CE250468B77282634C96ED32276DD08@xmb-rcd-x02.cisco.com> References: <00ef01cdc64a$37284d00$a578e700$@olddog.co.uk> <50B4F55E.5000503@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.9] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED32276DD08xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] Progressing the chartering effort X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:27:25 -0000 --_000_95067C434CE250468B77282634C96ED32276DD08xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. Thanks, -- Carlos. On Nov 27, 2012, at 1:50 PM, Alia Atlas > wrote: I think it should include control plane protocols as well. The first focus= is RIB-based use-cases, which seem to be easily tied to a forwarding plane= . However, the BGP-based policy cases and topology cases do not need to be= co-located with a forwarding plane and, if that portion of the routing sys= tem is supported by a software entity, I think that I2RS should be able to = handle that as well. I feel that restricting the routing system to only those with an attached f= orwarding plane (physical or virtual) is unnecessarily restrictive and we a= lready know of cases where it may not be sufficient. Alia On Tue, Nov 27, 2012 at 12:16 PM, Russ White > wrote: This looks good --nice, well defined scope and strong requirements language. The only question I have is: =3D=3D A routing system is all or part of a routing network such as an interface, a collection of interfaces, a router, or a collection of routers= . =3D=3D Should this include the control plane protocols, as well? The positive would be to provide a (more) complete description of a routing system, the negative is this might be seen as bringing interaction with protocols into the charter. Thoughts? :-) Russ -- <>< riwhite@verisign.com russw@riw.us _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_95067C434CE250468B77282634C96ED32276DD08xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0DF9AE196881AF4DA1A31EC4BC020DAE@cisco.com> Content-Transfer-Encoding: quoted-printable +1.

Thanks,

-- Carlos.

On Nov 27, 2012, at 1:50 PM, Alia Atlas <akatlas@gmail.com> wrote:

I think it should include control plane protocols= as well.  The first focus is RIB-based use-cases, which seem to be ea= sily tied to a forwarding plane.  However, the BGP-based policy cases = and topology cases do not need to be co-located with a forwarding plane and, if that portion of the routing system is supp= orted by a software entity, I think that I2RS should be able to handle that= as well.

I feel that restricting the routing system to only those with an attached f= orwarding plane (physical or virtual) is unnecessarily restrictive and we a= lready know of cases where it may not be sufficient.

Alia


On Tue, Nov 27, 2012 at 12:16 PM, Russ White <russw@riw.us><= /span> wrote:

This looks good --nice, well defined scope and strong requirements
language. The only question I have is:

=3D=3D
A routing system is all or part of a routing network such as an
interface, a collection of interfaces, a router, or a collection of routers= .
=3D=3D

Should this include the control plane protocols, as well? The positive
would be to provide a (more) complete description of a routing system,
the negative is this might be seen as bringing interaction with
protocols into the charter.

Thoughts?

:-)

Russ

--
<><
riwhite@verisign.com
russw@riw.us
_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--_000_95067C434CE250468B77282634C96ED32276DD08xmbrcdx02ciscoc_-- From daniel@olddog.co.uk Thu Dec 13 12:30:41 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0121F87F5 for ; Thu, 13 Dec 2012 12:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wdgP-arsDcw for ; Thu, 13 Dec 2012 12:30:40 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5971D21F87C5 for ; Thu, 13 Dec 2012 12:30:40 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBDKUce4017163; Thu, 13 Dec 2012 20:30:39 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBDKUaol017141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 20:30:38 GMT From: "Daniel King" To: Date: Thu, 13 Dec 2012 20:30:34 -0000 Message-ID: <004e01cdd970$b5039d90$1f0ad8b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ZcJXXR6OTltG6Q/O6QzwuwUWp+w== Content-Language: en-gb Cc: adrian@olddog.co.uk Subject: [i2rs] ABNO Updated - draft-farrkingel-pce-abno-architecture-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:30:42 -0000 Hi All,=20 Thanks for all the feedback so far. Please find a new version of the document: http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-01 Updates include: - Clarification of scope (>data center and CDN) - Updates to architecture model=20 - Discussing implementation of the architecture - Placeholder for survivability and redundancy - General readability and nit fixes We know several people are working on text for additional use cases, and = we look forward to seeing those contributions! Br, Dan & Adrian. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: 03 December 2012 14:22 To: mohamed.boucadair@orange.com; 'Daniel King' Cc: 'JACQUENET Christian OLNC/OLN'; i2rs@ietf.org Subject: RE: [i2rs] A new draft on an architecture for application-based network operations Hi Med, Thanks for your comments. Because you responded on the I2RS list, I will as well, but maybe we = should take this off-list to avoid gumming up the charter discussions with something that is pretty-much off-topic. In short, you are right that there are commercial and administrative policies that come into play. If I recall right, your I-D was by way of = an applicability statement showing how the PCE blocks could fit together. = It might be interesting to review your work in the light of hierarchical = PCE to see how that all bolts together. We will look at how we can add some further explanation of the = interactions of policy in this process to the example in Section 3.1 (without turning this into a full and detailed blow-by-blow explanation). Would surely welcome your input. You ask what value is added by the I2RS approach to the inter-AS setup described in Section 3.1. My answer: none. And that is why the example = in 3.1 does not mention I2RS. Cheers, Adrian > I read this draft and I was interested in Section 3.1 > (http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00# > section- > 3.1). >=20 > The current text makes no assumption whether administrative setup is=20 > needed before sending any request to reserve some inter-domain=20 > resources. FWIW, we have edited in the past this document:=20 > http://tools.ietf.org/html/draft- boucadair-pce-interas-01. Two types = of agreements are needed for such model: > (1) between adjacent domains and (2) between the entities managing the = > end ASes which will terminate LSPs. This document uses COPS to put=20 > into effect computed inter-domain LSPs. The document proposes also: a=20 > solution to discover a remote AS is supporting the PCE service, a=20 > solution to avoid advertising the IP > addresses of routers which are candidate to be tail/head end of an inter-domain > LSP, etc. A demo of the full system can be found here: http://www.ist- = > mescal.org/roadmap/pcs-demo.avi >=20 > Since 2005 (at the edited that document), there are several advances.=20 > It would be > valuable to explain what is the added value of the i2rs approach for=20 > this use case > compared to what was proposed in the document cited above. >=20 > Cheers, > Med >=20 >=20 > >-----Message d'origine----- > >De : i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] De la part=20 > >de Daniel King Envoy=E9 : dimanche 2 d=E9cembre 2012 00:03 =C0 :=20 > >i2rs@ietf.org Cc : adrian@olddog.co.uk; daniel@olddog.co.uk Objet :=20 > >[i2rs] A new draft on an architecture for application-based network=20 > >operations > > > >Dear i2rs, > > > >Adrian and I posted an I-D which is a rather grandiose attempt to=20 > >pull together a number of existing architectural components (PCE,=20 > >VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based = > >architect-thingy. > >It needed a name, so we called it Application-Based Network=20 > >Operations (ABNO), warning it's not house trained and may answer to=20 > >various other > >names: > > > >A PCE-based Architecture for Application-based Network Operations > >http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 > > > >As some of you will know this is the result of numerous discussions=20 > >we have had with a number of people over the last three months. =20 > >Where pieces of the puzzle seem to have been coagulating, we thought=20 > >it might be nice to build a framework in which the jelly (jello) can=20 > >set. It is at a really early stage, so we are convinced you will all=20 > >throw stuff at us, but what the hell! > > > >As it stands, the current draft includes: > > > >- A brief description of abstraction functional components and the=20 > >interfaces between them. > >- An attempt to supply pointers to existing work (tool kit) where=20 > >that may be applicable and there are some use case examples to give a = > >feel for how it all works. > >- Various ABNO use cases. > > > >A number of areas need further discussion, especially the use cases.=20 > >We decided to submit with the few we do have, in order to generate=20 > >some feedback - anyone who wants to supply use case(s) and text,=20 > >would receive hero status. > > > >We have pitched the document as a PCE working group document because=20 > >PCE is a central component, but the document doesn't really fall=20 > >inside the PCE charter. For the time being it might be best to send=20 > >comments direct to us rather than clutter up any WG mailing list with = > >discussions that are outside the charter (but if some WG chair wants=20 > >to claim the work, then...) > > > >Thanks, > >Dan and Adrian > > > >_______________________________________________ > >i2rs mailing list > >i2rs@ietf.org > >https://www.ietf.org/mailman/listinfo/i2rs > >=3D From mohamed.boucadair@orange.com Fri Dec 14 07:38:13 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557021F85B2 for ; Fri, 14 Dec 2012 07:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.003, 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 W8+YbFa6OaCF for ; Fri, 14 Dec 2012 07:38:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B128021F8456 for ; Fri, 14 Dec 2012 07:38:12 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3D97D22C308 for ; Fri, 14 Dec 2012 16:38:11 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 246EF35C07B for ; Fri, 14 Dec 2012 16:38:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 14 Dec 2012 16:38:10 +0100 From: To: "i2rs@ietf.org" Date: Fri, 14 Dec 2012 16:38:09 +0100 Thread-Topic: I-D Action: draft-boucadair-network-automation-requirements-00.txt Thread-Index: Ac3aD459ZsbCByFCT9aTzzNH+viWEQAAJgdA Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D16E309@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.12.14.133918 Cc: JACQUENET Christian OLNC/OLN Subject: [i2rs] TR: I-D Action: draft-boucadair-network-automation-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:38:13 -0000 Dear all, We submitted this I-D which discusses requirements for network automation. = We thought this document may be of interest of this mailing list.=20 The document includes a (short) discussion about I2RS-related requirements = (see Section 5.2.2). Title : Requirements for Automated (Configuration) Management Author(s) : Mohamed Boucadair Christian Jacquenet Filename : draft-boucadair-network-automation-requirements-00.txt Pages : 17 Date : 2012-12-14 Abstract: Given the ever-increasing complexity of the configuration tasks required for the dynamic provisioning of IP networks and services, this document aims at listing the requirements to drive the specification of an automated configuration management framework, including the requirements for a protocol to convey configuration information towards the managed entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-network-automation-require= ments There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-network-automation-requirements-= 00 Comments, contributions and suggestions are more than welcome.=20 Cheers, Med= From j.schoenwaelder@jacobs-university.de Fri Dec 14 07:59:35 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF9A21F8891 for ; Fri, 14 Dec 2012 07:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEDLiOWXs0of for ; Fri, 14 Dec 2012 07:59:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6C78D21F8889 for ; Fri, 14 Dec 2012 07:59:34 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB4420C3A; Fri, 14 Dec 2012 16:59:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5-Yaa9_PssfS; Fri, 14 Dec 2012 16:59:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32AAD20C36; Fri, 14 Dec 2012 16:59:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 72CC2236E9A6; Fri, 14 Dec 2012 16:59:40 +0100 (CET) Date: Fri, 14 Dec 2012 16:59:39 +0100 From: Juergen Schoenwaelder To: mohamed.boucadair@orange.com, JACQUENET Christian OLNC/OLN Message-ID: <20121214155939.GA64703@elstar.local> Mail-Followup-To: mohamed.boucadair@orange.com, JACQUENET Christian OLNC/OLN , "i2rs@ietf.org" References: <94C682931C08B048B7A8645303FDC9F36E9D16E309@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9D16E309@PUEXCB1B.nanterre.francetelecom.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] TR: I-D Action: draft-boucadair-network-automation-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:59:35 -0000 On Fri, Dec 14, 2012 at 04:38:09PM +0100, mohamed.boucadair@orange.com wrote: > Dear all, > > We submitted this I-D which discusses requirements for network automation. We thought this document may be of interest of this mailing list. > The document includes a (short) discussion about I2RS-related requirements (see Section 5.2.2). > > Title : Requirements for Automated (Configuration) Management > Author(s) : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-network-automation-requirements-00.txt > Pages : 17 > Date : 2012-12-14 > > Abstract: > Given the ever-increasing complexity of the configuration tasks > required for the dynamic provisioning of IP networks and services, > this document aims at listing the requirements to drive the > specification of an automated configuration management framework, > including the requirements for a protocol to convey configuration > information towards the managed entities. Before reading this, what does this document add relative to RFC 3139 and RFC 3535? And from a NETCONF and YANG perspective, is there anything you guys find not addressed by NETCONF and YANG? (And please do not confuse data modeling languages with data models.) You may also want to look at these documents, close to be submitted to the AD: draft-ietf-netmod-interfaces-cfg-08 draft-ietf-netmod-ip-cfg-07 draft-ietf-netmod-routing-cfg-06 There is work being done in this space, substantial work. Saying something is embryonic is not necessarily a good reason to start work on another baby. First wait for delivery. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rcallon@juniper.net Mon Dec 17 09:39:06 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1304F21F8AC2 for ; Mon, 17 Dec 2012 09:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, UNRESOLVED_TEMPLATE=3.132, 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 0Uy3bu9HRJF8 for ; Mon, 17 Dec 2012 09:39:04 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0821F8AC1 for ; Mon, 17 Dec 2012 09:39:04 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUM9YuKWKebZpPYtZVeStYOe87cH+fS3y@postini.com; Mon, 17 Dec 2012 09:39:04 PST 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; Mon, 17 Dec 2012 09:38:50 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 17 Dec 2012 09:38:49 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.14) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 17 Dec 2012 09:46:19 -0800 Received: from mail249-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Dec 2012 17:38:48 +0000 Received: from mail249-va3 (localhost [127.0.0.1]) by mail249-va3-R.bigfish.com (Postfix) with ESMTP id AEB26C80208 for ; Mon, 17 Dec 2012 17:38:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zzc85fh4015Izz1de0h1202h1e76h1d1ah1d2ahzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h34h1155h) Received: from mail249-va3 (localhost.localdomain [127.0.0.1]) by mail249-va3 (MessageSwitch) id 1355765913347028_14382; Mon, 17 Dec 2012 17:38:33 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.247]) by mail249-va3.bigfish.com (Postfix) with ESMTP id 4BC2CC00067 for ; Mon, 17 Dec 2012 17:38:33 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Dec 2012 17:38:29 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.22]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0245.002; Mon, 17 Dec 2012 17:38:29 +0000 From: Ross Callon To: "i2rs@ietf.org" Thread-Topic: Minutes from the IRS BOF Thread-Index: Ac3cfVGih24K56uLRkq+0AunxjkzTg== Date: Mon, 17 Dec 2012 17:38:27 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309A0A184@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/mixed; boundary="_004_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_" 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: [i2rs] Minutes from the IRS BOF X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 17:39:06 -0000 --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_ Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_" --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I just uploaded the IRS BOF minutes to the IETF server. They are also attac= hed to this email in text form. Thanks to Sue Hares and Dave Ward for provi= ding the rough input that I summarized into these minutes. Thanks, Ross --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I just uploaded the IRS BOF minutes to the IETF server. They are also = attached to this email in text form. Thanks to Sue Hares and Dave Ward for = providing the rough input that I summarized into these minutes.
 
Thanks, Ross
 
 
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_-- --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_ Content-Type: text/plain; name="Minutes IRS BOF IETF 85.txt" Content-Description: Minutes IRS BOF IETF 85.txt Content-Disposition: attachment; filename="Minutes IRS BOF IETF 85.txt"; size=16491; creation-date="Tue, 04 Dec 2012 21:28:50 GMT"; modification-date="Mon, 17 Dec 2012 17:34:20 GMT" Content-Transfer-Encoding: base64 TWludXRlcyBmcm9tIElSUyBCT0YgDQoyMDEyLjExLjA1LCBBbHRhbnRhDQoNCg0KQWdlbmRhOg0K DQogICAgQWdlbmRhLWJhc2hpbmcgYW5kIGFkbWluaXN0cml2aWEgKGNoYWlycykgDQogICAgU2Nv cGUgYW5kIHB1cnBvc2Ugb2YgQm9GIChBZHJpYW4gRmFycmVsKSANCiAgICBPdmVydmlldyBvZiBQ cm9ibGVtIFN0YXRlbWVudCBhbmQgRnJhbWV3b3JrIChKb2VsIEhhbHBlcm4pDQogICAgT3ZlcnZp ZXcgb2YgVXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgKFNoYW5lIEFtYW50ZSkNCiAgICBQb3Rl bnRpYWwgQ2hhcnRlciAoUm9zcyBDYWxsb24pDQogICAgT2J2aW91cyBRdWVzdGlvbnMgKERhdmUg V2FyZCkNCiAgICBEaXNjdXNzaW9uIChhbGwpDQogICAgU3VtbWFyeSBhbmQgQ2xvc3VyZSAoY2hh aXJzIGFuZCBBRCkNCg0KDQowLiBBZG1pbmlzdHJpdmlhIC0gUm9zcyBDYWxsb24NCg0KTm90ZSBX ZWxsIHdhcyBkaXNjdXNzZWQuDQpUaGlzIGlzIGEgV0cgZm9ybWluZyBCT0YsIHNvIFJvc3Mgd2ls bCBnbyBvdmVyIGRyYWZ0IGNoYXJ0ZXIgbGF0ZXIgaW4gQk9GLiBEYXZlIHdpbGwgZ28gdGhyb3Vn aCBzb21lIHF1ZXN0aW9ucyB0aGF0IGhhdmUgYmVlbiBhc2tlZC4gDQoNCk5vIHF1ZXN0aW9ucw0K DQoNCkkuIFB1cnBvc2Ugb2YgYm9mIC0gQWRyaWFuIEZhcnJlbA0KDQpUaGFuayB5b3UgZm9yIGNv bWluZy4gS2V5IGVsZW1lbnRzIHRoYXQgd2UgbmVlZCB0byBhZGRyZXNzOiBjb25zZW5zdXMgdGhh dCB0aGVyZSBpcyB3b3JrIHRvIGJlIGRvbmUsIGNsZWFyIGZvY3VzIG9uIHRvcGljczsgZGV0ZXJt aW5lIGlmIHdvcmsgaXMgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgSUVURiAoZWcgaW4gZWl0aGVy IHJvdXRpbmcgb3Igb3BlcmF0aW9ucyk7IGEgY3JpdGljYWwgbWFzcyBvZiBwZW9wbGUgY29tbWl0 IHRvIGRvaW5nIHRoZSB3b3JrIChub3QgMSBvciAyIHBlb3BsZSkuIA0KDQpObyBxdWVzdGlvbnMN Cg0KDQpJSS4gT3ZlcnZpZXcgb2YgUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIEZyYW1ld29yayAtIEpv ZWwgSGFscGVybg0KDQpUaGlzIGlzIHJlbGF0ZWQgdG8gYnV0IG5vdCB0aGUgc2FtZSBhcyB1c2Ug Y2FzZXMuIFdlIGFyZSB0YWxraW5nIGFib3V0IGEgcHJvYmxlbSwgbm90IGEgcHJvdG9jb2wuIA0K DQpXaGF0IGlzIG5lZWRlZDogDQogLSBkYXRhIG1vZGVsaW5nIGZvciByb3V0aW5nIGFuZCBzaWdu YWxpbmcgc3RhdGUNCgktIFNOTVAgaXMgbm90IGEgZ29vZCBkYXRlIG1vZGVsIGZvciBhbnl0aGlu ZywNCgktIHRoZXJlIGlzIGEgY2hhbGxlbmdlIGluIG1vZGVsaW5nIHBvbGljeSANCgktIChmb3Ig bW9kZWxzIHNlZSBzbGlkZXMpDQogLSBXZSBuZWVkIGEgZnJhbWV3b3JrIHRvIGludGVncmF0ZSB0 aGUgZXh0ZXJuYWwgZGF0YSBpbnRvIFJvdXRpbmcNCgktIGluZGlyZWN0aW9uLCBwb2xpY3ksIGxv b3AtZGV0ZWN0aW9uDQoJLSB3ZSBuZWVkIHRvIHByb3ZpZGUgdGhlIHRyaWFnZSB0aGF0IGlzIG5l ZWRlZCBmb3IgdGhlIHJlZA0KCSAgYWxlcnQgc3RyZWFtIChpZSwgYWlkIHdoZW4gb25lIG91dGFn ZSBjYXVzZXMgZmxvb2Qgb2YgYWxlcnRzKQ0KIC0gd2UgYXJlIG5vdCBzdGFydGluZyBvbiBkZWZp bmluZyBhIHByb3RvY29sIJYgd2UgaGF2ZSBsb3RzIA0KICBvZiBwcm90b2NvbHMuIFdlIGFyZSBz dGFydGluZyBvbiBkYXRhIG1vZGVscy4gDQoNCk1haW4gY29uY2VybnM6DQogLSBTdGFuZGFyZCBN b2RlbHMNCiAgICAgIC0gY2xlYXIgc2VsZi1kZXNjcmliaW5nIHNlbWFudGljcw0KICAgICAgLSBz dWZmaWNpZW50IGNvdmVyYWdlIGZvciB1c2UgY2FzZXMgbmVlZGluZyBmYWN0DQogLSBBcHBsaWNh dGlvbnMgYXJlIG5vdCByb3V0ZXJzDQogLSBTZWN1cml0eSwgYXV0aG9yaXphdGlvbiwgYW5kIGlk ZW50aXR5CQ0KICAgICAgLSB3ZSBtdXN0IHB1dCBpdCBpbiBmcm9tIHRoZSBiZWdpbm5pbmcuDQog LSBJdCBtdXN0IHNjYWxlIHRvIGxhcmdlIHNpemVzLiANCihzZWUgZGlhZ3JhbSBvbiBzbGlkZXMp DQoNClBBTCAtIHNsaWRlcyAoc2VlIHNsaWRlcykNCg0KSVJTIEludGVyZmFjZSBLZXkgQXNwZWN0 cyANCiAtIE11bHRpcGxlIHNpbXVsdGFuZW91cyBhc3luY2ggDQogLSBzb21lIGxvbmcsIHNvbWUg c2hvcnQsIHBhcmFsbGVsIG9wZXJhdGlvbnMNCiAtIENvbmZpZ3VyYXRpb26gIA0KIC0gV2UgbmVl ZCB0byBpbnRlcmFjdCB3aXRoIHRoZSBjaGFuZ2VzIG9mIGNvbmZpZ3VyYXRpb24NCiAtIChNYW55 IGltcGxlbWVudGF0aW9ucyBjYW4gaGFuZGxlIGludGVyYWN0aW9ucyB0byBjb25maWd1cmF0aW9u KQ0KIC0gTXVzdCBrbm93IGFib3V0IGNhcGFiaWxpdGllcywgVGhlIGFwcGxpY2F0aW9ucyBoYXZl IHRvIGtub3cgd2hhdA0KICAgeW91IGNhbiBkby6gDQoNCldoYXQgSVJTIGlzIG5vdCANCiAtIG5v dCBjb25maWcsIG5vdCByb3V0ZXIvc2lnbmFsaW5nLCBub3QgdGhlIG9ubHkgd2F5LKANCiAtIG5v dCB0byByZXBsYWNlIGJncCBvciBvc3BmIHBsbCBvdXSgDQogLSBOb3QgdG8gYSBzcGVjaWZpYyBk ZXZpY2VzIG9yIG5vdCBhIHNwZWNpZmljIGNhc2UNCg0KU3RhcnQgd2l0aCBhIEZvY3VzZWQgU2Nv cGUgDQogLSBzbWFsbCBzZXQgb2YgZGF0YS1tb2RlbHMgKFJJQiBsYXllcikgZm9yIGNvbnRyb2ws DQogLSBTZXQgb2YgZXZlbnRzIHRvIHN1cHBvcnQgcmVsYXRlZCB1c2UtY2FzZXMsDQogLSBEYXRh LW1vZGVsIGZvciB0b3BvbG9neSygDQogLSBpbnZlc3RpZ2F0ZSBwcm90b2NvbCBvcHRpb25zIGZv ciB0aGUgaW50ZXJmYWNlDQogLSBkZWZpbmWgYSBzZXQgb2YgbW90aXZhdGluZyB1c2UtY2FzZSB0 byBkcml2ZSB0aGlzIHNjb3BlDQogLSBXZSB3aWxsIGZhaWwgaWYgd2UgdHJ5IHRvIGRvIGFsbCBp ZiBpdCEhISENCiAtIFdlIGhhdmUgdG8gbWFrZSBleHRlbnNpYmxlLKANCg0KSVJTIFBvbGljeSBG cmFtZXdvcmsgDQogLSBkaXNjdXNzaW9uIG9mIGRpYWdyYW2gDQogLSBJdCBoYXMgdG8gYmUgbWFu eS10by1tYW55LA0KIC0gVW5mb3J0dW5hdGVseSAtIHdlIGNhbiBtYWtlIHRoZSBzaW1wbGlmaWNh dGlvbiBvZiAxIHRvIG1hbnksDQoNClBvbGljeSBGcmFtZXdvcmsgVG9waWNzIA0KIC0gSWRlbnRp dHmgDQogLSBSb2xlDQogLSBTY29wZSAtIHdoYXQgSSBjYW4gcmVhZA0KIC0gSW5mbHVlbmNlIC0g d2hhdCBJIHdyaXRloA0KIC0gUmVzb3VyY2VzIA0KIC0gdGhhdCBwZXJzaXN0IGFuZCBtYXkgY29u c3VtZSB0aGluZ3MNCiAtIFBvbGljeaAgDQogLSBpbXBsaWNpdCBwb2xpY3kgLSBleGlzdHMgd2l0 aGluIHByb3RvY29scywgc29tZSByb3V0ZXJzIGNob29zZSBiZXR3ZWVuDQogLSBleHBsaWNpdCBw b2xpY3kgLSByZWFkIGFuZCB3cml0ZSBpbiB0aGUgY29uZmlndXJhdGlvbg0KIC0gQm90aCBtdXN0 IGJlIHJlcHJlc2VudGVkIGluIHRoZSBwcm90b2NvbA0KIC0gUG9saWN5IEFjdGlvbnMgDQogLSBX ZSBjYW1lIHVwIHdpdGggYSBzdGFydC11cA0KIC0gV2Ugd291bGQgbGlrZSByZXZpZXcNCg0KUXVl c3Rpb25zIC8gRGlzY3Vzc2lvbiANCg0KIC0gS2lyZWV0aSBLb21wZWxsYSAtIEFyZSBhbGwgYXBw bGljYXRpb25zIG5ldHdvcmsgcmVsYXRlZD8gDQpKb2VsOiBMb25nIHRlcm0gYm90aCAobmV0d29y ayByZWxhdGVkIGFuZCBub3QpLiBTaG9ydCB0ZXJtIGZvY3VzIG9uIGFwcGxpY2F0aW9ucyB0aGF0 IGFyZSBuZXR3b3JrIGF3YXJlLg0KDQogLSBLaXJlZXRpIC0gd2Ugc2hvdWxkIGdvIGJhY2sgdG8g TWlubmVhcG9saXMgZm9yIGJvaWxpbmcgbGFrZXMgaW5zdGVhZCBvZiBvY2VhbnMuoCBQb2xpY3kg hSBpcyB0aGlzIHJvdXRpbmcgcG9saWN5PyBQbGVhc2UgbWFrZSB0aGlzIGNsZWFyLg0KSm9lbDog VHdvIHR5cGVzOiBQb2xpY2llcyBvZiBJUlMghSBJUlMgYWZmZWN0cyByb3V0aW5nIHBvbGljeQ0K DQogLSBLaXJlZXRpOiBUaGlyZCwgSVJTIGlzIG5vdCBhIGRpcmVjdCByZXBsYWNlbWVudCBmb3Ig cm91dGluZyBwcm90b2NvbHMuIERvZXMgdGhpcyBtZWFuIGluZGlyZWN0Pw0KSkg6IEluIGEgc3Rh dGljIChlLmcuIHN0YXRpYyByb3V0aW5nIC0gbWF5YmUpIGJ1dCwgdGhlIGFzc3VtcHRpb24gaXMg dGhhdCBkeW5hbWljIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBpcyBpbiBvcGVyYXRpb24NCg0KIC0g VmlqYXkgS2VydmFuaTogSW4gUGFyaXMsIHdlIGhhZCBhIEJPRiBJMkFYIHdoaWNoIGlzIHJlbGF0 ZWQgdG8gdGhpcyBidXQgZm9jdXNlZCBvbiBhIHByb3RvY29sLiBEb24ndCByZW1lbWJlciB0aGlz IGRpc2N1c3Npb24gdGhlcmUuIEkgY28tY2hhaXJlZC4NCkpIOiBXZSBzaG91bGQgbG9vayBhdCB0 aGUgSUEyRVhULqBQbGVhc2Ugc2VuZCBpbmZvIG9uIHRoaXMgdG8gdGhlIGxpc3QNCg0KIC0gQm9t YmkgSzogUGxlYXNlIGRvIG5vdCB1c2UgdGhlIHRlcm0gk0lSU5QuIA0KIC0gQm9tYmk6IElzIGl0 IGEgbmV0d29yayBBUEkgb3IgYSByb3V0ZXIgQVBJP6ANCkpvZWw6IFRoaXMgaXMgYSBjb250cm9s IGVudGl0eSBvciBhIGNvbnRyb2wgY29tbWlzc2lvbmVyLqAgSXQgaXMgdGFsa2luZyBiZXR3ZWVu IGEgY29udHJvbCBlbnRpdHkgYW5kIHRoZSByb3V0ZXJzLqBBIGNvbnRyb2wgZW50aXR5IChjbGll bnQvY29tbWlzc2lvbmVyKSB0YWxrcyB0byBvbmUgb3IgbW9yZSBuZXR3b3JrIG5vZGVzIChlLmcu IHJvdXRlcnMpLiANCg0KIC0gQm9tYmk6IElmIHlvdSBhcmUgZmFtaWxpYXIgd2l0aCBvdGhlciBy ZWxhdGVkIHdvcmsgaW4gb3RoZXIgU0RPcywgeW91IHNob3VsZCByZXZpZXcgaXQuoA0KDQogLSBU b20gTmFkZWF1OiAoQ2hhbm5lbGluZyBLZXl1ciBQYXRlbCB2aWEgamFiYmVyKTogSVJTIGlzIHN1 cHBvc2VkIHRvIGF1Z21lbnQgbm90IHJlcGxhY2Ugcm91dGluZyBwcm90b2NvbHMuDQoNCiAtIFBl dGVyIExvdGhiZXJnOiBZb3UgYXJlIGFzc3VtaW5nIG11bHRpcGxlIGNvbnRyb2wgcGxhbmVzIHRh bGtpbmcgdG8gdGhpcy4gSG93IGRvIHlvdSBhcmJpdHJhdGUgYW5kIGRlYWwgd2l0aCBjb2hlcmVu Y3k/DQpKb2VsOiBUaGlzIGlzIGRpc2N1c3NlZCBpbqB0aGUgUG9saWN5IGRvY3VtZW50LqANCg0K IC0gRWR3YXJkIENyYWJiZTogVGhlICdhcHBsaWNhdGlvbicgdGVybWlub2xvZ3kgd2UncmUgdXNp bmcgaXMgYSBiaXQgY29uZnVzaW5nOyB1bHRpbWF0ZWx5IGFsbCB0aGUgdGhpbmdzIHdlJ3JlIHRh bGtpbmcgYWJvdXQgYXJlIGNvbnRyb2wgc3lzdGVtcyBhbmQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMg c3VjaC4gQWxzbyB5b3UgY2FuIHJlcGxhY2Ugcm91dGluZyBwcm90b2NvbHMgd2l0aCB0aGlzIHBy b3RvY29sLCB3aGV0aGVyIHlvdSBpbnRlbmRlZCBvciBub3QuDQpKb2VsOiBJbnRlbnQgaXMgYWx3 YXlzIGxpbWl0aW5nLg0KDQoNCklJSS4gVXNlIENhc2VzIGFuZCBSZXF1aXJlbWVudHMgLSBTaGFu ZSBBbWFudGUNCg0KU2VlIGxpc3Qgb2YgZG9jdW1lbnRzIGZvciB1c2UgY2FzZXMgKyArIGEgbmV3 IGRyYWZ0IHdpbGwgYmUgcHVibGlzaGVkIGJ5IEdlb2ZmDQogTWF0c29uLCBhZnRlciBJLUQgd2lu ZG93IHJlb3BlbnMuDQoNCkNhdmVhdDogU2hhbmUgd2lsbCBxdWlja2x5IHN1bW1hcml6ZSBjb250 ZW50cyBvZiBkcmFmdHMuIFdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0aGF0IGFsbCB1c2UgY2FzZXMg bmVlZCB0byBiZSBhZGRyZXNzZWQgaW5pdGlhbGx5LqANCg0KUGxlYXNlIGxvb2sgYXQgYW5kIHJl YWQgdGhlIHVzZSBjYXNlcyBkcmFmdHMuDQoNCkluIG15IG9waW5pb24sIGFjcm9zcyBzZXZlcmFs IHVzZSBjYXNlIGRyYWZ0cywgd2hhdCB5b3UgcmVhbGx5IHdpbGwgZmluZCBpcw0KIHRoZSBzeW50 aGVzaXMgb2YgaW5mb3JtYXRpb24gdGhhdCBhcmUgb3V0c2lkZSB0aGUgcm91dGluZyBjb250cm9s IHBsYW5lLCBlLmcuOg0KIE5ldGZsb3csIHRvIHVsdGltYXRlbHkgaGVscCBkaXJlY3Qgcm91dGlu ZyBwcm90b2NvbHMgdG8gbWFrZSBtb3JlIGdsb2JhbGx5DQogb3B0aW1hbCBmb3J3YXJkaW5nIGRl Y2lzaW9ucy4gSSB0aGluayBKb2VsIGRpZCBhIGdyZWF0IGpvYiBvZiBoaWdobGlnaHRpbmcgdGhp cw0KIGluIGhpcyB0YWxrLg0KDQoNCkRyYWZ0IDE6IGRyYWZ0LWFtYW50ZS1pcnMtdG9wb2xvZ3kt dXNlLWNhc2VzLTAwIA0KIC0gVGhlcmUgYXJlIGV4aXN0aW5nIGludmVudG9yeSAmIHN0YXRpc3Rp Y3Mgd2FyZWhvdXNlIHN5c3RlbXMgdGhhdCBzb21ldGhpbmcgbGlrZSB0aGlzIGlzIGdvaW5nIHRv IHJlYWNoIG91dCBhbmQgZ2V0IGluZm9ybWF0aW9uIGZyb20uDQogLSBJUlMgbmVlZHMgdG8gdGhp bmsgYWJvdXQgaG93IHRvIGV4dHJhY3QgaW5mb3JtYXRpb24gZnJvbSB0aG9zZSBzeXN0ZW1zLg0K DQogLSBDb21tb25hbGl0eTogVEUsIFZQTiwgUmFwaWQgSVAgJiBBU04gcmVudW1iZXIsIGV0Yy4N Cg0KIC0gVW5pcXVlOiBDYXBhY2l0eSBwbGFubmluZywgcGF0aCBjb21wdXRhdGlvbiBlbGVtZW50 IChQQ0UpDQogLSBBTFRPIHNlcnZlcnMNCg0KRHJhZnQgMjogZHJhZnQta2V5dXBkYXRlLWlycy1i Z3AtdXNlY2FzZXMtMDEgDQogLSBCR1AgY29uZmlndXJhdGlvbiBsYXJnZXN0IGluIHRoZSBib3gs IFJTVlAtVEUgTFNQJ3MgYXJlIHNlY29uZC4NCg0KIC0gSGF2aW5nIHRoZSBhYmlsaXR5IHRvIHN5 bmNocm9uaXplIGNvbnNpc3RlbnQgQkdQIHBvbGljaWVzIGFjcm9zcyBhbiBlbnRpcmUgQVMgaXMg ZXh0cmVtZWx5IGltcG9ydGFudCwNCg0KIC0gQkdQIFRyYWZmaWMgRW5naW5lZXJpbmcgaXMgaW1w b3J0YW50LCBhcyBzaG93biBieSBSdXNzIFdoaXRlIGluIGhpcyBkcmFmdC4NCg0KIC0gQ29tbW9u IA0KDQogICAgLSBGbG93IHNwZWMgKHJlYWN0IHRvIERET1MgYXR0YWNrcykgc2ltaWxhciB0byB3 aGl0ZS1pcnMtdXNlDQoNCiAgICAtIE9wdGltaXplZCBleGl0IGNvbnRyb2wNCg0KDQpEcmFmdCAz IERyYWZ0LXdoaXRlLWlycy11c2UtY2FzZS0wMCANCiAtIE9wdGltaXplZCBleGl0IGNvbnRyb2wg LSBCR1AgZG9lcyBub3QgYWxsb3cgZmluZSBncmFpbiBjb250cm9sDQoNCiAtIE5lZWQgdG8gcmVh Y3QgcXVpY2tseSB0byBERE9TIGF0dGFjaw0KDQogLSBEeW5hbWljYWxseSBvcHRpbWl6ZSBmbG93 cyBpbiBodWIgJiBzcG9rZSBuZXR3b3JrDQoNCiAtIEluc2lkZSBEYXRhQ2VudGVyDQoNCiAtIEJl dHdlZW4gRGF0YSBDZW50ZXIgcm91dGluZyAtIEJhbmR3aWR0aCBvbiBEZW1hbmQNCg0KIC0gT3Zl cmFsbCB1c2UgY2FzZXMgYXJlIGFib3V0OiBmaW5lIGdyYWluIHR1bmluZyBvZiB0cmFmZmljIGZs b3dzIGluIGEgbmV0d29yaw0KDQoNCkRyYWZ0IDQ6IEdlb2ZmcmV5IE1hdHRzb24ncyBEcmFmdCAN CiAtIElmIG9wdGljYWwgdHJhbnNwb25kZXJzIGFyZSBvZmZib2FyZCwgaXQgaXMgdXNlZnVsIHRv IGJlIGFibGUgdG8gbW9uaXRvciBiaXQgIGVycm9yLXJhdGUgZGVncmFkaW5nIG92ZXIgdGltZSBh bmQgdGVsbCwgdGhyb3VnaCBJUlMsIElQL01QTFMgcm91dGVycyB0bw0KIHJlYWN0IHRvIHRoYXQs IGkuZS46IHNoaWZ0IHRyYWZmaWMgYXdheSBmcm9tIGEgYmFkIGxpbmssIGluIG9yZGVyIHRvIHJl cGFpciBpdC4NCg0KDQpEcmFmdCA1OiBEcmFmdC1tZWR2ZWQtaXJzLXRvcG9sb2d5LXJlcXVpcmVt ZW50cy0wMCANCiAtIENvbmNlbnRyYXRlZCBsb29rIGF0IHVzZSBjYXNlICYgcmVxdWlyZW1lbnRz IGZvciB0aGUgbm9ydGgtYm91bmQgQVBJDQoNCiAtIFRoaXMgZ29lcyBmcm9tIHRoZSBjb21taXNz aW9uZXIgdG8gdGhlIGFwcGxpY2F0aW9uKHMpIGFib3ZlIGl0DQoNCiAtIENsZWFyIG5lZWQgZm9y IGEgZGF0YSBtb2RlbCB0aGF0IGNhbiBwcm92aWRlIGEgY29tbW9uIHZvY2FidWxhcnkNCiB0byBk ZXNjcmliZSB0aGUgZWxlbWVudHMgSVJTIGhhbmRsZXMNCg0KIC0gVGhpcyB1c2UgY2FzZSBoYXMg cHJvdG9jb2wgcmVxdWlyZW1lbnRzDQoNCg0KRHJhZnQgNjogZHJhZnQtcmZlcm5hZG8taXJzLWZy YW1ld29yay1yZXF1aXJlbWVudC0wMCANCiAtIHB1Ymxpc2gtc3Vic2NyaWJlIGZvciBhc3luY2hy b25vdXMgbm90aWZpY2F0aW9uIG9mIGV2ZW50cyB0aGF0IG9jY3VyDQogLSBwMnAgdHJhbnNwb3J0 IGNvbm5lY3Rpb24gYmV0d2VlbiBjbGllbnQgYW5kIGEgc2VydmVyLA0KIC0gSW4gb3JkZXIsIHJl bGlhYmxlIGRhdGEgZGVsaXZlcnkgaW4gYm90aCBkaXJlY3Rpb25zLA0KIC0gU2VjdXJpdHkgcmVx dWlyZW1lbnQ6IHNlcnZlciBuZWVkcyB0byB2YWxpZGF0ZSBpZGVudGl0eSBvZiBjbGllbnQsIGJl Zm9yZSBhbGxvd2luZyBjbGllbnQgdG8gcmVhZCBvciBwZXJmb3JtIHJlYWQtd3JpdGUgYWN0aW9u cw0KDQogLSBJbXBvcnRhbnQ6IGZyb20gYW4gYXBwbGljYXRpb24gdGhhdCBzaXRzIGFib3ZlIGl0 IC0gdGhlIGFwcGxpY2F0aW9uIHNob3VsZG4ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IHRoZSBtZWNo YW5pc21zIHRvIHByb3ZpZGUgc2VydmljZXMuIFRoZXJlIHNob3VsZCBiZSB0ZW1wbGF0ZXMgdGhh dCBjYW4gYmUgYWJzdHJhY3RlZCBmcm9tIHRoZSBuZXR3b3JrLg0KDQoNClJlcXVpcmVtZW50IFN1 bW1hcnkgDQogLSBOZWVkIHN0YW5kYXJkL2NvbW1vbiB2b2NhYnVsYXJ5IHRvIGRlc2NyaWJlIHRo ZSBmdW5jdGlvbmFsIG5ldHdvcmsgY29tcG9uZW50cyBpbiB0aGUgSVAgUm91dGluZyBTeXN0ZW0g d2l0aGluIFN0YW5kYXJkcy1iYXNlZCBkYXRhIG1vZGVscw0KDQogLSBOZWVkICJhcHBsaWNhdGlv biBmcmllbmRseSIgbWVjaGFuaXNtcyB0byByZXRyaWV2ZSBpbmZvcm1hdGlvbiBmcm9tDQogbmV0 d29yayBlbGVtZW50cyBhbmQgcHVzaCBjb25maWd1cmF0aW9uL3BvbGljaWVzL2V0Yy4gYmFjayBp bnRvIGdyb3VwcyBvZiBuZXR3b3JrIGVsZW1lbnRzLg0KDQoNCg0KT3ZlcmFsbA0KDQogLSBDcml0 aWNhbCBuZWVkIHRvIG1ha2UgZ2xvYmFsbHkgb3B0aW1pemVkIHJvdXRpbmcvZm9yd2FyZGluZyBh bmQgY29uZmlndXJhdGlvbiBjaGFuZ2VzIHRvIGVudGlyZSBuZXR3b3JrIA0KDQogLSBXaGVuIHRy eWluZyB0byBpbXByb3ZlIGVmZmljaWVuY3kgb3IgaGFuZGxlIERET1MgYXR0YWNrcywgbmVlZCBm aW5lLQ0KDQogZ3JhaW5lZCBpbmZsdWVuY2Ugb3ZlciByb3V0aW5nL2ZvcndhcmRpbmcgbWVjaGFu aXNtcyANCg0KDQoNClF1ZXN0aW9ucyAgLyBEaXNjdXNzaW9uOiANCiANCiAtIFJ1c3MgV2hpdGU6 IEFsdGhvdWdoIGl0IHNvdW5kcyBsaWtlIHdlIGFyZSB0cnlpbmcgdG8gYm9pbCB0aGUgb2NlYW4s IHdlIGFyZSB0cnlpbmcgdG8gbGlzdCBhbiBvY2VhbiBvZiByZXF1aXJlbWVudHMgYW5kIHRoZW4g dGFrZSBhIGN1cCBvZiBvY2VhbiB0byBzb2x2ZS4gVGhpcyBpc24ndCBhYm91dCByZXBsYWNpbmcg dGhlIHJvdXRpbmcgcHJvdG9jb2xzIGJ1dCwgb3BlbmluZyB1cCB0aGUgY29udHJvbCBwbGFuZSBv ZiByb3V0ZXJzIHRoYXQgd2UgdHdlYWsgZXZlcnlkYXkgaW4gYSBjb29yZGluYXRlZCB3YXkuDQoN CiAtIERhdmlkIExhbXBldGVyOiBUd28gZXhhbXBsZSB1c2UgY2FzZXMgKGNoYW5naW5nIElHUCBt ZXRyaWMgYW5kIEFTTiBjaGFuZ2VzKS4gTkVUTU9EIGlzIG1vZGVsaW5nIHRoZSByb3V0aW5nIHN5 c3RlbS4gV2hlbiBkbyB5b3UgdXNlIE5FVE1PRCB2cyBJUlM/DQpTaGFuZTogTmVlZCB0byBoYXZl IHJvdXRpbmcgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGluIGEgcG9saWN5IGZvcm0sIHRoZW4gSVJT DQogY2FuIHJldHJpZXZlIHRoYXQgaW4gTkVUTU9EIHRlbXBsYXRlcyBzbyB0aGF0IElSUyBjYW4g YWN0IG9uIGl0Lg0KDQoNCg0KIC0gU29tZW9uZSBIdXNzZWluIGZyb20gSW5maW5lcmE6IEZlZWxz IGxpa2UgeW91IGFyZSBwcm9wb3NpbmcgYSBzb2x1dGlvbiBmaXJzdCBhbmQgdGhlbiBhIHVzZSBj YXNlLCBuZWVkIHVzZSBjYXNlcyBmaXJzdA0KU2hhbmU6IEl0J3MgaW1wb3J0YW50IHRvIHJlY29n bml6ZSB0aGF0IHRoZXJlIGFyZSBleGlzdGluZyBzeXN0ZW1zIG91dCB0aGVyZSBub3cgKGUuZy4g c3RhdHMgY29sbGVjdGlvbnMgYW5kIGludmVudG9yeSBzeXN0ZW1zKSB0aGF0IGhhdmVuJ3QgYmVl biBmaXJzdCBjbGFzcyBjaXRpemVucywgYnV0IG5lZWQgdG8gYmUgZnJvbSBQb1Ygb2YgSVJTLiBU aGlzIGlzIGp1c3QgYSBzdHJhdyBtYW4gcHJvcG9zYWwuIA0KDQogLSBTSCAobm90IHN1cmUgd2hv IHRoaXMgd2FzKTogQnJpZWZseSBtZW50aW9uZWQgb3B0aWNhbCBlbmhhbmNlbWVudHMsIHdpbGwg eW91IGJlIGxvb2tpbmcgYXQgb3B0aWNhbCB0b3BvbG9neT8gDQpTaGFuZTogRXZlbnR1YWxseSwg dGhhdCB3b3VsZCBiZSBuaWNlLiAgVG8gZ2V0IHN0YXJ0ZWQsIHRoYXQncyBtb3N0IGxpa2VseSB0 b28gbXVjaCB0byBiaXRlIG9mZiwgc28gYW0gd2lsbGluZyB0byBmb2N1cyBqdXN0IG9uIElQL01Q TFMgbmV0d29ya3MgZm9yIG5vdy4NCg0KDQogLSBFZCBDcmFiYmU6IFNvdW5kcyBsaWtlIHlvdSBh cmUgY29uZnVzaW5nIHdoYXQncyBhdmFpbGFibGUgZnJvbSBTTk1QDQpTaGFuZTogVGhlcmUgYXJl IGV4aXN0aW5nIHByb3RvY29scyB0byB0YWxrIHdpdGggdHJhbnNwb25kZXJzIGFuZCBpZiB3ZSBj YW4gcmV1c2UgdGhlbSwgZ3JlYXQgYnV0LCB3aGF0J3MgbWlzc2luZyBpcyB0aGUgY29vcmRpbmF0 aW9uIG1lY2hhbmlzbS4gQ2FuIGRvIHNvbWV0aGluZyB2ZXJ5IHNpbXBsZSB0b2RheSB2aWEgdGhl IENMSSBidXQsIEkgaG9wZSB3ZSBnZXQgYmV5b25kIHRoYXQuDQoNCg0KIC0gRWQ6IFNlZW1zIGRh bmdlcm91cyB0byB0YWxrIGFib3V0IHJlcGxhY2luZyBhbGwga25vd24gcHJvdG9jb2xzDQpTaGFu ZTogTm90IHNheWluZyB0aGF0LiBTYXlpbmcgdGhhdCBJIHdhbnQgYSBkYXRhIG1vZGVsLCBub3Qg VEwxIG9yIENMSS4NCg0KDQogLSBSdWRpZ2VyIFZvbGs6IEmSbSBjb25mdXNlZC4gSkgncyBzbGlk ZXMgc2hvd2VkIGludGVyZmFjZXMgdGhhdCBleGVyY2lzZSBtb3JlIGNvbnRyb2wuIFdoYXQgSZJt IGhlYXJpbmcgZnJvbSB5b3UgU2hhbmUgaXMgdGhhdCBJIHdhbnQgdG8gZG8gYWxsIGNvbnRyb2wg b2YgdGhlIHN5c3RlbSBhbmQgZG93bmxvYWQgcG9saWNpZXMuIElzIHRoZSBnb2FsIHRvIGJ1aWxk IG11bHRpcGxlIGludGVyYWN0aW5nIGNvbW1pc3Npb25lcnMgb3IgZG8gd2UgaGF2ZSBzb21ld2hh dCBtb3JlIG1vZGVzdCBnb2FscyBoZXJlLg0KU2hhbmU6IFRoaXMgaXMgYW4gZW50aXJlIHRheG9u b215IG9mIHVzZSBjYXNlcy4gU2hvdWxkIGRpc2N1c3MgdGhhdCB3aGVuIHdlIGRpc2N1c3Mgd2hh dCBpcyBjaGFydGVyIG9mIFdHLg0KDQoNCg0KSVYuIENoYXJ0ZXIgT3ZlcnZpZXcgLSBSb3NzIENh bGxvbg0KDQpXR3MgZG8gYmVzdCB3aXRoIGxpbWl0ZWQgZGVmaW5lZCBjaGFydGVycywgT0sgdG8g cG9zdHBvbmUgc29tZSB3b3JrIHRvIGxhdGVyLqAgDQoNCklzc3VloHRoYXQgY2FtZSB1cCBpbiBk aXNjdXNzaW9uIG9mIGRyYWZ0IGNoYXJ0ZXIgdGhhdCBoYWQgYmVlbiBtYWlsZWQgdG8gdGhlIGly cy1kaXNjdXNzIGxpc3Q6IEZhc3QgcGF0aCB2cyBTbG93IHBhdGguIEZhc3QgdmVyc3VzIHNsb3cg aXMgcmVsYXRpdmUuIFdlIGRvIG5vdCB3YW50IHRvIGNvbmZ1c2UgaW1wbGVtZW50YXRpb24gdmVy c3VzIHN0YW5kYXJkcy4NCg0KV2hpY2ggcHJvdG9jb2wgLSBhbiBleGlzdGluZyBwcm90b2NvbCBv ciBkZWZpbmUgYSBuZXcgb25lIHByb3RvY29sP6AgDQogLSBUaGUgV0cgbmVlZHMgdG8gZmlndXJl IHRoaXMgb3V0DQoNCkluaXRpYWwgY2hhcnRlciCWIGZvY3VzZXMgb24gdXNlIGNhc2VzLCBub3Qg cHJvdG9jb2wuoEkgZG91YnQgd2Ugd2lsbCBkZWZpbmUgYSBuZXcgcHJvdG9jb2wsIG1vcmUgbGlr ZWx5IHdlIHdpbGwgdXNlIGFuIGV4aXN0aW5nIHByb3RvY29sLg0KDQpJc3N1ZSB3aXRoIHJlZ2Fy ZCB0byBVc2UgQ2FzZXMgDQogLSBUaWdodGx5IHNjb3BlZCBrZXkgdXNlIGNhc2VzIGZvciBvcGVy YXRpb25hbCB1c2Ugb2YgSVJTLqANCiAtIFRleHQgaW4gZHJhZnQgY2hhcnRlciBzdGF0ZXMgk3Ro ZXNlIHVzZSBjYXNlcyB3aWxsIGluY2x1ZGUgYXQgbGVhc3SUIChzZWUgbW9yZSBkZXRhaWwgaW4g ZHJhZnQgY2hhcnRlciBzZW50IHRvIElSUy1kaXNjdXNzIGxpc3QpLiBRdWVzdGlvbiBoYXMgYmVl biBhc2tlZDogRG9lcyB0aGlzIHByZWNsdWRlIG90aGVyIHVzZSBjYXNlcz+gDQogLSBOby0tIGJ1 dCB3ZSBuZWVkIHRvIGZvY3VzIHRvIG1ha2UgcHJvZ3Jlc3MNCg0KKFEmQSBwb3N0cG9uZWQgdW50 aWwgYWZ0ZXIgRGF2ZSBXYXJkknMgdGFsaykNCg0KDQpWLiBPYnZpb3VzIFF1ZXN0aW9ucyAtIERh dmUgV2FyZA0KDQpIb3cgYmlnIGlzIHRoZSBjb21tdW5pdHkgd29ya2luZyBvbiBJUlM/oCANCiAt IDQwOCBtZW1iZXJzIG9mIG1haWxpbmcgbGlzdA0KIC0gMTEgZHJhZnRzLCBsb3RzIG9mIGF1dGhv cnOgDQogLSAyNSUgb3BlcmF0b3JzLCAzNSUgdmVuZG9ycywgMjUlIGFjYWRlbWljcyBvciBvdGhl cg0KDQpXaGF0IGFib3V0IG15IHVzZSBDYXNlP6AgDQogLSBUaGUgbnVtYmVyIG9mIHVzZSBjYXNl cyBiZWluZyB3cml0dGVuIHVwIGlzIGdyZWF0ZXIgdGhhbiBvbmUNCiAtIEV2YWx1YXRpb24gb2Yg dXNlIGNhc2UgaXMgdG8gYmUgY29uc2lkZXJlZCBleGFtcGxlIG5vdCBjYW5vbmljYWwgZGVzaWdu DQogLSBUaGV5IGFyZSB0byBtYWtlIHN1cmUgd2UgaGF2ZSByZWFzb25hYmxlIHRhcmdldHMgbm90 IHRoZSBvbmx5IHRhcmdldHMgZm9yIHRoZSB0ZWNobm9sb2d5LA0KDQpNeSBlbmNvZGluZyBpcyB0 aGUgcHJldHRpZXN0IA0KIC0gTm8gaXQgaXNuJ3SgDQogLSBOb25lIGFyZSBwZXJmZWN0IHRvZGF5 LA0KIC0gRmlyc3Qgd2Ugc3RhcnQgd2l0aCB0aGUgZGF0YSBtb2RlbCwgYW5kIGVuY29kaW5nDQoN ClJlY2FwOiBJUlMgYW5kIFByb2dyYW1taW5nIA0KIC0gSVJTIGlzIGEgbWVjaGFuaXNtIHRvIGxl YXJuIHN0YXRlIGZyb20gdGhlIG5ldHdvcmsNCiAtIChzZWUgc2xpZGVzKaANCg0KSVJTIENvbmNl cm5zDQogLSAobG9uZyBsaXN0LCBzZWUgc2xpZGVzKQ0KDQpDYW5kaWRhdGVzIGZvciBzZXNzaW9u IGFuZCBkYXRhIG1vZGVsaW5nDQpQcm9zOiAoc2VlIHNsaWRlKSB5YW5nLCBtb2R1bGFyLKANCkdh cHM6IG9wZXJhdGlvbmFsIHN0YXRlLCBzdGF0ZSBwZXJzaXN0ZW5jZSwgc3RhdGUgb3duZXJzaGlw LCBIQSBzZW1hbnRpY3MsIHBsdWdnYWJsZSBvbi10aGUtd2lyZSwNCg0KVG9wb2xvZ3kgdG9vbHMN CiAtIEN1cnJlbnQgdGVhbSBpbnZlc3RpZ2F0aW5nIE5ldGNvbmYveWFuZyBhcHBsaWNhYmlsaXR5 IHRvIElSUyANCiAgICAtIFJleCBmZXJhbmRvIChyZXhAY2lzY28uY29tKQ0KICAgIC0gTWFydGlu IEJqb3JrbHVuZCAobWJnQHRhaWxmLmNvKQ0KICAgIC0gQnJ1bm8gUmlqc21hbiAoQnJpanNtYW5A anVuaXBlci5uZXQpDQoNCg0KVkkuIE9wZW4gRGlzY3Vzc2lvbg0KDQpMb3UgQmVyZ2VyOiBEZWZp bml0aW9uIG9mIHRvcG9sb2d5IHRvbyBicm9hZDogT1ROLCBXRE0sIEwyLCBNUExTLCBWUE4sIGV2 ZXJ5dGhpbmcuIFdoYXQncyBpbiBzY29wZSBvciBvdXQgb2Ygc2NvcGUgSSBjYW4ndCB0ZWxsLiBF aXRoZXIgZXhwYW5kIG9uIGRlZmluaXRpb24gb3IgInBpY2sgdGhpcyB1c2UgY2FzZSIgU2hvdWxk IGJlIHBhcnQgb2YgdGhlIGNoYXJ0ZXIgZm9yIHByb3BlciBzY29waW5nLg0KDQpNYXJnYXJldCBX YXNzZXJtYW46IFdlIHRyaWVkIGEgbG90IG9mIHRpbWUgaG93IHlvdSBhcmUgZ29pbmcgdG8gbWFu YWdlIA0KZGV2aWNlcy4gQWxsIGhhdmUgaGFkIHNpbWlsYXIgcHJvYmxlbSCFIGlmIHlvdSBjYW4g b25seSBtYW5hZ2Ugb25seSBhIHN1YnNldCBvZiBmdW5jdGlvbmFsaXR5IG9uIGEgcGllY2Ugb2Yg ZXF1aXBtZW50IGFuZCB0aGVyZWZvcmUgcnVuIGFub3RoZXIgInRoaW5nIiB0byBjb250cm9sIHRo ZSByZXN0IG9mIHRoZSBlcXVpcG1lbnQuIFdoeSBpcyB0aGlzIHNpdHVhdGlvbiBkaWZmZXJlbnQ/ IFdoeSBpcyBhIGNvbW1vbiBzdWJzZXQgdXNlZnVsIG5vdz8NCg0KTWFyZ2FyZXQgVzogVmVyeSBh ZnJhaWQgdGhhdCBpdCB3YXMgc3RhdGVkIHNvIG1hbnkgdGltZXMgIm5vdCBib2lsIHRoZSBvY2Vh biIgdGhhdCB0aGlzIGNhdXNlcyBjb25jZXJuLg0KDQpSdWRpZ2VyIFZvbGs6IDxtaW51dGUgdGFr ZXIgZGlkIG5vdCBjYXRjaD4NCg0KSmFtYWw6IFdlIGFyZSBub3QgdGFsa2luZyBhYm91dCBwcm90 b2NvbHMsIHdoeSBhcmUgd2UgdGFsa2luZyBhYm91dCBOQy9ZPyBDYW4gSSB3cml0ZSBhIGRyYWZ0 IG9uIG15IGZhdm9yaXRlIHByb3RvY29sPw0KUm9zczogWWVzDQoNCkRhdmlkIExhbXBldGVyOiBD bGFzc2ljIGNvbmZpZyBwcm90b2NvbHMgYXJlIHNsb3cgcGF0aCwgd2hhdCBpcyB0aGUgZmFzdCAN CnBhdGg/DQoNCj86IElzIHRoaXMgU0ROPw0KQTogSXQgaXMgcmVsYXRlZC4NCg0KQ2hyaXMgTDog V2hhdCBhcmUgTm9ydGhib3VuZCBBUElzIG9uIHRvcCBvZiB0aGUgY29tbWlzc2lvbmVyIGFuZCB0 aGF0IG1pZ2h0IGRlZmluZSB3aGF0IHdlIG5lZWQgc291dGhib3VuZC4gV2hhdCBjYW4gd2UgdXNl L2FidXNlIGluIHRoZSBJRVRGDQoNClNoYW5lIEFtYW50ZTogU2hlIG1heSBiZSBjb25jZXJuZWQg d2l0aCByYXRlIG9mIGFkb3B0aW9uIIUgdGhpcyB3b3JrIGlzIHVzaW5nIGV4aXN0aW5nIGZvcndh cmRpbmcgYW5kIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2xzIHdlIGhhdmUgdG9kYXkuIFRoZSBtb3N0 IHRpbWUgY29uc3VtaW5nIGVmZm9ydCBpcyBkZXBsb3lpbmcgbmV3IGNvbnRyb2wgYW5kIGZvcndh cmRpbmcgcGxhbmUgcHJvdG9jb2xzLiBUaGUgcmV1c2Ugb2YgZXhpc3RpbmcgcHJvdG9jb2xzIGFu ZCBhdWdtZW50aW5nIHRoZW0gaXMgY3JpdGljYWwuDQoNCkRtaXRyaTogY29uY2VybiBvZiB0aGUg bW9kZWxpbmcgd29yay4gSXQgc2hvdWxkIGJlIG5vdCBsaW1pdGVkIHRvIGluZm9ybWF0aW9uIG1v ZGVsIGZpcnN0LiBBIGRlZmluaXRpb24gb2YgYW4gYWdlbnQgdGhhdCB3YXMgdXNlZCBieSBKb2Vs IG1heSBsaW1pdCB0aGUgd29yay4gRnVuY3Rpb24gYW5kIG1lbW9yeSBhbmQgbmVlZCBzdGF0ZQ0K DQpCcmlhbiBEaXhvbjogVGhlIHNsb3cgcGF0aCB2cyBmYXN0IHBhdGguIFZlbmRvcnMgc2hvdWxk IG5vdCBpbXBsZW1lbnQgdGhpcyBieSBtYWtpbmcgYSBnYXRld2F5IHRvIHRoZSBjbGkgYW5kIHRo ZSBjb21taXNzaW9uZXIgY291bGQgYmUgYSBDTEkuIFRoZSBiZXN0IHdheSB0byB2aWV3IHRoaXMg aXMgYXMgbm90IGFzIGEgcHJvdG9jb2wgaW50ZWdyYXRpb24gYnV0LCBhIGhvcml6b250YWwgaW50 ZWdyYXRpb24gYWNyb3NzIGVsZW1lbnRzIGFjcm9zcyBhbiBlbnRpcmUgbmV0d29yay4gTm90IGFs bCBvZiB0aGUgZnVuY3Rpb25zIGJ1dCwgYWxsIHRoZSBjbGFzc2VzIG9mIGJlaGF2aW9yLg0KDQpX ZXMgSGFydGlrZXI6IEkgZG9uJ3QgdGhpbmsgeW91IGFyZSB0cnlpbmcgdG8gYm9pbCBhbiBvY2Vh biBidXQgcmF0aGVyLCBhIGJvZHkgb2Ygd2F0ZXIgb24gYSBkaXN0YW50IHBsYW5ldC4gVGhlIGJv ZHkgb2Ygd29yayBpcyBiaWdnZXIgdGhhbiBiZWhhdmUuIFRvIGF2b2lkIHRoZSBkZXNpZ24gYnkg Y29tbWl0dGVlIGlzIHRvIHRoaW5rIGFib3V0OiBkbyB3ZSBoYXZlIHRvIGRvIGFsbCBvZiB0aGlz IGF0IG9uY2U/IE1hbmFnaW5nIHRoZSBtdWx0aXBsZSBSSUJzIGlzIGhhcmQgZW5vdWdoLg0KDQpS dWRpZ2VyIFZvbGs6IFdoYXQgaXMgdGhlIGFic29sdXRlIGtleSBpc3N1ZSBpcyB0aGUgZGF0YSBt b2RlbGluZy4gVG8gYW5zd2VyIChkaWRuknQgZ2V0IHJlc3QpDQoNCk1hcmdhcmV0OiB0aGUgd29y ayBmb3IgZ2V0dGluZyBhIG1vcmUgdW5pZmllZCBzb2x1dGlvbiB0byBnZXQgdG8gDQptYW5hZ2lu ZyBhIGRldmljZSBoYXMgdGFrZW4gZGVjYWRlcyBhbmQgdGhlIGRhdGEgbW9kZWxpbmcgZm9yIGFs bCB0aGUgdXN1YWwgZmVhdHVyZXMghSB0byBkbyBldmVyeXRoaW5nIChtb2RlbCkgYW5kIHJlcXVl c3QgbmV3IHdheXMgZm9yIGNoYW5naW5nIGV2ZXJ5dGhpbmcuIFVzZSBjYXNlcyBkZWZpbmluZyBk YXRhIG1vZGVscy4gV29ya2luZyB0b28gc2xvdyBvciB0b28gZmFzdCCFIHRoYXQgc2hvdWxkIGJl IHBvdGVudGlhbCBvcHRpbWl6YXRpb25zDQoNClBldGVyIExvdGhiZXJnOiBWZXJ5IGhhcHB5IHRv IHNlZSB0aGF0IG1vZGVsaW5nIG9wdGljYWwgZGV2aWNlcyBpcyBpbiB0aGVyZS4gVG9kYXkgdGhl eSBoYXZlIHRvIGRvIDJrIHRyYW5zYWN0aW9ucyBhIHNlY29uZC4NCg0KU2hvd3Mgb2YgaGFuZHM6 IA0KDQpQZW9wbGUgaW50ZXJlc3RlZCBpbiBoZWxwaW5nIHdpdGggdGhpcyB3b3JrOg0KfjQwIGlu dGVyZXN0ZWQgaW4gdGhpcyB3b3JrDQoNClNob3VsZCB3ZSBmb3JtIGEgV0c6DQp+NjAgZm9yIFdH IGZvcm1hdGlvbg0KfjYgZm9yIG5vdCBhIFdHIHRvIGJlIGZvcm1lZA0KDQpDb21wYXJlZCB0byBj dXJyZW50IGRyYWZ0IGNoYXJ0ZXIsIGhvdyBtYW55IGRlbGl2ZXJhYmxlcyBzaG91bGQgd2UgaGF2 ZToNCmN1cnJlbnQgc2V0OiAxMg0KZmV3ZXIgZG9jczogMzANCndob2xseSBkaWZmZXJlbnQ6IDAN Cg0KQ29tbWVudDogUGxlYXNlIGFkZCBzZWN1cml0eQ0KDQpBRHMgLyBDaGFpcnM6IE5leHQgc3Rl cCBpcyB0byBjb250aW51ZSB0byBkaXNjdXNzIGNoYXJ0ZXIsIHdoYXQgZG9jcyB0byBkcm9wLCBl dGMuIFRoYW5rcy4gDQoNCg0K --_004_62CCD4C52ACDAD4481149BD5D8A72FD309A0A184CH1PRD0510MB355_-- From adrian@olddog.co.uk Fri Dec 21 11:35:43 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595AD21F85CC for ; Fri, 21 Dec 2012 11:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 P65j6TfoIWQB for ; Fri, 21 Dec 2012 11:35:42 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95121F846B for ; Fri, 21 Dec 2012 11:35:42 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBLJZfko030355 for ; Fri, 21 Dec 2012 19:35:41 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBLJZevi030345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Dec 2012 19:35:40 GMT From: "Adrian Farrel" To: Date: Fri, 21 Dec 2012 19:35:36 -0000 Message-ID: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: Ac3fsc4mH9TFJeD7SA6kUf6n6rDprA== Subject: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 19:35:43 -0000 Hi, I have ploughed through the emails discussing the charter and come up with some minor tweaks. 1. "Interface" There was a strong desire to separate the two meanings of "interface". However, the solutions suggested were all rather variable. In fact, the word is only used in the first paragraph of the charter, so it seems best to be long-winded for the sake of clarity. This leads to: == A routing system is all or part of a routing network. A part of a routing network may be a single router or a collection of routers. The routing system may be further divided to be an interface over which data traffic is forwarded, or a collection of such interfaces. I2RS facilitates real-time or event driven interaction with the routing system through a collection of control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and between multiple interactions with the routing system. == 2. Include Control Plane Protocols This got immediate support and leads to: == A routing system is all or part of a routing network. A part of a routing network may be a single router or a collection of routers. The routing system may be further divided to be an interface over which data traffic is forwarded, or a collection of such interfaces. The routing system also includes the control plane protocols that operate the routers. I2RS facilitates real-time or event driven interaction with the routing system through a collection of control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and between multiple interactions with the routing system. == 3. Rationalise the Use Cases There was good support in theory (at the BoF) for reducing / focussing the use cases., but as I predicted, the rule of thumb is "Cut out other people's use cases. Leave mine in." There were some emails of a generally supportive nature for focussing the use cases a bit better, and some suggestions for additional (but focussed) use cases. Here is my suggestion based on: draft-atlas-irs-problem-statement section 3 draft-keyupate-irs-bgp-usecases draft-white-irs-use-case-00.txt section 2 draft-white-irs-use-case-00.txt section 3 draft-white-irs-use-case-00.txt section 4 draft-amante-irs-topology-use-cases == OLD - Tightly scoped key use cases for operational use of I2RS. These use cases will include at least: o Interactions with the RIB. o Association of routing policies with routing state. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as an initial work item. Other use cases may be adopted by the working group only after milestones have been added to the charter page. NEW - Tightly scoped key use cases for operational use of I2RS. These use cases will include at least: o Interactions with the RIB. Allowing read and write access to the RIB and to the policies used to construct the FIB, but no direct access to the FIB. o Control and analysis of the operation of BGP including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through quickly modification of the control plane behavior to reroute traffic for one destination while leaving a standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as an initial work item. Other use cases may be adopted by the working group only after milestones have been added to the charter page. END == 4. Rationalise milestones There was concern that each and every document did not need to be listed in the milestones. And it was noted that the chairs (once the WG is running) can add milestones as they consider useful. Additionally, we need to have some proposed dates against the milestones. That leads to: == Jul 2013 : Request publication of an Informational document defining the problem statement Jul 2013 : Request publication of an Informational document defining the architecture framework Aug 2013 : Request publication of Informational documents describing use cases Sep 2013 : Request publication of an Informational document defining the protocol requirements Sep 2013 : Request publication of an Informational document defining encoding language requirements Nov 2013 : Request publication of Standards Track documents specifying information models Nov 2013 : Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Dec 2013 : Consider re-chartering == I have made these changes and updated the draft charter at http://datatracker.ietf.org/doc/charter-ietf-i2rs/ It is my intention to put this charter to the IESG early in the New Year. So please review and comment heartily. Thanks, Adrian From abdussalambaryun@gmail.com Sat Dec 22 06:25:55 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4652C21F8B13 for ; Sat, 22 Dec 2012 06:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 f3GFg4VEC+A0 for ; Sat, 22 Dec 2012 06:25:54 -0800 (PST) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5126421F85E2 for ; Sat, 22 Dec 2012 06:25:54 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p1so6234738vbi.32 for ; Sat, 22 Dec 2012 06:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ziVb+k/l4F9b7Kf5Hbhsqdp/awpLd2sPpoEU2gDzRq4=; b=F/yaLzxOUfcJXrvgo5Zj0GMEixy7GqM0dNjEf297b8h//GUEJ9LKJBNBYntwSs58sL fHKPidnKZg7m4BSlOmcTQQ7XB29d2/evVzJk0UNJj5VK6r2PchCfnRdM+eyfs3YiislF s/miQREDYgLpesk8QDd3juYVpdJp7ymIAt3dRsuCbfYSVPq8ZujqeJptL03wxBT+XuLa t13jt6fcRgnU1X0XFek7TJDP1amNymTmY+x395Ze2z8bpbcXRCpn0+R9oH3d64d8MQqy p1rIzz7x5C8PH6pWAt8mfz+bAT5WtBT7MwVfHYPLc71ThKc1fJenh193r+2gExTrwbAa C5lg== MIME-Version: 1.0 Received: by 10.52.70.46 with SMTP id j14mr21345210vdu.99.1356186353380; Sat, 22 Dec 2012 06:25:53 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sat, 22 Dec 2012 06:25:53 -0800 (PST) In-Reply-To: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> Date: Sat, 22 Dec 2012 15:25:53 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 14:25:55 -0000 Thanks Adrian, I support including both 1 and 2, but if I need to choose then prefer 1, comments in lines; On 12/21/12, Adrian Farrel wrote: > Hi, > > I have ploughed through the emails discussing the charter and come up with > some > minor tweaks. > > 1. "Interface" > There was a strong desire to separate the two meanings of "interface". > However, > the solutions suggested were all rather variable. In fact, the word is only > used > in the first paragraph of the charter, so it seems best to be long-winded > for > the sake of clarity. This leads to: > > == > A routing system is all or part of a routing network. A part of a routing > network may be a single router or a collection of routers. The routing > system > may be further divided to be an interface over which data traffic is > forwarded, > or a collection of such interfaces. AB>Suggest Amend> A routing system SHOULD be in all or part of the routing network. AB> Amend to> The routing system may be further divided by an interface over which data traffic can be forwarded, or by a collection of such interfaces. > > I2RS facilitates real-time or event driven interaction with the routing > system > through a collection of control or management interfaces. These allow > information, policies, and operational parameters to be injected into and > retrieved (as read or notification) from the routing system while retaining > data > consistency and coherency across the routers and routing infrastructure, > and > between multiple interactions with the routing system. > == AB> replace: between with among > > 2. Include Control Plane Protocols > This got immediate support and leads to: > I think If included we need to define the interface within this plane, separating I2RS protocol and the control operation protocol. > == > A routing system is all or part of a routing network. A part of a routing > network may be a single router or a collection of routers. The routing > system > may be further divided to be an interface over which data traffic is > forwarded, > or a collection of such interfaces. The routing system also includes the > control plane protocols that operate the routers. > AB> Amend> The routing system also includes the operational protocols that are within control plane that operate the routers. > I2RS facilitates real-time or event driven interaction with the routing > system > through a collection of control or management interfaces. These allow > information, policies, and operational parameters to be injected into and > retrieved (as read or notification) from the routing system while retaining > data > consistency and coherency across the routers and routing infrastructure, > and > between multiple interactions with the routing system. > == > > 3. Rationalise the Use Cases > There was good support in theory (at the BoF) for reducing / focussing the > use > cases., but as I predicted, the rule of thumb is "Cut out other people's > use > cases. Leave mine in." > There were some emails of a generally supportive nature for focussing the > use > cases a bit better, and some suggestions for additional (but focussed) use > cases. > Here is my suggestion based on: > draft-atlas-irs-problem-statement section 3 > draft-keyupate-irs-bgp-usecases > draft-white-irs-use-case-00.txt section 2 > draft-white-irs-use-case-00.txt section 3 > draft-white-irs-use-case-00.txt section 4 > draft-amante-irs-topology-use-cases no objection, as after a year we may recharter :) > == > OLD > - Tightly scoped key use cases for operational use of I2RS. These use cases > will > include at least: > o Interactions with the RIB. > o Association of routing policies with routing state. > o The ability to extract information about topology from the > network. Injection and creation of topology will not be > considered as an initial work item. > > Other use cases may be adopted by the working group only after > milestones > have been added to the charter page. > NEW > - Tightly scoped key use cases for operational use of I2RS. These use cases > will > include at least: > o Interactions with the RIB. Allowing read and write access to the RIB > and to > the policies used to construct the FIB, but no direct access to the FIB. > o Control and analysis of the operation of BGP including the setting and > activation of policies related to the protocol. > o Control, optimization, and choice of traffic exit points from networks > based on more information than provided by the dynamic control plane. > o Distributed reaction to network-based attacks through quickly > modification > of the control plane behavior to reroute traffic for one destination while > leaving a standard mechanisms (filters, metrics, and policy) in place for > other > routes. > o Service layer routing to improve on existing hub-and-spoke traffic > o The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as an initial > work > item. > > Other use cases may be adopted by the working group only after > milestones > have been added to the charter page. > END > == agree > > 4. Rationalise milestones > There was concern that each and every document did not need to be listed in > the > milestones. And it was noted that the chairs (once the WG is running) can > add > milestones as they consider useful. > Additionally, we need to have some proposed dates against the milestones. > That leads to: > Yes preferable we can leave it after in the meetings and discussion while the work and efforts is flowing, so I agree with your suggest. > == > Jul 2013 : Request publication of an Informational document defining the > problem > statement > Jul 2013 : Request publication of an Informational document defining the > architecture framework > Aug 2013 : Request publication of Informational documents describing use > cases > Sep 2013 : Request publication of an Informational document defining the > protocol requirements > Sep 2013 : Request publication of an Informational document defining > encoding > language requirements > Nov 2013 : Request publication of Standards Track documents specifying > information models > Nov 2013 : Request publication of an Informational document providing an > analysis of existing IETF and other protocols and encoding languages against > the > requirements > Dec 2013 : Consider re-chartering +1 for the above, > == > > I have made these changes and updated the draft charter at > http://datatracker.ietf.org/doc/charter-ietf-i2rs/ > Thanks > It is my intention to put this charter to the IESG early in the New Year. +1 with above, > So > please review and comment heartily. > > Thanks, > Adrian > Thanking you AB > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From adrian@olddog.co.uk Sun Dec 23 03:40:03 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B597021F8722 for ; Sun, 23 Dec 2012 03:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_27=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 w3xqOlKHP9cm for ; Sun, 23 Dec 2012 03:40:03 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0784721F8731 for ; Sun, 23 Dec 2012 03:40:02 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNBe07f001283; Sun, 23 Dec 2012 11:40:00 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNBdxwY001248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Dec 2012 11:40:00 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> In-Reply-To: Date: Sun, 23 Dec 2012 11:39:55 -0000 Message-ID: <007c01cde102$3b4c4210$b1e4c630$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEswVCPW8JU8hFpBIVJxKGn6yXYJADv9CA8mWD/0pA= Content-Language: en-gb Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 11:40:03 -0000 Hi Abdussalam, Thanks for contributing. > > A routing system is all or part of a routing network. A part of a routing > > network may be a single router or a collection of routers. The routing > > system may be further divided to be an interface over which data >> traffic is forwarded, or a collection of such interfaces. > > AB>Suggest Amend> A routing system SHOULD be in all or part of the > routing network. Not sure what you mean. The use of upper case here would have no meaning. How is "should be in" more useful that "is"? > AB> Amend to> The routing system may be further divided by an > interface over which data traffic can be forwarded, or by a collection > of such interfaces. You have s/to be/by/ Doesn't "by" imply that it is the interface that does the dividing? I don't think that language works. > > I2RS facilitates real-time or event driven interaction with the routing > > system through a collection of control or management interfaces. > > These allow information, policies, and operational parameters to be > > injected into and retrieved (as read or notification) from the routing > > system while retaining data consistency and coherency across the > > routers and routing infrastructure, and between multiple interactions > > with the routing system. > > AB> replace: between with among Fine. > > 2. Include Control Plane Protocols > > This got immediate support and leads to: > > I think If included we need to define the interface within this plane, > separating I2RS protocol and the control operation protocol. > > > == > > A routing system is all or part of a routing network. A part of a routing > > network may be a single router or a collection of routers. The routing > > system may be further divided to be an interface over which data > > traffic is forwarded, or a collection of such interfaces. The routing > > system also includes the control plane protocols that operate the > > routers. > > AB> Amend> The routing system also includes the operational protocols > that are within control plane that operate the routers. I think an "operational protocol that is within the control plane" is a "control plane protocol." Thanks, Adrian From jclarke@cisco.com Sun Dec 23 07:17:01 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1217021F87EA for ; Sun, 23 Dec 2012 07:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.058 X-Spam-Level: X-Spam-Status: No, score=-10.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_RHS_DOB=1.083] 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 N5+b-iYFeEZY for ; Sun, 23 Dec 2012 07:17:00 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 183F521F878A for ; Sun, 23 Dec 2012 07:17:00 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBNFGwUW023448; Sun, 23 Dec 2012 10:16:58 -0500 (EST) Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBNFGwbV022755; Sun, 23 Dec 2012 10:16:58 -0500 (EST) Message-ID: <50D7206A.6000109@cisco.com> Date: Sun, 23 Dec 2012 10:16:58 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> In-Reply-To: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 15:17:01 -0000 On 12/21/12 2:35 PM, Adrian Farrel wrote: > Hi, > > I have ploughed through the emails discussing the charter and come up with some > minor tweaks. > > 1. "Interface" > There was a strong desire to separate the two meanings of "interface". However, > the solutions suggested were all rather variable. In fact, the word is only used > in the first paragraph of the charter, so it seems best to be long-winded for > the sake of clarity. This leads to: > > == > A routing system is all or part of a routing network. A part of a routing > network may be a single router or a collection of routers. The routing system > may be further divided to be an interface over which data traffic is forwarded, > or a collection of such interfaces. > > I2RS facilitates real-time or event driven interaction with the routing system > through a collection of control or management interfaces. These allow > information, policies, and operational parameters to be injected into and > retrieved (as read or notification) from the routing system while retaining data > consistency and coherency across the routers and routing infrastructure, and > between multiple interactions with the routing system. > == I know this was bikeshedded quite a bit -- and I have no objection to the dual meaning -- but I do think that these two paragraphs mix "interface" in a way that might be confusing. A "router" already has a management "interface" (either virtual or physical) and that is independent of the "interface" mentioned in paragraph two. Unfortunately, I don't have a better suggestion other than putting the word "programmatic" or "structured" in there to help disambiguate the two uses. However, since this has been beaten to death, and this is what the majority agrees to, then so be it. More of a nit, but I think the parenthetical portion should read, "(as read or by notification) > Aug 2013 : Request publication of Informational documents describing use cases While it's written correctly here, you have two 'b's in "describing" in the web charter. > I have made these changes and updated the draft charter at > http://datatracker.ietf.org/doc/charter-ietf-i2rs/ > >From the web charter: "The I2RS working group works to develop a framework and architecture that will enable specific use cases, and lead to an understanding of the informational models and requirements for encodings and protocols. Small and well-scoped use cases are critical to constrain the scope of the work and achieve sufficient focus for the working group to deliver successfully. Initial work within the working group will be limited to within a single administrative domain." Another grammatical nit, but perhaps the last two sentences could read: "Small and well-scoped use cases are critical to constrain the scope of the work an achieve sufficient focus for the working group to deliver successful outcomes. Initial work within the working group will be limited to a single administrative domain." Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From adrian@olddog.co.uk Sun Dec 23 09:03:56 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3971021F85FC for ; Sun, 23 Dec 2012 09:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 1sosVL7ordRd for ; Sun, 23 Dec 2012 09:03:55 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0FE21F84F2 for ; Sun, 23 Dec 2012 09:03:55 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNH3oVr021995; Sun, 23 Dec 2012 17:03:50 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNH3nsD021984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Dec 2012 17:03:49 GMT From: "Adrian Farrel" To: "'Joe Marcus Clarke'" References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <50D7206A.6000109@cisco.com> In-Reply-To: <50D7206A.6000109@cisco.com> Date: Sun, 23 Dec 2012 17:03:44 -0000 Message-ID: <000b01cde12f$780af930$6820eb90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEswVCPW8JU8hFpBIVJxKGn6yXYJALAQVE4mVLZOCA= Content-Language: en-gb Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 17:03:56 -0000 Thanks Joe, > > A routing system is all or part of a routing network. A part of a routing > > network may be a single router or a collection of routers. The routing system > > may be further divided to be an interface over which data traffic is forwarded, > > or a collection of such interfaces. > > > > I2RS facilitates real-time or event driven interaction with the routing system > > through a collection of control or management interfaces. These allow > > information, policies, and operational parameters to be injected into and > > retrieved (as read or notification) from the routing system while retaining data > > consistency and coherency across the routers and routing infrastructure, and > > between multiple interactions with the routing system. > > I know this was bikeshedded quite a bit -- A bit? ;-) > and I have no objection to > the dual meaning -- but I do think that these two paragraphs mix > "interface" in a way that might be confusing. A "router" already has a > management "interface" (either virtual or physical) and that is > independent of the "interface" mentioned in paragraph two. > Unfortunately, I don't have a better suggestion other than putting the > word "programmatic" or "structured" in there to help disambiguate the > two uses. However, since this has been beaten to death, and this is > what the majority agrees to, then so be it. I think many object to programmatic on account of we are not building an API, but a protocol. While "interface" now appears multiple times in the paragraphs, each is specifically qualified. > More of a nit, but I think the parenthetical portion should read, "(as > read or by notification) Yes > > Aug 2013 : Request publication of Informational documents describing use > cases > > While it's written correctly here, you have two 'b's in "describing" in > the web charter. Two b's or not two b's? > From the web charter: > > "The I2RS working group works to develop a framework and architecture > that will enable specific use cases, and lead to an understanding of the > informational models and requirements for encodings and protocols. Small > and well-scoped use cases are critical to constrain the scope of the > work and achieve sufficient focus for the working group to deliver > successfully. Initial work within the working group will be limited to > within a single administrative domain." > > Another grammatical nit, but perhaps the last two sentences could read: > > "Small and well-scoped use cases are critical to constrain the scope of > the work an achieve sufficient focus for the working group to deliver > successful outcomes. Initial work within the working group will be > limited to a single administrative domain." I've made these changes. Cheers, Adrian From jclarke@cisco.com Sun Dec 23 09:24:33 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7BF21F8587 for ; Sun, 23 Dec 2012 09:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 oKtr5HtMAfJv for ; Sun, 23 Dec 2012 09:24:33 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DFB2721F8556 for ; Sun, 23 Dec 2012 09:24:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBNHOVPH004173; Sun, 23 Dec 2012 12:24:31 -0500 (EST) Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBNHORUl027932; Sun, 23 Dec 2012 12:24:28 -0500 (EST) Message-ID: <50D73E4B.3010807@cisco.com> Date: Sun, 23 Dec 2012 12:24:27 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <50D7206A.6000109@cisco.com> <000b01cde12f$780af930$6820eb90$@olddog.co.uk> In-Reply-To: <000b01cde12f$780af930$6820eb90$@olddog.co.uk> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 17:24:33 -0000 On 12/23/12 12:03 PM, Adrian Farrel wrote: >> I know this was bikeshedded quite a bit -- > > A bit? ;-) For some value of "a bit." :-) > >> and I have no objection to >> the dual meaning -- but I do think that these two paragraphs mix >> "interface" in a way that might be confusing. A "router" already has a >> management "interface" (either virtual or physical) and that is >> independent of the "interface" mentioned in paragraph two. >> Unfortunately, I don't have a better suggestion other than putting the >> word "programmatic" or "structured" in there to help disambiguate the >> two uses. However, since this has been beaten to death, and this is >> what the majority agrees to, then so be it. > > I think many object to programmatic on account of we are not building an API, > but a protocol. Yeah, that's why I wasn't terribly happy with either word. > > While "interface" now appears multiple times in the paragraphs, each is > specifically qualified. Okay, I guess my reading of the second use of "interface" didn't make it clear that it designates a hook into the routing system as opposed to a physical or logical port on which to pass generic management and control data. > I've made these changes. Thanks! Happy holidays. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From abdussalambaryun@gmail.com Sun Dec 23 09:44:08 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A9E21F878F for ; Sun, 23 Dec 2012 09:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, 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 NQ3+EcK17moZ for ; Sun, 23 Dec 2012 09:44:08 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id EEDEA21F865B for ; Sun, 23 Dec 2012 09:44:07 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so6874760vba.27 for ; Sun, 23 Dec 2012 09:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PTwFt3OgryeLySEgFyDLaQ63OcDj/lFURlXkQT9QrhY=; b=Rk28DbTofhVqdornI50OKQzrA2hz9d+X5n2O7N25Xrjb/y30DsZxNjwqoVmIcgdf7I a7cKMiWazMokUhmw6KParlBS0ECb3XHU+glr64G9AvA/aNbyWfuV9YrFxlnbSDUp0+cr g6/lk3g6BidVqIvti0jp7hFGNXysQMz/6zOjhgvOamdHtcokTOjODCan9UQq+2t3bINl oaxbdbcP086n8uQfltyGRtn9bogbK3AeL52I4+R17BXarkg2xa0Ovk4FyWswzx5ERWIK Z+LXjZu86uf6EiQ5zl0LUvxmgcwanxlW8awHjuuL6ru14+F64UrzIXd/Gsezbl4UVxrF KXgQ== MIME-Version: 1.0 Received: by 10.52.76.73 with SMTP id i9mr25613422vdw.25.1356284646989; Sun, 23 Dec 2012 09:44:06 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 23 Dec 2012 09:44:06 -0800 (PST) In-Reply-To: <007c01cde102$3b4c4210$b1e4c630$@olddog.co.uk> References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <007c01cde102$3b4c4210$b1e4c630$@olddog.co.uk> Date: Sun, 23 Dec 2012 18:44:06 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 17:44:08 -0000 Hi Adrian, I agree that my input/suggestions for the charter are not necessary, my idea was to just separate if possible the definitions of RS and the I2RS to make it flexible until we agree on such architectures. However, some inline; On 12/23/12, Adrian Farrel wrote: > Hi Abdussalam, > > Thanks for contributing. > >> > A routing system is all or part of a routing network. A part of a >> > routing >> > network may be a single router or a collection of routers. The >> > routing >> > system may be further divided to be an interface over which data >>> traffic is forwarded, or a collection of such interfaces. >> >> AB>Suggest Amend> A routing system SHOULD be in all or part of the >> routing network. > > Not sure what you mean. > The use of upper case here would have no meaning. > How is "should be in" more useful that "is"? In the charter of WG it is better we don't define the routing systems. When using "is" we are somehow defining the routing system, but using SHOULD, MUST and MAY, make clear pecifications direction with the interfaces to these systems. The "is" seems like "must", which I don't prefer in this stage. > >> AB> Amend to> The routing system may be further divided by an >> interface over which data traffic can be forwarded, or by a collection >> of such interfaces. > > You have s/to be/by/ > Doesn't "by" imply that it is the interface that does the dividing? > I don't think that language works. > >> > I2RS facilitates real-time or event driven interaction with the routing >> > system through a collection of control or management interfaces. >> > These allow information, policies, and operational parameters to be >> > injected into and retrieved (as read or notification) from the routing >> > system while retaining data consistency and coherency across the >> > routers and routing infrastructure, and between multiple interactions >> > with the routing system. >> >> AB> replace: between with among > > Fine. > >> > 2. Include Control Plane Protocols >> > This got immediate support and leads to: >> >> I think If included we need to define the interface within this plane, >> separating I2RS protocol and the control operation protocol. >> >> > == >> > A routing system is all or part of a routing network. A part of a >> > routing >> > network may be a single router or a collection of routers. The >> > routing >> > system may be further divided to be an interface over which data >> > traffic is forwarded, or a collection of such interfaces. The routing >> > system also includes the control plane protocols that operate the >> > routers. >> >> AB> Amend> The routing system also includes the operational protocols >> that are within control plane that operate the routers. > > I think an "operational protocol that is within the control plane" is a > "control > plane protocol." I agree, but I prefer to avoid the definition of routing system as some prefered to avoid separating data and control interface to RS. Also we still will discuss the I2RS architecture in the WG. I just as not mentioning data interface and control interface to RS as types, as we may not have to define control plane in the routing system. Therefore, my concerns is if we mention the data and control interface then it is ok to mention the control plane as must be included in the routing system. Please note that if you see that the above is not reasonable, the you may ignore, it is just thoughts, Regards AB From adrian@olddog.co.uk Sun Dec 23 10:21:14 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BDE21F8B45 for ; Sun, 23 Dec 2012 10:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_27=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 mi8mK2UfMjod for ; Sun, 23 Dec 2012 10:21:13 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E021F87AE for ; Sun, 23 Dec 2012 10:21:12 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNIL9FH021262; Sun, 23 Dec 2012 18:21:10 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBNIL8wV021250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Dec 2012 18:21:09 GMT From: "Adrian Farrel" To: "'Abdussalam Baryun'" References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <007c01cde102$3b4c4210$b1e4c630$@olddog.co.uk> In-Reply-To: Date: Sun, 23 Dec 2012 18:21:04 -0000 Message-ID: <000e01cde13a$457ff960$d07fec20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEswVCPW8JU8hFpBIVJxKGn6yXYJADv9CA8AeRwyb8BkLmy2plFx3hw Content-Language: en-gb Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 18:21:14 -0000 Hi, > >> > A routing system is all or part of a routing network. A part of a > >> > routing network may be a single router or a collection of > >> > routers. The routing system may be further divided to be > >> > an interface over which data traffic is forwarded, or a > >> > collection of such interfaces. > >> > >> AB>Suggest Amend> A routing system SHOULD be in all or part of the > >> routing network. > > > > Not sure what you mean. > > The use of upper case here would have no meaning. > > How is "should be in" more useful that "is"? > > In the charter of WG it is better we don't define the routing > systems. When using "is" we are somehow defining the routing system, > but using SHOULD, MUST and MAY, make clear pecifications direction > with the interfaces to these systems. The "is" seems like "must", > which I don't prefer in this stage. OK, I understand your point. I think that the text describes the "routing system" which this working group will work on. I'm also pretty sure it describes every routing system that exists. > >> AB> Amend> The routing system also includes the operational protocols > >> that are within control plane that operate the routers. > > > > I think an "operational protocol that is within the control plane" is a > > "control plane protocol." > > I agree, but I prefer to avoid the definition of routing system as > some prefered to avoid separating data and control interface to RS. > Also we still will discuss the I2RS architecture in the WG. I just as > not mentioning data interface and control interface to RS as types, as > we may not have to define control plane in the routing system. > Therefore, my concerns is if we mention the data and control interface > then it is ok to mention the control plane as must be included in the > routing system. I think the conversation I heard on the list was that people strongly wanted to consider the control plane as part of the routing system. I would also add that "data interface and control interface to RS" is subtly wrong. The word "to" is at odds with the intention. The intention is that these interfaces are part of the routing system, not interface to the routing system. > Please note that if you see that the above is not reasonable, the you > may ignore, it is just thoughts, No problem. Through discussion we get solutions. Adrian From abdussalambaryun@gmail.com Sun Dec 23 18:50:37 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457F321F8B94 for ; Sun, 23 Dec 2012 18:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 VqiG8Pxrp7L5 for ; Sun, 23 Dec 2012 18:50:36 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id A301A21F8BBA for ; Sun, 23 Dec 2012 18:50:36 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id p1so7174093vcq.10 for ; Sun, 23 Dec 2012 18:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SXYhpZ5bM2LNrUmoTXOYDgupjHpnwri7RAh2ern1X3E=; b=QNH6E8XJWPtRa4J9IaxWQN665uC6DK79qmWpADmgMVFe2vAZ5eANEN+1OjS9+nse2S JT9I04dzi667wLGTCRnL/lyaIZekr8F8LI1xTa+eZDbHba+9OrCS2yJ5qYAK6vK3PVL5 ziWJbH+BB3U3rl26aTB/r71fDtcBhzKgTsetrrKwae0tFal0Q0v6W9ROjzjb94rjzg5o 9hNNRdZJgkuQygUE+k1soPobzAUpP0IYcg0Vp7GtXGTY0poHj05dqBGwIAnTf46y9v09 88FfoKFGzbAgy6eDZXavBFBUL0iWYv4VPIMRsfnuUbOBWRtjQsvyhNQPWaoCVGFuTc6m ZjhQ== MIME-Version: 1.0 Received: by 10.220.8.195 with SMTP id i3mr30360958vci.44.1356317436004; Sun, 23 Dec 2012 18:50:36 -0800 (PST) Received: by 10.220.145.5 with HTTP; Sun, 23 Dec 2012 18:50:35 -0800 (PST) In-Reply-To: <000e01cde13a$457ff960$d07fec20$@olddog.co.uk> References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <007c01cde102$3b4c4210$b1e4c630$@olddog.co.uk> <000e01cde13a$457ff960$d07fec20$@olddog.co.uk> Date: Mon, 24 Dec 2012 03:50:35 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 02:50:37 -0000 Hi Adrian, > I would also add that "data interface and control interface to RS" is > subtly > wrong. The word "to" is at odds with the intention. The intention is that > these > interfaces are part of the routing system, not interface to the routing > system. > I think that only I2RS servers must be part of the RS and not I2RS clients. However, I think I should read more into the drafts again, thanking you, AB From russw@riw.us Mon Dec 24 05:13:25 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FDB21F888C for ; Mon, 24 Dec 2012 05:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WIjBAc9viZpE for ; Mon, 24 Dec 2012 05:13:24 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9621F8864 for ; Mon, 24 Dec 2012 05:13:24 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tn7qO-00023F-0K for i2rs@ietf.org; Mon, 24 Dec 2012 05:13:24 -0800 Message-ID: <50D854F3.9000008@riw.us> Date: Mon, 24 Dec 2012 08:13:23 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> In-Reply-To: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> 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: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 13:13:25 -0000 > Here is my suggestion based on: > draft-atlas-irs-problem-statement section 3 > draft-keyupate-irs-bgp-usecases > draft-white-irs-use-case-00.txt section 2 > draft-white-irs-use-case-00.txt section 3 > draft-white-irs-use-case-00.txt section 4 > draft-amante-irs-topology-use-cases My sense is we (the authors of each of these documents) should combine the sections indicated into one document --this would expidite the work... We can work together to build a single "leftovers" document, or figure how to structure another set of documents that could be used for future phases of work after this initial batch is considered. > NEW > - Tightly scoped key use cases for operational use of I2RS. These use cases will > include at least: My only objection here is the words "at least..." I think we want to restrict the charter at this point, not set ourselves up to increase scope from the start. I think we're looking for an upper bound, not a baseline. > o Interactions with the RIB. Allowing read and write access to the RIB and to > the policies used to construct the FIB, but no direct access to the FIB. > o Control and analysis of the operation of BGP including the setting and > activation of policies related to the protocol. > o Control, optimization, and choice of traffic exit points from networks > based on more information than provided by the dynamic control plane. > o Distributed reaction to network-based attacks through quickly modification > of the control plane behavior to reroute traffic for one destination while > leaving a standard mechanisms (filters, metrics, and policy) in place for other > routes. > o Service layer routing to improve on existing hub-and-spoke traffic > o The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as an initial work > item. I'm afraid these might be too broad in terms of the solution set. The last 5 should fit within the first one, rather than being expansions on the first one, I think. :-) Russ -- <>< riwhite@verisign.com russw@riw.us From abdussalambaryun@gmail.com Mon Dec 24 06:52:51 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2AF21F88F7 for ; Mon, 24 Dec 2012 06:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 359I6aMxS1vH for ; Mon, 24 Dec 2012 06:52:51 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id C8D2B21F88F3 for ; Mon, 24 Dec 2012 06:52:50 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id x16so7449028vcq.37 for ; Mon, 24 Dec 2012 06:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ko5tvdR7D1Tqt1pvuTpRFlHWQxt4ZPwUP1gwJd2gsc=; b=fRRmf/Gy0CK/zfdZ4ep9EaVl9wkIbepV7fZVN9DGRyagX3FhxNHTHEVrcDo3ahG5eU red4c4J4DYQ3pqhVibh8XFnjJ3rM9BwnoiwW1zuQoB2TKUxF8JSZPREv3jo4s7/IiGoF PNVc3mtdOOjIR1zauFWv58fq6l/970LMJ9priSJqJ9Le1MDQz1FMJjyWiArgclDnjFLD h/Ugtes6brpbfS3ZedpP/Bny9CvOconu7Ul2TkLF7+pBY10e6e/HYc37nB4b5DU5m1/J 046pibkHI/7bq2LLHZNQ4GCtJeDydqxuxTAUUs8YxtMK+ft9lSzKw1d0cmqWjW/zF2EJ B7+w== MIME-Version: 1.0 Received: by 10.58.143.12 with SMTP id sa12mr34311341veb.43.1356360765700; Mon, 24 Dec 2012 06:52:45 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 24 Dec 2012 06:52:45 -0800 (PST) In-Reply-To: <50D854F3.9000008@riw.us> References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <50D854F3.9000008@riw.us> Date: Mon, 24 Dec 2012 15:52:45 +0100 Message-ID: From: Abdussalam Baryun To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 14:52:51 -0000 Hi Russ, My comments/opinion in line; On 12/24/12, Russ White wrote: > > >> Here is my suggestion based on: >> draft-atlas-irs-problem-statement section 3 >> draft-keyupate-irs-bgp-usecases >> draft-white-irs-use-case-00.txt section 2 >> draft-white-irs-use-case-00.txt section 3 >> draft-white-irs-use-case-00.txt section 4 >> draft-amante-irs-topology-use-cases > > My sense is we (the authors of each of these documents) should combine > the sections indicated into one document --this would expidite the > work... We can work together to build a single "leftovers" document, or > figure how to structure another set of documents that could be used for > future phases of work after this initial batch is considered. I agree too, > >> NEW >> - Tightly scoped key use cases for operational use of I2RS. These use >> cases will >> include at least: > > My only objection here is the words "at least..." I think we want to > restrict the charter at this point, not set ourselves up to increase > scope from the start. I think we're looking for an upper bound, not a > baseline. I understand that important reason, but I prefer not and leave it as *baseline*, because we are in the stage to think in and out the box, open ideas and welcome new input not to keep it into some drafts' scope. The proposed charter does form a solid framework direction not structure. If we do restrict work to thoes drafts then the drafts are the source of charter not the participants' ideas joining the WG. I think it is good to encourage new participants to join as well from the charter. As I am not an author of any of thoes drafts (still under my and others review) and thoes drafts still didn't get to alot discussions, that will be my opinion :) > >> o Interactions with the RIB. Allowing read and write access to the RIB >> and to >> the policies used to construct the FIB, but no direct access to the FIB. >> o Control and analysis of the operation of BGP including the setting >> and >> activation of policies related to the protocol. >> o Control, optimization, and choice of traffic exit points from >> networks >> based on more information than provided by the dynamic control plane. >> o Distributed reaction to network-based attacks through quickly >> modification >> of the control plane behavior to reroute traffic for one destination >> while >> leaving a standard mechanisms (filters, metrics, and policy) in place for >> other >> routes. >> o Service layer routing to improve on existing hub-and-spoke traffic >> o The ability to extract information about topology from the network. >>Injection and creation of topology will not be considered as an initial work item. > > I'm afraid these might be too broad in terms of the solution set. The > last 5 should fit within the first one, rather than being expansions on > the first one, I think. I don't think all are expansions of the first one, however, it seems it was a reflection of the drafts on this proposed charter. I agree to remove the last 5 if confusing by rewrite it into two points that may relate to participants concerns (ending with three points) as: AB>Amend to> - The key use cases for operational use of I2RS. These use cases will include at least: o Interactions with the RIB. Allowing read and write access to the RIB (includes to extract information about topology from the network) and to the policies used to construct the FIB, but no direct access to the FIB. o Control and analysis of the operations of Router(s) including the setting and activation; of policies related to the routing protocol, and including the optimizing of traffic exit points. o Service layer routing to improve on existing hub-and-spoke traffic. Important Note: Injection and creation of topology will not be considered as an initial work item. Regards AB From russw@riw.us Mon Dec 24 06:57:18 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BF721F88F3 for ; Mon, 24 Dec 2012 06:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k+R1o8cS-04 for ; Mon, 24 Dec 2012 06:57:17 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id D5F2621F88ED for ; Mon, 24 Dec 2012 06:57:17 -0800 (PST) Received: from cpe-065-190-156-032.nc.res.rr.com ([65.190.156.32] helo=[192.168.100.51]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tn9Sv-00007o-8i for i2rs@ietf.org; Mon, 24 Dec 2012 06:57:17 -0800 Message-ID: <50D86D4C.2050606@riw.us> Date: Mon, 24 Dec 2012 09:57:16 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <50D854F3.9000008@riw.us> 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: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 14:57:18 -0000 >> My only objection here is the words "at least..." I think we want to >> restrict the charter at this point, not set ourselves up to increase >> scope from the start. I think we're looking for an upper bound, not a >> baseline. > > I understand that important reason, but I prefer not and leave it as > *baseline*, because we are in the stage to think in and out the box, > open ideas and welcome new input not to keep it into some drafts' > scope. The proposed charter does form a solid framework direction not > structure. If we do restrict work to thoes drafts then the drafts are > the source of charter not the participants' ideas joining the WG. I > think it is good to encourage new participants to join as well from > the charter. As I am not an author of any of thoes drafts (still under > my and others review) and thoes drafts still didn't get to alot > discussions, that will be my opinion :) The problem we currently have isn't leaving the door open to new ideas, or even generating new ideas --we seem to have tons of ideas about where this work could/would be useful. The problem we currently have is limiting the scope narrowly enough to do effective work --to chunk the work up into small enough pieces to make it tractable. I.e., we are in danger of biting off more than we can chew, so we need to slice into smaller pieces. Not that we don't want to eat the whole thing, but we don't want to eat it right this second, and all in one bite, lest we choke... :-) Russ -- <>< riwhite@verisign.com russw@riw.us From abdussalambaryun@gmail.com Mon Dec 24 07:09:40 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B121F8BE3 for ; Mon, 24 Dec 2012 07:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 5okPyZv+m46C for ; Mon, 24 Dec 2012 07:09:39 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id 65FDB21F88D1 for ; Mon, 24 Dec 2012 07:09:39 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so7422654vbn.14 for ; Mon, 24 Dec 2012 07:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=awtNUWBxs7hzdaojfRQlDG+79dNTw+qE/uadi4cSM20=; b=kewEkcnvQdAirnloL/4BVLSsTpO9YMRCXWCvvJL0+9GmLdp0HP2nCScqbdmzkqkjVq GsXipjc/s+ULTIXDYkohzMtB0sMbwMj2azrio03HNrxP99zU+BIK8QTE/A75yElO7t+U wKta+hZJNulHCDvhCtNK2lZQpq1/bd1V1IerHhi/87tghICiF3JA2iuD98ttP3Uvcsad dXzZAHPWgzfggxiIUq8WwEKWuvJSz1VzU8ntkllMYlo0uXy8cQQZP0R0dhy/C925/l9M bZOw0IYRh5oPJTsZMr0bUOiJD4pzxrhMN2h6CapNQUCGiNDolmQzjvr33H+2hscrjMpq 5w7A== MIME-Version: 1.0 Received: by 10.220.115.20 with SMTP id g20mr33464849vcq.31.1356361778907; Mon, 24 Dec 2012 07:09:38 -0800 (PST) Received: by 10.220.145.5 with HTTP; Mon, 24 Dec 2012 07:09:38 -0800 (PST) In-Reply-To: <50D86D4C.2050606@riw.us> References: <047801cddfb2$59f14810$0dd3d830$@olddog.co.uk> <50D854F3.9000008@riw.us> <50D86D4C.2050606@riw.us> Date: Mon, 24 Dec 2012 16:09:38 +0100 Message-ID: From: Abdussalam Baryun To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS charter X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2012 15:09:40 -0000 On 12/24/12, Russ White wrote: > > The problem we currently have isn't leaving the door open to new ideas, > or even generating new ideas --we seem to have tons of ideas about where > this work could/would be useful. The problem we currently have is > limiting the scope narrowly enough to do effective work --to chunk the > work up into small enough pieces to make it tractable. > > I.e., we are in danger of biting off more than we can chew, so we need > to slice into smaller pieces. Not that we don't want to eat the whole > thing, but we don't want to eat it right this second, and all in one > bite, lest we choke... Thanks, I will never disagree about that, have a happy new year and christmas to you and all, :-) AB From wesley.george@twcable.com Fri Dec 28 11:21:56 2012 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9821F8E0A for ; Fri, 28 Dec 2012 11:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 0JYaWumN-79X for ; Fri, 28 Dec 2012 11:21:55 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFC721F8E08 for ; Fri, 28 Dec 2012 11:21:55 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.84,371,1355115600"; d="scan'208";a="4220490" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Dec 2012 14:21:07 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 28 Dec 2012 14:21:53 -0500 From: "George, Wes" To: "mohamed.boucadair@orange.com" , "i2rs@ietf.org" Date: Fri, 28 Dec 2012 14:22:09 -0500 Thread-Topic: comments on draft-boucadair-network-automation-requirements Thread-Index: Ac3lMJ+ErT9bc1KuSrCkzJPtXqFAvQ== Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033A7B5647@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: JACQUENET Christian OLNC/OLN Subject: [i2rs] comments on draft-boucadair-network-automation-requirements X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 19:21:56 -0000 "This is because existing standards have either failed to (1) be massively adopted so far ... or (2) address service provider and network operator requirements about configuration framework and procedures." [WEG] I think this is incomplete as currently presented. I don't think it's= a failing of the existing standards, and I think the challenge is much lar= ger. First, a quote I've always found appropriate for framing this discussion: "= The first rule of any technology used in a business is that automation appl= ied to an efficient operation will magnify the efficiency. The second is th= at automation applied to an inefficient operation will magnify the ineffici= ency." - Bill Gates There are two different but related issues with automation of network provi= sioning and management: 1) a lack of will to invest in a real, continually improved and updated aut= omation environment - it's sometimes cheaper to "throw headcount at a probl= em" than to make a long-term investment in automation, especially since the= industry is littered with attempts to do automation that have ultimately f= ailed, making the return on the investment somewhat questionable. It also r= equires a permanent staff of people to maintain and improve the system, rat= her than it being a once and done sort of investment. Some companies are go= od about this, because they have management that understands the productivi= ty multiplier that proper automation can provide and are willing to invest = in it, others are not, sometimes because they try to force a tool to automa= te their current process as-is rather than trying to streamline their proce= ss around the capabilities of the tool. 2) healthy mistrust by operators and management of the automation's level o= f intelligence and ability to make the "right" decision given all possible = scenarios it might encounter. This could be restated as an inability to eit= her characterize or pre-build business rules around all possible scenarios.= It's unclear to me whether this is because the tools available are simply = too crude to adequately represent the series of scenarios that your average= human operator is capable of handling, or because the average SP has too m= uch variability in its scenarios such that "if A occurs, do B" isn't realis= tic for all possible values of A. We may need to differentiate between simp= le business logic and complex when it comes to automation requirements, sin= ce it's much harder to solve the latter, but we can maybe make good progres= s on the former. When it comes to network automation, the options today are usually either "= build your own system mostly from scratch" or "buy a COTS package and then = work to adapt it for your needs and integrate it into your internal systems= ". Both of these options can use standards-based protocols, but those could= be thought of as the modular building blocks for a "some assembly required= " implementation that is almost always bespoke. Even if you have good north= /southbound APIs to work with, someone has to work on the glue to hold ever= ything together. A good implementation requires a lot of work to document f= unctional spec and business logic (or adapt existing process to better fit = the limitations and capabilities of the tool), a lot of testing to ensure t= hat things are working properly, and the ability to make changes easy enoug= h that it isn't simpler/cheaper to bypass the automation and have someone d= o it manually when something changes. So in a way, the necessary modularity= for flexibility and adaptability and the necessary predefinition to make i= mplementation easy "out of the box" run counter to one another. The good ne= ws is, it's extensible, so you can adapt it for your needs. The bad news? I= t's extensible, so you likely MUST adapt it for you needs in order for it t= o be useful. 3.4/3.5 - there are more performance and scaling impacts than this - most n= otably, a poorly-implemented discovery mechanism will do things like attemp= t synchronization too frequently, or do it inefficiently by attempting to p= ull down a complete configuration and then do diffs on its stored data, rat= her than requesting diffs directly and storing those updates, or waiting f= or a notification that something it cares about has been changed before goi= ng out to synchronize with that particular network element ONLY. It may als= o try to discover network elements by walking through IP ranges, which does= n't really work for IPv6. It's also pretty common for there to be a lack of= coordination between different tools that need access to the same data, an= d rather than pulling the data once and then replicating it to all of the d= ifferent tools that need it, each tool polls separately, leading to situati= ons where a box collapses under the load of too-frequent and overly-aggress= ive SNMP polling, etc. I remember problems in production with a certain VPN provisioning software = where its timeout for pulling the complete configuration was too short, and= on routers with large and complex VPN configurations the config sync step = would fail because it took the router too long to uncompress and "display" = the config to the TTY, especially if the base CPU load was too high. There are a good number of scaling/performance considerations for VPNs spec= ifically discussed in draft-gs-vpn-scaling that may help with this discussi= on. I generally agree with the requirements, but it's possible that the above d= iscussion will generate additional requirements, so I didn't spend a lot of= time pondering them yet. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.