From nobody Tue Jun 3 01:51:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712F51A017E for ; Tue, 3 Jun 2014 01:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RUBLx-QQvUY for ; Tue, 3 Jun 2014 01:51:41 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99B01A0181 for ; Tue, 3 Jun 2014 01:51:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79746d000006fe2-f7-538d8c93b967 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E3.BD.28642.39C8D835; Tue, 3 Jun 2014 10:51:31 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.52]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Tue, 3 Jun 2014 10:51:31 +0200 From: Anton Smith To: "i2rs@ietf.org" Thread-Topic: Question and new usecase Thread-Index: Ac9/CQL1puhesClNS7CC5yGLqDNVvQ== Date: Tue, 3 Jun 2014 08:51:30 +0000 Message-ID: <8CCC03580905AE4F98B89B784F5AE85A1A2A19A2@ESESSMB305.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje7knt5gg+dztSzWzfjA4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMO3WhkLznNVfLi8hqWB8QxHFyMnh4SAicSa/wtYIGwxiQv3 1rN1MXJxCAkcZZTYc7SVCcJZxChx5MkHIIeDg01AR+JJXwFIg4iAssTBn72sILawgKLEz6sT WSDiahLLjm6HsvUkbq1tYwexWQRUJE4snsQEYvMK+EpcWvcJrJcRaPH3U2vA4swC4hK3nsxn gjhIQGLJnvPMELaoxMvH/1ghbEWJj6/2MULU60gs2P2JDcLWlli28DUzxHxBiZMzn7BMYBSe hWTsLCQts5C0zELSsoCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYIgf3PLbagfjweeO hxgFOBiVeHgffO4JFmJNLCuuzD3EKM3BoiTOe1GjOlhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY19TpWzU/+7fPk/VJc/WfuC1092d6vfn9vGXudcl3UqL85e/W3EnbDLTqc1b+VsP7nZK MTv5oj124evrVwuE513sn1Hil8bLIbU4nCHb5alQtW6b35KXE69P9Pn13bTv54fZ8/sFYh8e Nz5lxNErPzWh3La0s87gWKs2n5BU0oo1Z8ysk7LclViKMxINtZiLihMBtJ2El1ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ZJ3SbxefqW4vh8EyFk9EHUYmjbk Subject: [i2rs] Question and new usecase X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:51:42 -0000 Hi all, I have a question and a potential usecase. I was reading the charter today = and it mentioned some fairly specific usecases. I've been thinking of anoth= er fairly specific class of usecase that I had hoped I2RS would deliver. The question is, where do you raise discussion on a new usecase, is it here= on the list? The usecase itself is about flow installation or basically non-destination = based routing and forwarding. Imagine a router participating in an IP/MPLS = domain, which is running for example multiple L3VPNs, L2VPNs, or even just = plain L3 routing. It would be desirable to be able to dynamically push down new policy based = rules to an access interface such that as traffic ingresses the node it can= be redirected to either services (like an L3VPN context) or forwarded, bas= ed on whatever can be filtered/matched in the incoming packet. In essence policy based forwarding (aka PBR), but allowing I2RS to push dow= n the policies (match criteria, action, etc.), edit them, remove them, and = so forth. This could allow for instance, based off orchestration layer deci= sions, the dynamic redirection or separation of traffic that would have bee= n previously grouped together, and not restricted to just QoS separation bu= t allowing path separation or service redirection.=20 Regards, Anton From nobody Tue Jun 3 22:42:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BC1A008A for ; Tue, 3 Jun 2014 22:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg4U8TVd6v-H for ; Tue, 3 Jun 2014 22:42:38 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1A31A0087 for ; Tue, 3 Jun 2014 22:42:38 -0700 (PDT) Received: from pps.filterd (m0048193 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s545PqBl011028; Tue, 3 Jun 2014 22:42:29 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1m9hhbg6nu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 03 Jun 2014 22:42:29 -0700 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.3.123.3; Tue, 3 Jun 2014 22:42:28 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::f5db:81ae:2a14:f915%12]) with mapi; Tue, 3 Jun 2014 22:42:26 -0700 From: ramki Krishnan To: Anton Smith , "i2rs@ietf.org" Date: Tue, 3 Jun 2014 22:42:25 -0700 Thread-Topic: Question and new use case Thread-Index: Ac9/t7NQWlRd+9iuQrqINSd9SAUbMw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-04_01:2014-06-02,2014-06-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406040069 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uk-ltNk0PFzw8g-bvvHt44SlViE Subject: Re: [i2rs] Question and new use case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 05:42:39 -0000 Hi Anton, The draft below addresses the use case you are mentioning. Would love to ha= ve your comments. http://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/?in= clude_text=3D1 Thanks, Ramki -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Smith Sent: Tuesday, June 03, 2014 1:51 AM To: i2rs@ietf.org Subject: [i2rs] Question and new usecase Hi all, I have a question and a potential usecase. I was reading the charter today = and it mentioned some fairly specific usecases. I've been thinking of anoth= er fairly specific class of usecase that I had hoped I2RS would deliver. The question is, where do you raise discussion on a new usecase, is it here= on the list? The usecase itself is about flow installation or basically non-destination = based routing and forwarding. Imagine a router participating in an IP/MPLS = domain, which is running for example multiple L3VPNs, L2VPNs, or even just = plain L3 routing. It would be desirable to be able to dynamically push down new policy based = rules to an access interface such that as traffic ingresses the node it can= be redirected to either services (like an L3VPN context) or forwarded, bas= ed on whatever can be filtered/matched in the incoming packet. In essence policy based forwarding (aka PBR), but allowing I2RS to push dow= n the policies (match criteria, action, etc.), edit them, remove them, and = so forth. This could allow for instance, based off orchestration layer deci= sions, the dynamic redirection or separation of traffic that would have bee= n previously grouped together, and not restricted to just QoS separation bu= t allowing path separation or service redirection.=20 Regards, Anton _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 3 23:16:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD381A009C for ; Tue, 3 Jun 2014 23:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNRrBoe8xRv8 for ; Tue, 3 Jun 2014 23:16:24 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0F91A0099 for ; Tue, 3 Jun 2014 23:16:23 -0700 (PDT) X-AuditID: c1b4fb2d-f79776d000001085-e4-538eb9b0eb29 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.0D.04229.0B9BE835; Wed, 4 Jun 2014 08:16:16 +0200 (CEST) Received: from ESESSMB305.ericsson.se ([169.254.5.52]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0174.001; Wed, 4 Jun 2014 08:16:15 +0200 From: Anton Smith To: ramki Krishnan Thread-Topic: Question and new use case Thread-Index: Ac9/t7NQWlRd+9iuQrqINSd9SAUbMwABMpGz Date: Wed, 4 Jun 2014 06:16:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje6GnX3BBqvmiVqsm/GBxWLbzJ/M DkwePccus3ksWfKTKYApissmJTUnsyy1SN8ugSvj5pp9rAWfBCqevH7H0sD4kLeLkYNDQsBE YusD8S5GTiBTTOLCvfVsILaQwFFGiX3L47sYuYDsRYwSHw73sIPUswnoSDzpKwCpERFQlXi0 7yJYPbOAssTEl/vBbGEBNYn3lyawQtSoS9y9c4EdwjaS6Ph6igXEZhFQkfh87glYDa+AvcTf zn5miL0hEh1XFoDN4RQIlThw6CITiM0IdNv3U2uYIHaJS9x6Mp8J4mYBiSV7zjND2KISLx// Y4Wo0ZFYsPsT1G3aEssWvmaG2CUocXLmE5YJjKKzkIyahaRlFpKWWUhaFjCyrGIULU4tLs5N NzLWSy3KTC4uzs/Ty0st2cQIjJGDW37r7mBc/drxEKMAB6MSD68Cb1+wEGtiWXFl7iFGaQ4W JXHeSxrVwUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY3Y4InQtQjzHMbTnwutGDW0ma68kb VhnpkK3qRxZ3Zj9rNK9YIG9gfmSPUKDd9Ve2rx6qXVtsv+DS9ykq5ys/yBYvuT/75TXOr2tk dkldv+WZ/vRLqZ6RRM73K++6RE4LKqddePzK6hR/ysYpZqYPX0YvzpilkDNtqbjmpuwTnbev RN64KfjhuBJLcUaioRZzUXEiADECNAlyAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/il94qgmcdzU_9DF0-2ayJb9bx6g Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Question and new use case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 06:16:26 -0000 Thanks Ramki, Will take a look. Rest regards Anton Sent from my iPhone > On 4 jun 2014, at 07:42, "ramki Krishnan" wrote: >=20 > Hi Anton, >=20 > The draft below addresses the use case you are mentioning. Would love to = have your comments. >=20 > http://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/?= include_text=3D1 >=20 > Thanks, > Ramki >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Smith > Sent: Tuesday, June 03, 2014 1:51 AM > To: i2rs@ietf.org > Subject: [i2rs] Question and new usecase >=20 > Hi all, >=20 > I have a question and a potential usecase. I was reading the charter toda= y and it mentioned some fairly specific usecases. I've been thinking of ano= ther fairly specific class of usecase that I had hoped I2RS would deliver. >=20 > The question is, where do you raise discussion on a new usecase, is it he= re on the list? >=20 > The usecase itself is about flow installation or basically non-destinatio= n based routing and forwarding. Imagine a router participating in an IP/MPL= S domain, which is running for example multiple L3VPNs, L2VPNs, or even jus= t plain L3 routing. >=20 > It would be desirable to be able to dynamically push down new policy base= d rules to an access interface such that as traffic ingresses the node it c= an be redirected to either services (like an L3VPN context) or forwarded, b= ased on whatever can be filtered/matched in the incoming packet. >=20 > In essence policy based forwarding (aka PBR), but allowing I2RS to push d= own the policies (match criteria, action, etc.), edit them, remove them, an= d so forth. This could allow for instance, based off orchestration layer de= cisions, the dynamic redirection or separation of traffic that would have b= een previously grouped together, and not restricted to just QoS separation = but allowing path separation or service redirection.=20 >=20 > Regards, > Anton >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jun 4 08:06:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA11A0361 for ; Wed, 4 Jun 2014 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3KF3mIZmWlA for ; Wed, 4 Jun 2014 08:06:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 183C41A0277 for ; Wed, 4 Jun 2014 08:06:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3F4C5C2A4; Wed, 4 Jun 2014 11:06:44 -0400 (EDT) Date: Wed, 4 Jun 2014 11:06:44 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140604150644.GC7069@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ujQk4k_YqjiIIgmruOPqIMd8gRg Subject: [i2rs] [mcr+ietf@sandelman.ca: second call: NomCom 2014-2015 Call for Volunteers] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 15:06:52 -0000 ----- Forwarded message from Michael Richardson ----- Date: Tue, 03 Jun 2014 15:17:47 -0400 From: Michael Richardson To: ietf@ietf.org, WG Chairs Subject: second call: NomCom 2014-2015 Call for Volunteers The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). This is the second call for volunteers. (and you may have seen it more than once) If your name is on the below, then you have volunteered and are qualified. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 54 volunteers so far. The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: Your Full Name: __________-- Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ [] Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel DHRUV DHODY Dacheng Zhang Dapeng Liu Donald Eastlake Eric VYNCKE Fernando Gont Fred Baker Gonzalo Salgueiro Hongyu Li Hosnieh Rafiee Hugo Salgado John E Drake John Levine John Scudder Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Yong Mach Chen Mark Townsley Matt Lepinski Mehmet Ersue Melinda Shore Min Ye Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Yee Ralph Droms Ron Bonica Ross Callon Ross Finlayson Sam K. Aldrin Sanjay Mishra Sheng JIANG Shucheng Liu Stephan Friedl Stephan Wenger Stephen Kent Suhas Nandakumar Tim Wicinski Tissa Senevirathne Toerless Eckert Wassim Haddad Xiaohu XU Yuanlong Jiang -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ----- End forwarded message ----- From nobody Wed Jun 4 10:44:30 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3021A0254; Wed, 4 Jun 2014 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id marjetv_XMhN; Wed, 4 Jun 2014 10:44:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 502501A0306; Wed, 4 Jun 2014 10:44:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 10:44:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7jlgq5UtFBtE1gR6aPOlXPMhgwc Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:44:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Use Cases for an Interface to BGP Protocol Authors : Keyur Patel Rex Fernando Hannes Gredler Shane Amante Russ White Susan Hares Filename : draft-keyupate-i2rs-bgp-usecases-02.txt Pages : 17 Date : 2014-06-04 Abstract: A network routing protocol like BGP is typically configured and analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. Interface to the Routing System's (I2RS) Programmatic interfaces, as defined in draft-ietf-i2rs-architecture, provides an alternate way to control and diagnose the operation of the BGP protocol. I2RS may be used for the configuration, manipulation, analyzing or collecting the protocol data. This document describes set of use cases for which I2RS can be used for BGP protocol. It is intended to provide a base for the solution draft describing a set of interfaces to the BGP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 4 11:49:49 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B673F1A03A1 for ; Wed, 4 Jun 2014 11:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsgsRJKhu55R for ; Wed, 4 Jun 2014 11:49:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 64E831A0390 for ; Wed, 4 Jun 2014 11:49:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> In-Reply-To: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> Date: Wed, 4 Jun 2014 14:49:29 -0400 Message-ID: <005101cf8025$b7cc2b70$27648250$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qJsoHcbA Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ImNlK5lj7f2_qvxS50IkY_jyea8 Cc: "'Keyur Patel \(keyupate\)'" , Hannes Gredler , Russ White , 'Susan Hares' , rex@cisco.com Subject: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 18:49:48 -0000 Jeff and Ed: This updated draft has all the changes that Keyur Patel promised and updates to the reference the current i2rs internet drafts. Would you please do a Working Group adoption call? Thank you, Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, June 04, 2014 1:44 PM To: i-d-announce@ietf.org Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Use Cases for an Interface to BGP Protocol Authors : Keyur Patel Rex Fernando Hannes Gredler Shane Amante Russ White Susan Hares Filename : draft-keyupate-i2rs-bgp-usecases-02.txt Pages : 17 Date : 2014-06-04 Abstract: A network routing protocol like BGP is typically configured and analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. Interface to the Routing System's (I2RS) Programmatic interfaces, as defined in draft-ietf-i2rs-architecture, provides an alternate way to control and diagnose the operation of the BGP protocol. I2RS may be used for the configuration, manipulation, analyzing or collecting the protocol data. This document describes set of use cases for which I2RS can be used for BGP protocol. It is intended to provide a base for the solution draft describing a set of interfaces to the BGP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jun 4 12:24:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011AA1A03CA for ; Wed, 4 Jun 2014 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiqByD7LGsij for ; Wed, 4 Jun 2014 12:23:58 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 60CEC1A033A for ; Wed, 4 Jun 2014 12:23:58 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: Date: Wed, 4 Jun 2014 15:23:47 -0400 Message-ID: <005c01cf802a$82407d80$86c17880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CF8008.FB325FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+AKnt5S1k3RcsFSj6HkUsXnT9fsg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kxNxQAAkvhqoo6NuBGjzUlOtlPI Cc: 'Jeffrey Haas' , Edward Crabbe Subject: [i2rs] draft-white-i2rs-use-case-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:24:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005D_01CF8008.FB325FF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS WG: This use case draft has been changed to provide a numbered list of requirements (per Jeff's request). The authors welcome feedback on these changes. Sue -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, June 04, 2014 3:21 PM To: Alvaro Retana; Susan Hares; Susan Hares; Russ White; Russ White; Alvaro Retana Subject: New Version Notification for draft-white-i2rs-use-case-03.txt A new version of I-D, draft-white-i2rs-use-case-03.txt has been successfully submitted by Susan Hares and posted to the IETF repository. Name: draft-white-i2rs-use-case Revision: 03 Title: Protocol Independent Use Cases for an Interface to the Routing System Document date: 2014-06-04 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-03.txt Status: https://datatracker.ietf.org/doc/draft-white-i2rs-use-case/ Htmlized: http://tools.ietf.org/html/draft-white-i2rs-use-case-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-white-i2rs-use-case-03 Abstract: Programmatic interfaces to provide control over individual forwarding devices in a network promise to reduce operational costs while improving scaling, control, and visibility into the operation of large scale networks. To this end, several programmatic interfaces have been proposed. OpenFlow, for instance, provides a mechanism to replace the dynamic control plane processes on individual forwarding devices throughout a network with off box processes that interact with the forwarding tables on each device. Another example is NETCONF, which provides a fast and flexible mechanism to interact with device configuration and policy. There is, however, no proposal which provides an interface to all aspects of the routing system as a system. Such a system would not interact with the forwarding system on individual devices, but rather with the control plane processes already used to discover the best path to any given destination through the network, as well as interact with the routing information base (RIB), which feeds the forwarding table the information needed to actually switch traffic at a local level. This document describes a set of use cases such a system could fulfill. It is designed to provide underlying support for the framework, policy, and other drafts describing the Interface to the Routing System (I2RS). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------=_NextPart_000_005D_01CF8008.FB325FF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS WG: =

This use case draft = has been changed to provide a numbered list of requirements (per Jeff's = request).  The authors welcome feedback on these changes. =  

 

Sue =

 

 

-----Original = Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]
Sent: Wednesday, June 04, 2014 = 3:21 PM
To: Alvaro Retana; Susan Hares; Susan Hares; Russ White; Russ = White; Alvaro Retana
Subject: New Version Notification for = draft-white-i2rs-use-case-03.txt

 

 

A new version of = I-D, draft-white-i2rs-use-case-03.txt has been successfully submitted by = Susan Hares and posted to the IETF repository.

 

Name:       = draft-white-i2rs-use-case

Revision:   03

Title:          &= nbsp; Protocol Independent Use Cases for an Interface to the Routing = System

Document = date:    2014-06-04

Group:          &= nbsp; Individual Submission

Pages:          &= nbsp; 15

URL:          &nb= sp; http://www.ietf.org/inter= net-drafts/draft-white-i2rs-use-case-03.txt<= /p>

Status:         https://datatracker.ietf.= org/doc/draft-white-i2rs-use-case/

Htmlized:       http://tools.ietf.org/htm= l/draft-white-i2rs-use-case-03

Diff:           = = http://www.ietf.org/rfcdi= ff?url2=3Ddraft-white-i2rs-use-case-03

 

Abstract:

   = Programmatic interfaces to provide control over individual = forwarding

   = devices in a network promise to reduce operational costs = while

   = improving scaling, control, and visibility into the operation = of

   large = scale networks.  To this end, several programmatic = interfaces

   have = been proposed.  OpenFlow, for instance, provides a mechanism = to

   = replace the dynamic control plane processes on individual = forwarding

   = devices throughout a network with off box processes that = interact

   with = the forwarding tables on each device.  Another example = is

   = NETCONF, which provides a fast and flexible mechanism to = interact

   with = device configuration and policy.

 

   There = is, however, no proposal which provides an interface to = all

   = aspects of the routing system as a system.  Such a system would = not

   = interact with the forwarding system on individual devices, but = rather

   with = the control plane processes already used to discover the = best

   path = to any given destination through the network, as well = as

   = interact with the routing information base (RIB), which feeds = the

   = forwarding table the information needed to actually switch traffic = at

   a = local level.

 

   This = document describes a set of use cases such a system = could

   = fulfill.  It is designed to provide underlying support for = the

   = framework, policy, and other drafts describing the Interface to = the

   = Routing System (I2RS).

 

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

Please note that it = may take a couple of minutes from the time of submission until the = htmlized version and diff are available at = tools.ietf.org.

 

The IETF = Secretariat

 

------=_NextPart_000_005D_01CF8008.FB325FF0-- From nobody Thu Jun 5 01:38:40 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEAA1A02C1 for ; Thu, 5 Jun 2014 01:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mT_Lc5Ev5s0 for ; Thu, 5 Jun 2014 01:38:36 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B231A0109 for ; Thu, 5 Jun 2014 01:38:35 -0700 (PDT) Received: from DB3PRD0210HT003.eurprd02.prod.outlook.com (157.56.253.69) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 5 Jun 2014 08:38:27 +0000 Message-ID: <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> Date: Thu, 5 Jun 2014 09:35:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: AMSPR07CA008.eurprd07.prod.outlook.com (10.242.77.176) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(428001)(199002)(377424004)(51704005)(13464003)(189002)(377454003)(61296002)(81342001)(62966002)(92726001)(74662001)(62236002)(23756003)(64706001)(47776003)(66066001)(20776003)(44716002)(92566001)(81542001)(81816999)(93916002)(88136002)(87976001)(31966008)(87286001)(19580405001)(19580395003)(89996001)(83322001)(104166001)(4396001)(33646001)(50466002)(50226001)(42186004)(85852003)(83072002)(50986999)(86362001)(76176999)(80022001)(79102001)(46102001)(21056001)(15202345003)(15975445006)(44736004)(74502001)(14496001)(76482001)(81686999)(77156001)(101416001)(77982001)(102836001)(99396002)(84392001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DB3PRD0210HT003.eurprd02.prod.outlook.com; FPR:; MLV:ovr; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Dvpo85VzBTPEP4PJlJuv_8JWMMQ Cc: "'Keyur Patel \(keyupate\)'" , Hannes Gredler , Russ White , 'Susan Hares' , rex@cisco.com Subject: Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:38:39 -0000 Sue Currently you have six authors which is too many for an RFC - someone's got to go! For me, this is not just an admin point - when commenting, I like to have one or two names, no more, as the clear pen holders whom I can expect to act. Too often, with so many names, everyone thinks that someone else will do something and nothing happens, so, in all seriousness, I oppose adoption until you sort this out amongst yourselves. Note too that you have a citation in the Abstract, again not allowed - this can be surprising difficult to get round but get round it you, one or more thereof, must. Tom Petch ----- Original Message ----- From: "Susan Hares" To: Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" ; "Russ White" ; "'Susan Hares'" ; Sent: Wednesday, June 04, 2014 7:49 PM Subject: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > Jeff and Ed: > > This updated draft has all the changes that Keyur Patel promised and updates > to the reference the current i2rs internet drafts. > > Would you please do a Working Group adoption call? > > Thank you, > Sue Hares > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, June 04, 2014 1:44 PM > To: i-d-announce@ietf.org > Cc: i2rs@ietf.org > Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Interface to the Routing System Working > Group of the IETF. > > Title : Use Cases for an Interface to BGP Protocol > Authors : Keyur Patel > Rex Fernando > Hannes Gredler > Shane Amante > Russ White > Susan Hares > Filename : draft-keyupate-i2rs-bgp-usecases-02.txt > Pages : 17 > Date : 2014-06-04 > > Abstract: > A network routing protocol like BGP is typically configured and > analyzed through some form of Command Line Interface (CLI) or > NETCONF. These interactions to control BGP and diagnose its > operation encompass: configuration of protocol parameters, display of > protocol data, setting of certain protocol state and debugging of the > protocol. > > Interface to the Routing System's (I2RS) Programmatic interfaces, as > defined in draft-ietf-i2rs-architecture, provides an alternate way to > control and diagnose the operation of the BGP protocol. I2RS may be > used for the configuration, manipulation, analyzing or collecting the > protocol data. This document describes set of use cases for which > I2RS can be used for BGP protocol. It is intended to provide a base > for the solution draft describing a set of interfaces to the BGP > protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 nobody Thu Jun 5 01:48:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8A71A0102 for ; Thu, 5 Jun 2014 01:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4nHjkVkgnRp for ; Thu, 5 Jun 2014 01:48:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0781A0365 for ; Thu, 5 Jun 2014 01:48:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'t.petch'" , References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> In-Reply-To: <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> Date: Thu, 5 Jun 2014 04:47:23 -0400 Message-ID: <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qAGayTg4AbY3QWSbDoAbEA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/_3OiT4KhrS7fP0yn1uJPFK9kL00 Cc: "'Keyur Patel \(keyupate\)'" , 'Hannes Gredler' , 'Russ White' , 'Susan Hares' , rex@cisco.com Subject: Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:48:08 -0000 Tom: I'm glad to change the citation in the abstract. On the authors, this was merge of two drafts. Sue -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Thursday, June 05, 2014 4:35 AM To: Susan Hares; i2rs@ietf.org Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan Hares'; rex@cisco.com Subject: Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Sue Currently you have six authors which is too many for an RFC - someone's got to go! For me, this is not just an admin point - when commenting, I like to have one or two names, no more, as the clear pen holders whom I can expect to act. Too often, with so many names, everyone thinks that someone else will do something and nothing happens, so, in all seriousness, I oppose adoption until you sort this out amongst yourselves. Note too that you have a citation in the Abstract, again not allowed - this can be surprising difficult to get round but get round it you, one or more thereof, must. Tom Petch ----- Original Message ----- From: "Susan Hares" To: Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" ; "Russ White" ; "'Susan Hares'" ; Sent: Wednesday, June 04, 2014 7:49 PM Subject: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > Jeff and Ed: > > This updated draft has all the changes that Keyur Patel promised and updates > to the reference the current i2rs internet drafts. > > Would you please do a Working Group adoption call? > > Thank you, > Sue Hares > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, June 04, 2014 1:44 PM > To: i-d-announce@ietf.org > Cc: i2rs@ietf.org > Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Interface to the Routing System Working > Group of the IETF. > > Title : Use Cases for an Interface to BGP Protocol > Authors : Keyur Patel > Rex Fernando > Hannes Gredler > Shane Amante > Russ White > Susan Hares > Filename : draft-keyupate-i2rs-bgp-usecases-02.txt > Pages : 17 > Date : 2014-06-04 > > Abstract: > A network routing protocol like BGP is typically configured and > analyzed through some form of Command Line Interface (CLI) or > NETCONF. These interactions to control BGP and diagnose its > operation encompass: configuration of protocol parameters, display of > protocol data, setting of certain protocol state and debugging of the > protocol. > > Interface to the Routing System's (I2RS) Programmatic interfaces, as > defined in draft-ietf-i2rs-architecture, provides an alternate way to > control and diagnose the operation of the BGP protocol. I2RS may be > used for the configuration, manipulation, analyzing or collecting the > protocol data. This document describes set of use cases for which > I2RS can be used for BGP protocol. It is intended to provide a base > for the solution draft describing a set of interfaces to the BGP > protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 nobody Thu Jun 5 13:31:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBB91A0369 for ; Thu, 5 Jun 2014 13:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQDdFGRXIbbc for ; Thu, 5 Jun 2014 13:31:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 849601A0359 for ; Thu, 5 Jun 2014 13:29:45 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F1AC6C138; Thu, 5 Jun 2014 16:29:38 -0400 (EDT) Date: Thu, 5 Jun 2014 16:29:38 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140605202938.GP13606@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YZp8lYKgAxBoAnIeGBGb5PQ0qkI Subject: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:31:41 -0000 Working Group, The original deadline for comments on WGLC for the problem statement and architecture drafts of May 30 has passed with no comment whatsoever. While we all realize that there's a bit of exhaustion going on with regard to these drafts, they are a bit of process we simply must get done in order to fully move forward with our agenda of putting together data models. We are *NOT* going to hold that work up further - it is clear that there is consenus to start making that progress. To assist us with putting this work behind us, please respond to the following questions: http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ Have you read the problem statement draft? Do you think it is ready to be published as a RFC? (If no, please respond to the list with issues.) http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Have you read the architecture draft? Do you think it is ready to be published as a RFC? (Ditto.) -- Jeff From nobody Thu Jun 5 13:33:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94B01A02B5 for ; Thu, 5 Jun 2014 13:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-wsh50xESEJ for ; Thu, 5 Jun 2014 13:33:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3621A0325 for ; Thu, 5 Jun 2014 13:32:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2820DC138; Thu, 5 Jun 2014 16:32:22 -0400 (EDT) Date: Thu, 5 Jun 2014 16:32:22 -0400 From: Jeffrey Haas To: ramki Krishnan Message-ID: <20140605203222.GQ13606@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/KdeRIjcPNFUCA0NuZTAUYKPMAQs Cc: Anton Smith , "i2rs@ietf.org" Subject: Re: [i2rs] Question and new use case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:33:07 -0000 Anton, On Tue, Jun 03, 2014 at 10:42:25PM -0700, ramki Krishnan wrote: > Hi Anton, > > The draft below addresses the use case you are mentioning. Would love to have your comments. > > http://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case/?include_text=1 Additionally, some of this is covered in the service chaining draft as well as the PBR info model. A review of existing drafts might prove informative: http://datatracker.ietf.org/wg/i2rs/ > > Thanks, > Ramki > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Anton Smith > Sent: Tuesday, June 03, 2014 1:51 AM > To: i2rs@ietf.org > Subject: [i2rs] Question and new usecase > > Hi all, > > I have a question and a potential usecase. I was reading the charter today and it mentioned some fairly specific usecases. I've been thinking of another fairly specific class of usecase that I had hoped I2RS would deliver. > > The question is, where do you raise discussion on a new usecase, is it here on the list? > > The usecase itself is about flow installation or basically non-destination based routing and forwarding. Imagine a router participating in an IP/MPLS domain, which is running for example multiple L3VPNs, L2VPNs, or even just plain L3 routing. > > It would be desirable to be able to dynamically push down new policy based rules to an access interface such that as traffic ingresses the node it can be redirected to either services (like an L3VPN context) or forwarded, based on whatever can be filtered/matched in the incoming packet. > > In essence policy based forwarding (aka PBR), but allowing I2RS to push down the policies (match criteria, action, etc.), edit them, remove them, and so forth. This could allow for instance, based off orchestration layer decisions, the dynamic redirection or separation of traffic that would have been previously grouped together, and not restricted to just QoS separation but allowing path separation or service redirection. > > Regards, > Anton > > _______________________________________________ > 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 nobody Thu Jun 5 13:46:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D931A0319 for ; Thu, 5 Jun 2014 13:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8azQhSJGPgt for ; Thu, 5 Jun 2014 13:46:22 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEC31A030E for ; Thu, 5 Jun 2014 13:46:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 57B64240787; Thu, 5 Jun 2014 13:46:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 979E9240440; Thu, 5 Jun 2014 13:46:15 -0700 (PDT) Message-ID: <5390D718.1040809@joelhalpern.com> Date: Thu, 05 Jun 2014 16:46:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: i2rs@ietf.org References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/SYIOHWKuk27SS8Pqx7lJ0H8pZYg Cc: Jeffrey Haas , Edward Crabbe Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:46:24 -0000 Comments in line with questions: On 6/5/14, 4:29 PM, Jeffrey Haas wrote: > Working Group, > > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. > > While we all realize that there's a bit of exhaustion going on with regard > to these drafts, they are a bit of process we simply must get done in order > to fully move forward with our agenda of putting together data models. > > We are *NOT* going to hold that work up further - it is clear that there is > consenus to start making that progress. > > To assist us with putting this work behind us, please respond to the > following questions: > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? Yes > Do you think it is ready to be published as a RFC? Yes > (If no, please respond to the list with issues.) > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? Yes > Do you think it is ready to be published as a RFC? Yes. While I would prefer to see the template material removed, I accept that the working group wants the material. > (Ditto.) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Jun 5 16:56:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A4D1A0307 for ; Thu, 5 Jun 2014 16:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHfs5EHerfHv for ; Thu, 5 Jun 2014 16:56:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C58221A027B for ; Thu, 5 Jun 2014 16:56:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'Jeffrey Haas'" , References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Date: Thu, 5 Jun 2014 19:56:31 -0400 Message-ID: <01af01cf8119$c67dea60$5379bf20$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw2WzTgNBoR3VxxqV/A44onIvVAJwgf/VA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JcpUiIpY_GP9GXRpco-1G7hbgBE Cc: 'Alia Atlas' Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 23:56:44 -0000 Jeff: Problem statement: read, suggested changes (repeated 4X), Ok for WG LC, and RFC. Architecture document: wrote, edited other people changes (repeated 10X), Ok for WG LC, RFC. Documents ready to ship to IESG for blessed RFCdom. Thanks Jeff for the reminder to comment! Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, June 05, 2014 4:30 PM To: i2rs@ietf.org Subject: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Working Group, The original deadline for comments on WGLC for the problem statement and architecture drafts of May 30 has passed with no comment whatsoever. While we all realize that there's a bit of exhaustion going on with regard to these drafts, they are a bit of process we simply must get done in order to fully move forward with our agenda of putting together data models. We are *NOT* going to hold that work up further - it is clear that there is consenus to start making that progress. To assist us with putting this work behind us, please respond to the following questions: http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ Have you read the problem statement draft? Do you think it is ready to be published as a RFC? (If no, please respond to the list with issues.) http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Have you read the architecture draft? Do you think it is ready to be published as a RFC? (Ditto.) -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 6 06:57:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241F1A009A for ; Fri, 6 Jun 2014 06:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uPxWQPseLRG for ; Fri, 6 Jun 2014 06:57:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCAF1A0092 for ; Fri, 6 Jun 2014 06:57:38 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 6 Jun 2014 13:57:29 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Fri, 6 Jun 2014 13:57:29 +0000 From: Dean Bogdanovic To: Jeffrey Haas Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: AQHPgP0tb0YxraJvlEmJQS1sKbk3SptkHIWA Date: Fri, 6 Jun 2014 13:57:29 +0000 Message-ID: <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(24454002)(51704005)(377454003)(4396001)(99286001)(101416001)(104166001)(99396002)(2656002)(88136002)(89996001)(87936001)(87286001)(83322001)(19580405001)(19580395003)(33656002)(15202345003)(66066001)(80022001)(57306001)(36756003)(92726001)(76482001)(92566001)(86362001)(93916002)(50226001)(79102001)(83716003)(64706001)(20776003)(85852003)(74662001)(76176999)(81542001)(50986999)(62966002)(81342001)(15975445006)(31966008)(46102001)(77156001)(74502001)(82746002)(83072002)(77982001)(21056001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <4CC2095C438669479CF8881CF91AC906@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ydenlznScmVBSFwDeViebI12qpY Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 13:57:44 -0000 Jeff,=20 Problem statement: suggested changes, several times, still waiting for tho= se to be addressed in the draft. As my comments are not addressed, I don't = think draft is ready for WGLC or RFC.=20 Architecture document: ready for WGLC, ready for RFC Dean On Jun 5, 2014, at 4:29 PM, Jeffrey Haas wrote: > Working Group, >=20 > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. >=20 > While we all realize that there's a bit of exhaustion going on with regar= d > to these drafts, they are a bit of process we simply must get done in ord= er > to fully move forward with our agenda of putting together data models. =20 >=20 > We are *NOT* going to hold that work up further - it is clear that there = is > consenus to start making that progress. >=20 > To assist us with putting this work behind us, please respond to the > following questions: >=20 > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) >=20 > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > Do you think it is ready to be published as a RFC? > (Ditto.) >=20 > -- Jeff >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 6 07:10:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764D1A0108 for ; Fri, 6 Jun 2014 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyRF-7-HTkcb for ; Fri, 6 Jun 2014 07:10:49 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B89F1A00A5 for ; Fri, 6 Jun 2014 07:10:49 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so4568015qge.12 for ; Fri, 06 Jun 2014 07:10:42 -0700 (PDT) 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=LOIQ1GqIP0cbD336PIYif2K9LiZ+D+AC0137lBepJSg=; b=w2kmdb21Q36ZbqdALsxasUwTL2ofDcnIv7WCol3Y+SUFyaIqZutD9s+hhIqwYnaK7B TNZyB/xDwlOaZoTLHXRBNU9sSZ7whmQxGT3ALus4lFANLCdBD38cmAk4Owi2EPD+P3Ig 89m/IRZRGEPHVDNFPrf1VOKKR48fM7cm+pXRfz4Sv3K8dBS3fhk/Z0QSc69uMI7/y/6F 9GY4rjNMXbxSTBoaZVQGvhLoXguTQfm4Hp+l1NhzWtSZGjXD5Dg6ZX/XZkP+dpxYIIxg PunS0dFXtMLZPWUY48zYSLKUdZexNMtpDAbnrd/pmZ1hNp2BdRCtF+AitEs77craSA2T gmTA== MIME-Version: 1.0 X-Received: by 10.224.104.5 with SMTP id m5mr9257929qao.9.1402063842304; Fri, 06 Jun 2014 07:10:42 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Fri, 6 Jun 2014 07:10:42 -0700 (PDT) In-Reply-To: <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> References: <20140605202938.GP13606@pfrc> <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> Date: Fri, 6 Jun 2014 10:10:42 -0400 Message-ID: From: Alia Atlas To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a1132f48845ebcc04fb2b6de4 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/jlySef7IOM2W5XCpmtf0xXJqzR0 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:10:53 -0000 --001a1132f48845ebcc04fb2b6de4 Content-Type: text/plain; charset=UTF-8 Dean, On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic wrote: > Jeff, > > Problem statement: suggested changes, several times, still waiting for > those to be addressed in the draft. As my comments are not addressed, I > don't think draft is ready for WGLC or RFC. > Just a reminder - I have the changes ready to go as discussed. We were waiting on any other comments from the WGLC before updating the draft. Given the paucity of such comments and the availability of integers, I'll just submit it. Alia > Architecture document: ready for WGLC, ready for RFC > > Dean > > On Jun 5, 2014, at 4:29 PM, Jeffrey Haas wrote: > > > Working Group, > > > > The original deadline for comments on WGLC for the problem statement and > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on with > regard > > to these drafts, they are a bit of process we simply must get done in > order > > to fully move forward with our agenda of putting together data models. > > > > We are *NOT* going to hold that work up further - it is clear that there > is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > 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 > --001a1132f48845ebcc04fb2b6de4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dean,

On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic <= deanb@juniper.net> wrote:
Jeff,

Problem statement: =C2=A0suggested changes, several times, still waiting fo= r those to be addressed in the draft. As my comments are not addressed, I d= on't think draft is ready for WGLC or RFC.

Just a reminder - I have the changes ready to go as discussed. =C2=A0W= e were waiting on any other comments from the WGLC before updating the draf= t. =C2=A0Given the paucity of such comments and the
availability = of integers, I'll just submit it.

Alia
=C2=A0
Architecture document: ready for WGLC, ready for RFC

Dean

On Jun 5, 2014, at 4:29 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> Working Group,
>
> The original deadline for comments on WGLC for the problem statement a= nd
> architecture drafts of May 30 has passed with no comment whatsoever. >
> While we all realize that there's a bit of exhaustion going on wit= h regard
> to these drafts, they are a bit of process we simply must get done in = order
> to fully move forward with our agenda of putting together data models.=
>
> We are *NOT* going to hold that work up further - it is clear that the= re is
> consenus to start making that progress.
>
> To assist us with putting this work behind us, please respond to the > following questions:
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-= problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-archi= tecture/
> Have you read the architecture draft?
> Do you think it is ready to be published as a RFC?
> (Ditto.)
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--001a1132f48845ebcc04fb2b6de4-- From nobody Fri Jun 6 07:16:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13C1A0092; Fri, 6 Jun 2014 07:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNNFeXdRctK7; Fri, 6 Jun 2014 07:16:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26A1A00E5; Fri, 6 Jun 2014 07:16:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606141611.17273.53529.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 07:16:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pyq78lf-z4TJsNJJdqo1uUAnQsg Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 14:16:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Interface to the Routing System Problem Statement Authors : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-02.txt Pages : 10 Date : 2014-06-06 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 08:28:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606161A010D for ; Fri, 6 Jun 2014 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lODAAAjuhmC for ; Fri, 6 Jun 2014 08:27:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9343A1A00F6 for ; Fri, 6 Jun 2014 08:27:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5EA3D75F; Fri, 6 Jun 2014 17:27:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eVfe2eyGYkmy; Fri, 6 Jun 2014 17:27:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Jun 2014 17:27:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D5CB20017; Fri, 6 Jun 2014 17:27:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8Z5Eg3gIWqEa; Fri, 6 Jun 2014 17:27:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D95720013; Fri, 6 Jun 2014 17:27:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 410622D53646; Fri, 6 Jun 2014 17:27:48 +0200 (CEST) Date: Fri, 6 Jun 2014 17:27:48 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140606152748.GD15025@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org References: <20140605202938.GP13606@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140605202938.GP13606@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/C-UsS9urIYw-vvFpSoYZK-hjBJE Cc: i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 15:28:01 -0000 On Thu, Jun 05, 2014 at 04:29:38PM -0400, Jeffrey Haas wrote: > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) I have read (and the diff for -02). I have a couple of comments that I like to see addressed, some are purely editorial (and may be left to the RFC editor), others are I think clarification or suggestions for more appropriate wordings. - Please make sure the central figure fits on a single page since a page break in the middle is kind of disturbing. - What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'. - What are "_semantic-aware_ data models"? Either remove _semantic-aware_ or define it. - s/MIBs/MIB modules/ - s/MIB Notifications/MIB notifications/ - This is not quite correct: [...] nor is there the standardized ability to set up the router to trigger different actions upon an event's occurrence so that a rapid reaction can be accomplished. I believe the MIB modules that were created by the Distributed Manaement (DISMAN) working group provide this functionality. You may want to rephrase this so that it says that such MIB modules were not successfully deployed or something like that, but it is not correct that there are no standardized MIB modules for this. - I find some of the high throughput "desired aspect" of the protocol problematic, e.g. "should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can". I find this ill defined. I see this got fixed in -02 which just got posted and I appreciate that fix. - s/NetConf/NETCONF/ - The NETCONF community was forced to follow a sequential process and it took us time to create YANG after NETCONF and we are now getting core data models out (some published, some in the RFC queue, some in the hands of the IESG). Hence I like the following to be rephrased: OLD: However, the lack of standard data models have hampered the adoption of NetConf. NEW: However, the initial lack of standard data models has hampered early adoption of NETCONF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jun 6 08:51:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608C91A006E for ; Fri, 6 Jun 2014 08:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfCC5C7e8wjj for ; Fri, 6 Jun 2014 08:51:26 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC9A1A007E for ; Fri, 6 Jun 2014 08:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2864; q=dns/txt; s=iport; t=1402069872; x=1403279472; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7+RF3fpqr+a/uPoi5j+8tG43w2Db1hs5zga/alR4LPU=; b=XQnd84qdoZP1RUQZ0DNWmrc5XTsTM8Iwg0RUguH/zMztNOsM6bGSaBvh tXYHJzDVlXDdRf3/7pa+yQIdyFSKg5zGZGl+dnTiE47W1YRimLyGOwH2Q OdNWHJvkaGAx4dKnRZDe9T6q2+dcQpwSZ19AXRh0cTd5buQC4npoo6wO/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQLAD7ikVOtJA2D/2dsb2JhbABZgw1Sq0cFAZFPhzwBgQYWdYQDAQEBAwEBAQE1NgoBEAsOBAYJFggHCQMCAQIBFR8DDgYBDAEFAgEBiDYIDc0sF4VdiCoRAVAHhEEBA5YMhAqBQZF/gXyBXCGBOQ X-IronPort-AV: E=Sophos;i="4.98,989,1392163200"; d="scan'208";a="50871472" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 06 Jun 2014 15:51:11 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-44-142.cisco.com [10.150.44.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s56FpBMd009205; Fri, 6 Jun 2014 15:51:11 GMT Message-ID: <5391E36F.7060605@cisco.com> Date: Fri, 06 Jun 2014 11:51:11 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alia Atlas , Dean Bogdanovic References: <20140605202938.GP13606@pfrc> <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/KROexJJCRc-46ZcVlyZ9SntM8WI Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:51:34 -0000 On 6/6/14, 10:10 AM, Alia Atlas wrote: > Dean, > > On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic > wrote: > > Jeff, > > Problem statement: suggested changes, several times, still waiting > for those to be addressed in the draft. As my comments are not > addressed, I don't think draft is ready for WGLC or RFC. > > > Just a reminder - I have the changes ready to go as discussed. We were > waiting on any other comments from the WGLC before updating the draft. > Given the paucity of such comments and the > availability of integers, I'll just submit it. I also had some comments on the last architecture draft. While some of them were silently addressed, there were a couple where I expected the authors to respond. I can resend the email if you missed it. It was a while ago. Joe > > Alia > > Architecture document: ready for WGLC, ready for RFC > > Dean > > On Jun 5, 2014, at 4:29 PM, Jeffrey Haas > wrote: > > > Working Group, > > > > The original deadline for comments on WGLC for the problem > statement and > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on > with regard > > to these drafts, they are a bit of process we simply must get > done in order > > to fully move forward with our agenda of putting together data > models. > > > > We are *NOT* going to hold that work up further - it is clear > that there is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Jun 6 12:15:19 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA911A0220 for ; Fri, 6 Jun 2014 12:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLx4hCX6ynHN for ; Fri, 6 Jun 2014 12:15:15 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90A51A008B for ; Fri, 6 Jun 2014 12:15:14 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j5so5448953qga.0 for ; Fri, 06 Jun 2014 12:15:07 -0700 (PDT) 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 :content-type; bh=Qsdp/3euDX+r/jOoIdV/7TdHy+KwycgSMjX9yLo17gs=; b=s3IcVaO8ec6FLst7hPmxqCCZG5sEvlvxExGsj6rC3W323XStuTmDJ1lvQYswZ4WZSR p/mWK0dtboQz4EdFtXl0rJ9j7rXlKMjvX+cTN0pLCP0J8Ah0nH+CKGm44pgdH+Tvk8lk 8FEHQ13mG65RtmPH+7+C1x3o2eJ8TSidejnETrP7gd1GZjy+3AGqv1CQPJd1VWY8PneP /M+5iTgtZzNxAue+gXRilu3j/Kq/onUEOr43quLqWFAxp4PZKF/AGsSdLXvUzw/hX0kj P7FxSXIY7sqwe+/ays2//wbbJs2OaMMwCTD4zBBRyDsg9F+apta1M4OvNF/ThdyNAu6P ybhg== MIME-Version: 1.0 X-Received: by 10.224.104.5 with SMTP id m5mr12179978qao.9.1402082107688; Fri, 06 Jun 2014 12:15:07 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Fri, 6 Jun 2014 12:15:07 -0700 (PDT) In-Reply-To: <20140606152748.GD15025@elstar.local> References: <20140605202938.GP13606@pfrc> <20140606152748.GD15025@elstar.local> Date: Fri, 6 Jun 2014 15:15:07 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Jeffrey Haas , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a1132f488f98cb604fb2fadee Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JezazMScFQ7HSmkNciPgq1o63Tg Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 19:15:17 -0000 --001a1132f488f98cb604fb2fadee Content-Type: text/plain; charset=UTF-8 Hi Juergen, Please see my responses/resolutions below. I'll be submitting a version -03 with these changes (plus a couple wording changes from Dean). Thanks for the review! Alia On Fri, Jun 6, 2014 at 11:27 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jun 05, 2014 at 04:29:38PM -0400, Jeffrey Haas wrote: > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > I have read (and the diff > for -02). I have a couple of comments that I like to see addressed, > some are purely editorial (and may be left to the RFC editor), others > are I think clarification or suggestions for more appropriate wordings. > > - Please make sure the central figure fits on a single page since a > page break in the middle is kind of disturbing. > > - What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'. > Replaced "clear" with "concise"... > - What are "_semantic-aware_ data models"? Either remove > _semantic-aware_ or define it. > Replaced with "meaningful" > - s/MIBs/MIB modules/ Done > - s/MIB Notifications/MIB notifications/ Done > - This is not quite correct: > [...] nor is there the > standardized ability to set up the router to trigger different > actions upon an event's occurrence so that a rapid reaction can be > accomplished. > > I believe the MIB modules that were created by the Distributed > Manaement (DISMAN) working group provide this functionality. You may > want to rephrase this so that it says that such MIB modules were not > successfully deployed or something like that, but it is not correct > that there are no standardized MIB modules for this. > > - I find some of the high throughput "desired aspect" of the protocol > problematic, e.g. "should be able to handle a considerable number of > operations per second above what basic Netconf or a propretiary CLI > can". I find this ill defined. I see this got fixed in -02 which > just got posted and I appreciate that fix. > Replaced with "While a few of these (e.g. link up/down) may be available via MIB notifications today, the full range is not - nor has there been successfully deployed the standardized ability to set up the router to trigger different actions upon an event's occurrence so that a rapid reaction can be accomplished. " > - s/NetConf/NETCONF/ > > - The NETCONF community was forced to follow a sequential process and > it took us time to create YANG after NETCONF and we are now getting > core data models out (some published, some in the RFC queue, some in > the hands of the IESG). Hence I like the following to be rephrased: > > OLD: > > However, the lack of > standard data models have hampered the adoption of NetConf. > > NEW: > > However, the initial lack of > standard data models has hampered early adoption of NETCONF. Done. > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1132f488f98cb604fb2fadee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi J= uergen,

Please see my responses/resolutions below. =C2=A0I'll be submitting
a version -03 with these changes (plus a couple wording changes from Dean).=

Thank= s for the review!
Alia

On Fri, Jun 6, 2014 at 11:27 AM, Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
On Thu, Jun 05, 2014 at 04:29:38PM -0400, = Jeffrey Haas wrote:

> http://datatracker.ietf.org/doc/draft-ietf-i2rs-= problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)

I have read <draft-ietf-i2rs-problem-statement-01.txt> (and the= diff
for -02). I have a couple of comments that I like to see addressed,
some are purely editorial (and may be left to the RFC editor), others
are I think clarification or suggestions for more appropriate wordings.

- Please make sure the central figure fits on a single page since a
=C2=A0 page break in the middle is kind of disturbing.

- What is a "_clear_ transfer syntax"? Perhaps simply remove '= ;clear'.

Replaced "clear"= with "concise"...
=C2=A0
- What are "_semantic-aware_ data models"? Either remove
=C2=A0 _semantic-aware_ or define it.

R= eplaced with "meaningful"=C2=A0
=C2=A0
- s/MIBs/MIB modules/

Done=C2=A0
= =C2=A0
- s/MIB Notifications/MIB notifications/

Do= ne
=C2=A0
=C2=A0- This is not quite correct:

=C2=A0 =C2=A0 [...] nor is there the
=C2=A0 =C2=A0 standardized ability to set up the router to trigger differen= t
=C2=A0 =C2=A0 actions upon an event's occurrence so that a rapid reacti= on can be
=C2=A0 =C2=A0 accomplished.

=C2=A0 I believe the MIB modules that were created by the Distributed
=C2=A0 Manaement (DISMAN) working group provide this functionality. You may=
=C2=A0 want to rephrase this so that it says that such MIB modules were not=
=C2=A0 successfully deployed or something like that, but it is not correct<= br> =C2=A0 that there are no standardized MIB modules for this.

- I find some of the high throughput "desired aspect" of the prot= ocol
=C2=A0 problematic, e.g. "should be able to handle a considerable numb= er of
=C2=A0 operations per second above what basic Netconf or a propretiary CLI<= br> =C2=A0 can". I find this ill defined. I see this got fixed in -02 whic= h
=C2=A0 just got posted and I appreciate that fix.

=
Replaced with "While a few of these (e.g. link up/down)
=C2=A0 =C2=A0 =C2=A0 may be available via MIB notifications today, t= he full range is
=C2=A0 =C2=A0 =C2=A0 not - nor has there been successfully deployed th= e standardized
=C2=A0 =C2=A0 =C2=A0 ability to set up the router = to trigger different actions upon
=C2=A0 =C2=A0 =C2=A0 an event&#= 39;s occurrence so that a rapid reaction can be
=C2=A0 =C2=A0 =C2=A0 accomplished.=C2=A0"

=C2=A0
- s/NetConf/NETCONF/

- The NETCONF community was forced to follow a sequential process and
=C2=A0 it took us time to create YANG after NETCONF and we are now getting<= br> =C2=A0 core data models out (some published, some in the RFC queue, some in=
=C2=A0 the hands of the IESG). Hence I like the following to be rephrased:<= br>
=C2=A0 OLD:

=C2=A0 =C2=A0 However, the lack of
=C2=A0 =C2=A0 standard data models have hampered the adoption of NetConf.
=C2=A0 NEW:

=C2=A0 =C2=A0 However, the initial lack of
=C2=A0 =C2=A0 standard data models has hampered early adoption of NETCONF.<= /blockquote>

Done.=C2=A0

=C2=A0=
/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >

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

--001a1132f488f98cb604fb2fadee-- From nobody Fri Jun 6 12:21:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0B51A016F; Fri, 6 Jun 2014 12:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mbk0uYqQUoxS; Fri, 6 Jun 2014 12:20:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E76651A021A; Fri, 6 Jun 2014 12:20:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606192056.20811.62692.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 12:20:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5RDXTZJw7p2PWfj7ii0Hy0p8T58 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 19:20:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Interface to the Routing System Problem Statement Authors : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-03.txt Pages : 10 Date : 2014-06-06 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 12:23:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A101A021A for ; Fri, 6 Jun 2014 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb9lunxzda7o for ; Fri, 6 Jun 2014 12:23:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 088131A008B for ; Fri, 6 Jun 2014 12:23:13 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 6 Jun 2014 19:23:00 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Fri, 6 Jun 2014 19:22:59 +0000 From: Dean Bogdanovic To: Alia Atlas , Jeffrey Haas Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: AQHPgP0tb0YxraJvlEmJQS1sKbk3SptkNcMAgAA/g4CAAAIxgA== Date: Fri, 6 Jun 2014 19:22:59 +0000 Message-ID: <4CAC9057-01A9-457E-B343-82A2BD32EAE7@juniper.net> References: <20140605202938.GP13606@pfrc> <20140606152748.GD15025@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(51914003)(377454003)(199002)(189002)(104166001)(101416001)(76482001)(76176999)(87936001)(33656002)(46102001)(50986999)(81342001)(88136002)(89996001)(81542001)(2656002)(87286001)(62966002)(83716003)(21056001)(74662001)(31966008)(82746002)(74502001)(15975445006)(16236675004)(92566001)(85852003)(99286001)(99396002)(83072002)(19580395003)(50226001)(19580405001)(83322001)(93916002)(92726001)(86362001)(80022001)(79102001)(77982001)(15202345003)(20776003)(64706001)(77156001)(36756003)(66066001)(4396001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_4CAC905701A9457EB34382A2BD32EAE7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gDwl2iYorDavshsM8QZKsTHhPl4 Cc: "" , Juergen Schoenwaelder Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 19:23:16 -0000 --_000_4CAC905701A9457EB34382A2BD32EAE7junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jeff, Alia answered my concerns and am fine with the draft for WGLC and RFC Dean On Jun 6, 2014, at 3:15 PM, Alia Atlas > wrote: Hi Juergen, Please see my responses/resolutions below. I'll be submitting a version -03 with these changes (plus a couple wording changes from Dean). Thanks for the review! Alia On Fri, Jun 6, 2014 at 11:27 AM, Juergen Schoenwaelder > wrote: On Thu, Jun 05, 2014 at 04:29:38PM -0400, Jeffrey Haas wrote: > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) I have read (and the diff for -02). I have a couple of comments that I like to see addressed, some are purely editorial (and may be left to the RFC editor), others are I think clarification or suggestions for more appropriate wordings. - Please make sure the central figure fits on a single page since a page break in the middle is kind of disturbing. - What is a "_clear_ transfer syntax"? Perhaps simply remove 'clear'. Replaced "clear" with "concise"... - What are "_semantic-aware_ data models"? Either remove _semantic-aware_ or define it. Replaced with "meaningful" - s/MIBs/MIB modules/ Done - s/MIB Notifications/MIB notifications/ Done - This is not quite correct: [...] nor is there the standardized ability to set up the router to trigger different actions upon an event's occurrence so that a rapid reaction can be accomplished. I believe the MIB modules that were created by the Distributed Manaement (DISMAN) working group provide this functionality. You may want to rephrase this so that it says that such MIB modules were not successfully deployed or something like that, but it is not correct that there are no standardized MIB modules for this. - I find some of the high throughput "desired aspect" of the protocol problematic, e.g. "should be able to handle a considerable number of operations per second above what basic Netconf or a propretiary CLI can". I find this ill defined. I see this got fixed in -02 which just got posted and I appreciate that fix. Replaced with "While a few of these (e.g. link up/down) may be available via MIB notifications today, the full range is not - nor has there been successfully deployed the standardized ability to set up the router to trigger different actions upon an event's occurrence so that a rapid reaction can be accomplished. " - s/NetConf/NETCONF/ - The NETCONF community was forced to follow a sequential process and it took us time to create YANG after NETCONF and we are now getting core data models out (some published, some in the RFC queue, some in the hands of the IESG). Hence I like the following to be rephrased: OLD: However, the lack of standard data models have hampered the adoption of NetConf. NEW: However, the initial lack of standard data models has hampered early adoption of NETCONF. Done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1= , 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_4CAC905701A9457EB34382A2BD32EAE7junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <93337EEDCDD0EB40A34F292E3C36EC1F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Jeff,

Alia answered my concerns and am fine with the draft for WGLC and RFC<= /div>

Dean

On Jun 6, 2014, at 3:15 PM, Alia Atlas <akatlas@gmail.com> wrote:

Hi Juergen,

Please see my responses/resolutions below.  = ;I'll be submitting
a version -03 with these changes (plus a couple = wording changes from Dean).

Thanks for the review!
Alia

On Fri, Jun 6, 2014 at 11:27 AM, Juergen Schoenw= aelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jun 05, 2014 at 04:29:38PM -0400, Jeffrey Haas wrot= e:

> http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)

I have read <draft-ietf-i2rs-problem-statement-01.txt> (and the diff<= br> for -02). I have a couple of comments that I like to see addressed,
some are purely editorial (and may be left to the RFC editor), others
are I think clarification or suggestions for more appropriate wordings.

- Please make sure the central figure fits on a single page since a
  page break in the middle is kind of disturbing.

- What is a "_clear_ transfer syntax"? Perhaps simply remove 'cle= ar'.

Replaced "clear" with "concise"...
 
- What are "_semantic-aware_ data models"? Either remove
  _semantic-aware_ or define it.

Replaced with "meaningful" 
 
- s/MIBs/MIB modules/

Done 
 
- s/MIB Notifications/MIB notifications/

Done
 
 - This is not quite correct:

    [...] nor is there the
    standardized ability to set up the router to trigger differen= t
    actions upon an event's occurrence so that a rapid reaction c= an be
    accomplished.

  I believe the MIB modules that were created by the Distributed
  Manaement (DISMAN) working group provide this functionality. You may=
  want to rephrase this so that it says that such MIB modules were not=
  successfully deployed or something like that, but it is not correct<= br>   that there are no standardized MIB modules for this.

- I find some of the high throughput "desired aspect" of the prot= ocol
  problematic, e.g. "should be able to handle a considerable numb= er of
  operations per second above what basic Netconf or a propretiary CLI<= br>   can". I find this ill defined. I see this got fixed in -02 whic= h
  just got posted and I appreciate that fix.

Replaced with "While a few of these (e.g. link up/down)
      may be available via MIB notifications today, the= full range is
      not - nor has there been successfully deployed th= e standardized
      ability to set up the router to trigger different= actions upon
      an event's occurrence so that a rapid reaction ca= n be
      accomplished. "

 
- s/NetConf/NETCONF/

- The NETCONF community was forced to follow a sequential process and
  it took us time to create YANG after NETCONF and we are now getting<= br>   core data models out (some published, some in the RFC queue, some in=
  the hands of the IESG). Hence I like the following to be rephrased:<= br>
  OLD:

    However, the lack of
    standard data models have hampered the adoption of NetConf.
  NEW:

    However, the initial lack of
    standard data models has hampered early adoption of NETCONF.<= /blockquote>

Done. 

 
/js

--
Juergen Schoenwaelder           Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 = Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-univer= sity.de/>

_______________________________________________
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_4CAC905701A9457EB34382A2BD32EAE7junipernet_-- From nobody Fri Jun 6 12:42:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AE01A0078 for ; Fri, 6 Jun 2014 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCdaonlSqW2R for ; Fri, 6 Jun 2014 12:41:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CA51A01AA for ; Fri, 6 Jun 2014 12:41:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0AF04ABA; Fri, 6 Jun 2014 21:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id apIDPs2sucSs; Fri, 6 Jun 2014 21:41:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Jun 2014 21:41:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 364F720017; Fri, 6 Jun 2014 21:41:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3RXOK6NK04XL; Fri, 6 Jun 2014 21:41:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85E6D20013; Fri, 6 Jun 2014 21:41:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 499FE2D537FF; Fri, 6 Jun 2014 21:41:44 +0200 (CEST) Date: Fri, 6 Jun 2014 21:41:44 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20140606194143.GA15646@elstar.local> Mail-Followup-To: Alia Atlas , Jeffrey Haas , "i2rs@ietf.org" References: <20140605202938.GP13606@pfrc> <20140606152748.GD15025@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UzkdGWTm4gtouarGa41oQyv3zfg Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jun 2014 19:41:57 -0000 On Fri, Jun 06, 2014 at 03:15:07PM -0400, Alia Atlas wrote: > Hi Juergen, > > Please see my responses/resolutions below. I'll be submitting > a version -03 with these changes (plus a couple wording changes from Dean). > Thanks for the changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jun 6 13:03:19 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B591A0086 for ; Fri, 6 Jun 2014 13:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNOCMAYsTjhf for ; Fri, 6 Jun 2014 13:03:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A791A0078 for ; Fri, 6 Jun 2014 13:03:13 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 6 Jun 2014 20:03:05 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Fri, 6 Jun 2014 20:02:58 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Thread-Index: AQHPgcJPUJvejJP5KkGEiMWG5tf2EA== Date: Fri, 6 Jun 2014 20:02:58 +0000 Message-ID: <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> In-Reply-To: <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 023495660C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(13464003)(377454003)(377424004)(51704005)(24454002)(74502001)(31966008)(83322001)(83072002)(77982001)(85852003)(88136002)(77156001)(15975445006)(83716003)(74662001)(82746002)(81542001)(89996001)(101416001)(76482001)(15202345003)(80022001)(66066001)(46102001)(19580405001)(93916002)(21056001)(19580395003)(86362001)(99396002)(99286001)(76176999)(62966002)(50986999)(2656002)(64706001)(87936001)(20776003)(87286001)(79102001)(36756003)(92566001)(92726001)(81342001)(93886002)(33656002)(104166001)(50226001)(4396001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB440; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/AGEnWpzyYzpClLznaakWp-gG7HQ Cc: "" , Susan Hares , "" , "t.petch" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:03:16 -0000 Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Rea= chability Information , so writing it out first time would be a good idea.= =20 Throughout the text, the requirement number sequence is confusing until you= get to the very and where all requirements are listed and then it makes se= nse. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should = impose persistent policies? It says it should be recorded in the configurat= ion of the local device. I agree that those policies should be visible to operators and other applic= ations, but not sure if dynamic protocols should be allowed to implement pe= rsistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such = as NETCONF, and should be recorded in the running or ephemeral configuratio= n of the local device so operators are aware of the full policy implemented= in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a= good idea. If you plan to change only what is configured on the local devi= ce, then that is OK, but if you start changing entries that are pushed from= other devices in the network, the system would get unstable. And it looks = to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares wrote: > Tom:=20 >=20 > I'm glad to change the citation in the abstract. On the authors, this = was > merge of two drafts.=20 >=20 > Sue =20 >=20 > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com]=20 > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan Hares'; > rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.t= xt >=20 > Sue >=20 > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders whom I > can expect to act. Too often, with so many names, everyone thinks that > someone else will do something and nothing happens, so, in all seriousnes= s, > I oppose adoption until you sort this out amongst yourselves. >=20 > Note too that you have a citation in the Abstract, again not allowed - th= is > can be surprising difficult to get round but get round it you, one or mor= e > thereof, must. >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Susan Hares" > To: > Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" > ; "Russ White" ; "'Susan Hares'" > ; > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >=20 >=20 >> Jeff and Ed: >>=20 >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >>=20 >> Would you please do a Working Group adoption call? >>=20 >> Thank you, >> Sue Hares >>=20 >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >>=20 >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >>=20 >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >>=20 >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 6 13:54:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E788A1A0290 for ; Fri, 6 Jun 2014 13:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le1nPLHamDRE for ; Fri, 6 Jun 2014 13:54:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4DC1A0274 for ; Fri, 6 Jun 2014 13:54:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6A842C23D; Fri, 6 Jun 2014 16:54:49 -0400 (EDT) Date: Fri, 6 Jun 2014 16:54:49 -0400 From: Jeffrey Haas To: Joe Marcus Clarke Message-ID: <20140606205449.GG16551@pfrc> References: <20140605202938.GP13606@pfrc> <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> <5391E36F.7060605@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5391E36F.7060605@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/p-LXROOCfkezke8aT4HxXlMvv0k Cc: Jeffrey Haas , "i2rs@ietf.org" , Dean Bogdanovic , Alia Atlas Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:54:58 -0000 Joe, On Fri, Jun 06, 2014 at 11:51:11AM -0400, Joe Marcus Clarke wrote: > I also had some comments on the last architecture draft. While some > of them were silently addressed, there were a couple where I > expected the authors to respond. I can resend the email if you > missed it. It was a while ago. Would you please review your comments and re-post the ones still waiting for action? Thanks! -- Jeff (who's hoping to avoid the need to use the trac system..) From nobody Fri Jun 6 13:57:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24541A0299 for ; Fri, 6 Jun 2014 13:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgFtMVq60Vlw for ; Fri, 6 Jun 2014 13:57:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E64E71A027C for ; Fri, 6 Jun 2014 13:57:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> In-Reply-To: <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> Date: Fri, 6 Jun 2014 16:57:20 -0400 Message-ID: <005b01cf81c9$e8d8ddd0$ba8a9970$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qAGayTg4AbY3QWQChw5Z8wECQGW8mvSMx0A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/nrOh7pNTpHNcq1rL8fJReFr_AHQ Cc: i2rs@ietf.org, 'Susan Hares' , rex@cisco.com, "'t.petch'" , "'Keyur Patel \(keyupate\)'" , 'Hannes Gredler' , 'Russ White' Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 20:57:49 -0000 Dean: Thank you for the complete review of version 3. Great review! On readability, Jeff Haas suggest putting all the requirements in the front. Would that make it better? It's an easy switch (other than listening to Jeff say "I told you so"). On configuration persistence, you are correct. My understanding of the feedback from the WG had been write from I2RS datastore to configuration datastore. I will go back and review the posts from the WG and check with co-authors dynamic memory. If the intent is empheral store, then we can use a variant of your text. On REQ01/02 - (01) Read/write access versus (02) notification and REQ08/09 - (08) Write versus (09) read/notify status --- I agree these could be combined if the WG desires or split on read/write versus notification. Do you have any preference? On the danger of inserting flow specifications, you are right. However, see IDR's discussion flow specification for choices. IDRs argues advanced features are like a rope, chair and whip - one can either hang oneself or tame a lion. Sue -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; ; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Reachability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you get to the very and where all requirements are listed and then it makes sense. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should impose persistent policies? It says it should be recorded in the configuration of the local device. I agree that those policies should be visible to operators and other applications, but not sure if dynamic protocols should be allowed to implement persistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the running or ephemeral configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a good idea. If you plan to change only what is configured on the local device, then that is OK, but if you start changing entries that are pushed from other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourselves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" > To: > Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" > ; "Russ White" ; "'Susan Hares'" > ; > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 6 14:34:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778EB1A02A9 for ; Fri, 6 Jun 2014 14:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqUQ6ONpu_T9 for ; Fri, 6 Jun 2014 14:34:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C841A0274 for ; Fri, 6 Jun 2014 14:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3155; q=dns/txt; s=iport; t=1402090439; x=1403300039; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=OM5gzLS100xhNo9K4puHZKM/2D4O/PLpV+ZVla3kGmI=; b=EqQKNxYIw5UyOhtKcfbswjuKHum5RvOneQDC1/GVsxJYavbTOHvxdZjT pvQf3IIZDH1dFRt7acYEls6TKp/s1VATP+ayRc06r87N8XIAL4JqMxXfH Oj3Jz7GQCe46WU5ChrOVIda9EqQIx9OE5L3v53MSLt1CkZzxYqpi8I+U/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugKACIzklOtJA2I/2dsb2JhbABZgw1Sq0wGmRABgQcWdYQDAQEBBDhAEQsOBAYJFg8JAwIBAgE3DgYBDAgBAYg+Dc1QF4VdiFk6hEEBA5YThAqBQpICgXyBXCE X-IronPort-AV: E=Sophos;i="4.98,991,1392163200"; d="scan'208";a="50959750" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 06 Jun 2014 21:33:58 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-44-142.cisco.com [10.150.44.142]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s56LXw9s027044; Fri, 6 Jun 2014 21:33:58 GMT Message-ID: <539233C5.2070700@cisco.com> Date: Fri, 06 Jun 2014 17:33:57 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , i2rs@ietf.org References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ESej5eqAbKk4pC_yoUMRO5SVSF4 Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 21:34:09 -0000 On 6/5/14, 4:29 PM, Jeffrey Haas wrote: > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > Do you think it is ready to be published as a RFC? > (Ditto.) Here is a list of my previous comments that didn't get addressed in the text or on the list. In section 1.1, the first paragraph states: ...Second is the access to structured information and state that is frequently not directly configurable... Then in paragraph four: ...I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration... While you do use the word "conceptually," it's hard to conceive of something that is at the same time safe to modify via the configuration but is not exposed via the configuration. That is, how would one know what is safe? This might benefit from an early example to clarify what is meant and perhaps it is good enough to drop the bit about modifiable via local configuration and just say that modification of protocol internal state is out of scope. === In section 1.2, the new text helps to show how App, Client, and Agent fit together, but I wonder if this same new text wouldn't benefit from a statement that App to Client communication is out of scope. That is, you state that the Client and Agent communicate via an asynchronous protocol, but nothing is said about, for example, how apps C, D, E communicate with Client P. You do mention this further down in the doc, so it's a minor thing, but perhaps worth a sentence here. === Section 2, in the I2RS Client paragraph, I can't get my head around this text: Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of the routing system the client interacts with to achieve operational goals. The first part makes sense, but then it starts to sound muddled, at least to me. Maybe you want to say: Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of the routing system in order to achieve operational goals. === Section 4. While streaming OSPF prefix announcements MAY NOT require confidentiality, some users may want it. Paragraph 4 starts out, Other communications via I2RS will not... I think this should say may not just to make it clear that this can be optional based on specific environmental requirements. === Section 7.1. This is mainly an editorial, but in looking back at things like NETCONF over BEEP, one goal might be to make sure the transport chosen is both operator and implementor friendly in terms of ease of adoption. === Section 7.5. Would a supervisory application work in this case? I suppose it could if it shared the same ID, but that wouldn't work for multiple applications. Likely a better approach would be to allow the Client to accept some meta-instructions at the beginning of a session as to what to do if the app goes away (as you state in paragraph 4). Thanks. Joe From nobody Fri Jun 6 18:51:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F231A02B5 for ; Fri, 6 Jun 2014 18:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTEfjbIvhwhB for ; Fri, 6 Jun 2014 18:51:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C591A02AC for ; Fri, 6 Jun 2014 18:51:00 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sat, 7 Jun 2014 01:50:52 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Sat, 7 Jun 2014 01:50:51 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Thread-Index: AQHPgcJPUJvejJP5KkGEiMWG5tf2EJtkkEsAgABSAIA= Date: Sat, 7 Jun 2014 01:50:50 +0000 Message-ID: References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <005b01cf81c9$e8d8ddd0$ba8a9970$@ndzh.com> In-Reply-To: <005b01cf81c9$e8d8ddd0$ba8a9970$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377424004)(199002)(189002)(24454002)(51704005)(377454003)(13464003)(15202345003)(76176999)(66066001)(50986999)(87936001)(20776003)(93886002)(104166001)(33656002)(62966002)(76482001)(77156001)(85852003)(77982001)(31966008)(93916002)(79102001)(74662001)(36756003)(74502001)(81342001)(46102001)(86362001)(81542001)(89996001)(57306001)(99396002)(83716003)(82746002)(83072002)(83322001)(101416001)(64706001)(21056001)(80022001)(19580395003)(19580405001)(99286001)(4396001)(2656002)(92566001)(15975445006)(50226001)(87286001)(92726001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB439; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <998FA48A8AC7B14C95FA7AC7DAAFF908@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ElbI4vmXV78HuoiTgfk6S4eGJfg Cc: "" , Susan Hares , "" , "t.petch" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:51:03 -0000 On Jun 6, 2014, at 4:57 PM, Susan Hares wrote: > Dean: >=20 > Thank you for the complete review of version 3. Great review!=20 >=20 > On readability, Jeff Haas suggest putting all the requirements in the fro= nt. > Would that make it better? It's an easy switch (other than listening to > Jeff say "I told you so"). =20 I don't like giving Jeff opportunity to use that sentence, but I'm in agree= ment with Jeff. Putting the requirement list upfront makes more sense and t= hen you don't have to repeat the whole requirement, you can just list it. > On configuration persistence, you are correct. > My understanding of the feedback from the WG had been write from I2RS > datastore to configuration datastore. I will go back and review the post= s > from the WG and check with co-authors dynamic memory. If the intent is > empheral store, then we can use a variant of your text.=20 OK >=20 > On REQ01/02 - (01) Read/write access versus (02) notification and REQ08= /09 > - (08) Write versus (09) read/notify status --- I agree these could be > combined if the WG desires or split on read/write versus notification. Do > you have any preference?=20 My preference would be read/notify and write. The reason is that read/notif= y are used for operational and analytic purposes and write is an action bas= ed on operational and analytical result. >=20 > On the danger of inserting flow specifications, you are right. However, s= ee > IDR's discussion flow specification for choices. IDRs argues advanced > features are like a rope, chair and whip - one can either hang oneself or > tame a lion. =20 or be mauled by the lion. I've seen so many times by giving the tools to th= e people, they shot themselves into the foot, so am careful about it. Just = talking from experience. >=20 > Sue=20 >=20 > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net]=20 > Sent: Friday, June 06, 2014 4:03 PM > To: Susan Hares > Cc: t.petch; ; Keyur Patel (keyupate); Hannes Gredler; Rus= s > White; Susan Hares; > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >=20 > Susan, >=20 > Many people don't know what NLRI abbreviation stands for (Network Layer > Reachability Information , so writing it out first time would be a good > idea.=20 >=20 > Throughout the text, the requirement number sequence is confusing until y= ou > get to the very and where all requirements are listed and then it makes > sense. >=20 > REQ04: The ability to interact with various policies configured on > the forwarding devices, in order to inform the policies > implemented by the dynamic routing processes. This interaction > should be through existing configuration mechanisms, such as > NETCONF, and should be recorded in the configuration of the local > device so operators are aware of the full policy implemented in > the network from the running configuration. > It is not clear to me if your requirement is that dynamic protocols shoul= d > impose persistent policies? It says it should be recorded in the > configuration of the local device. >=20 > I agree that those policies should be visible to operators and other > applications, but not sure if dynamic protocols should be allowed to > implement persistent policies. IMO, those should be ephemeral policies. > So maybe text should look like this > This interaction should be through existing configuration mechanisms, suc= h > as NETCONF, and should be recorded in the running or ephemeral configurat= ion > of the local device so operators are aware of the full policy implemented= in > the network from the running configuration. >=20 > I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? >=20 > In general I'm not sure if changing entries by dynamic protocol in RIB is= a > good idea. If you plan to change only what is configured on the local > device, then that is OK, but if you start changing entries that are pushe= d > from other devices in the network, the system would get unstable. And it > looks to me that REQ09 would allow that. >=20 > Dean >=20 >=20 > On Jun 5, 2014, at 4:47 AM, Susan Hares wrote: >=20 >> Tom:=20 >>=20 >> I'm glad to change the citation in the abstract. On the authors, this > was >> merge of two drafts.=20 >>=20 >> Sue >>=20 >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Thursday, June 05, 2014 4:35 AM >> To: Susan Hares; i2rs@ietf.org >> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan=20 >> Hares'; rex@cisco.com >> Subject: Re: [i2rs] FW: I-D Action:=20 >> draft-keyupate-i2rs-bgp-usecases-02.txt >>=20 >> Sue >>=20 >> Currently you have six authors which is too many for an RFC - someone's >> got to go! For me, this is not just an admin point - when commenting, >> I like to have one or two names, no more, as the clear pen holders=20 >> whom I can expect to act. Too often, with so many names, everyone=20 >> thinks that someone else will do something and nothing happens, so, in=20 >> all seriousness, I oppose adoption until you sort this out amongst > yourselves. >>=20 >> Note too that you have a citation in the Abstract, again not allowed -=20 >> this can be surprising difficult to get round but get round it you,=20 >> one or more thereof, must. >>=20 >> Tom Petch >>=20 >>=20 >> ----- Original Message ----- >> From: "Susan Hares" >> To: >> Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" >> ; "Russ White" ; "'Susan Hares'" >> ; >> Sent: Wednesday, June 04, 2014 7:49 PM >> Subject: [i2rs] FW: I-D Action:=20 >> draft-keyupate-i2rs-bgp-usecases-02.txt >>=20 >>=20 >>> Jeff and Ed: >>>=20 >>> This updated draft has all the changes that Keyur Patel promised and >> updates >>> to the reference the current i2rs internet drafts. >>>=20 >>> Would you please do a Working Group adoption call? >>>=20 >>> Thank you, >>> Sue Hares >>>=20 >>>=20 >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of=20 >>> internet-drafts@ietf.org >>> Sent: Wednesday, June 04, 2014 1:44 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> This draft is a work item of the Interface to the Routing System >> Working >>> Group of the IETF. >>>=20 >>> Title : Use Cases for an Interface to BGP Protocol >>> Authors : Keyur Patel >>> Rex Fernando >>> Hannes Gredler >>> Shane Amante >>> Russ White >>> Susan Hares >>> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >>> Pages : 17 >>> Date : 2014-06-04 >>>=20 >>> Abstract: >>> A network routing protocol like BGP is typically configured and >>> analyzed through some form of Command Line Interface (CLI) or >>> NETCONF. These interactions to control BGP and diagnose its >>> operation encompass: configuration of protocol parameters, display >> of >>> protocol data, setting of certain protocol state and debugging of >> the >>> protocol. >>>=20 >>> Interface to the Routing System's (I2RS) Programmatic interfaces, >> as >>> defined in draft-ietf-i2rs-architecture, provides an alternate way >> to >>> control and diagnose the operation of the BGP protocol. I2RS may >> be >>> used for the configuration, manipulation, analyzing or collecting >> the >>> protocol data. This document describes set of use cases for which >>> I2RS can be used for BGP protocol. It is intended to provide a >> base >>> for the solution draft describing a set of interfaces to the BGP >>> protocol. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 From nobody Sat Jun 7 11:05:31 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6C81A014D for ; Sat, 7 Jun 2014 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3Lt0QhXMWNM for ; Sat, 7 Jun 2014 11:05:27 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9071A0171 for ; Sat, 7 Jun 2014 11:05:27 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s57I5KMl017798; Sat, 7 Jun 2014 11:05:20 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1mbrb305bv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 07 Jun 2014 11:05:20 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 7 Jun 2014 11:05:19 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::a540:dc22:25c4:398e]) by HQ1WP-EXHUB01.corp.brocade.com ([fe80::55ee:533:4b9d:a097%12]) with mapi; Sat, 7 Jun 2014 11:05:19 -0700 From: ramki Krishnan To: Jeffrey Haas , "i2rs@ietf.org" Date: Sat, 7 Jun 2014 11:05:18 -0700 Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: Ac+A/SvbrOh/3lejSS6U3IfPsGkPuwBfb6Qg Message-ID: References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-07_02:2014-06-06,2014-06-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406070239 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2e-vhOu8zyiq7pSAQLJpe_rTgfE Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 18:05:29 -0000 http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ Have you read the problem statement draft? yes Do you think it is ready to be published as a RFC? yes http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Have you read the architecture draft? yes Do you think it is ready to be published as a RFC? yes Thanks, Ramki -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Thursday, June 05, 2014 1:30 PM To: i2rs@ietf.org Subject: [i2rs] Working Group Last Call on architecture and problem stateme= nt drafts (redux) Working Group, The original deadline for comments on WGLC for the problem statement and ar= chitecture drafts of May 30 has passed with no comment whatsoever. While we all realize that there's a bit of exhaustion going on with regard = to these drafts, they are a bit of process we simply must get done in order= to fully move forward with our agenda of putting together data models. =20 We are *NOT* going to hold that work up further - it is clear that there is= consenus to start making that progress. To assist us with putting this work behind us, please respond to the follow= ing questions: http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ Have you read the problem statement draft? Do you think it is ready to be published as a RFC? (If no, please respond to the list with issues.) http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ Have you read the architecture draft? Do you think it is ready to be published as a RFC? (Ditto.) -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sat Jun 7 16:47:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F951A025E for ; Sat, 7 Jun 2014 16:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IROrykETUWpf for ; Sat, 7 Jun 2014 16:47:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E2C1A026C for ; Sat, 7 Jun 2014 16:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1402184829; x=1403394429; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xuVAH75Qm9KVeyheJkUSLTKQqe6QcgDLOhF+8+Re5B0=; b=KJV6Ol/JZTkGgbTYUM+jhbwecD4M/yxNkjPE/L620H7teWGOPl/IiefP ELGKpCfCFVAhcn0oQ0MhLfckp2cxY2zhlL+nmPPUQ9H+E41YpaLPkh+sb 6owberinOmqj5DVEmqTw2L+DYfCXHZx14XP3qBHlPOc/pm/PasGRiO8b6 o=; X-IronPort-AV: E=Sophos;i="4.98,996,1392163200"; d="scan'208";a="51153830" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 07 Jun 2014 23:47:09 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (rtp-jclarke-8915.cisco.com [10.117.46.166]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s57Nl8iu021048; Sat, 7 Jun 2014 23:47:08 GMT Message-ID: <5393A47C.8020703@cisco.com> Date: Sat, 07 Jun 2014 19:47:08 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> In-Reply-To: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/nb1WyUiXrIsgm1EbBB9CKsGydIk Cc: Carlos Pignataro , Gonzalo Salgueiro Subject: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 23:47:18 -0000 This update to i2rs-traceability addresses the comments made by Dean concerning the Actor ID as well as changes the ABNF model to a YANG model. The figure has been updated to convey some UML semantics similar to what was done in the RIB info model. As always, comments are appreciated. Joe === A new version of I-D, draft-clarke-i2rs-traceability-02.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Name: draft-clarke-i2rs-traceability Revision: 02 Title: Interface to the Routing System (I2RS) Traceability: Framework and Information Model Document date: 2014-06-07 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-02.txt Status: https://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/ Htmlized: http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-02 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Jun 7 17:48:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDED31A024A for ; Sat, 7 Jun 2014 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZZPTuYesyG7 for ; Sat, 7 Jun 2014 17:48:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE64A1A01F1 for ; Sat, 7 Jun 2014 17:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 78544240521; Sat, 7 Jun 2014 17:48:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9B03B2400DD; Sat, 7 Jun 2014 17:48:34 -0700 (PDT) Message-ID: <5393B2E4.8020909@joelhalpern.com> Date: Sat, 07 Jun 2014 20:48:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Marcus Clarke , "i2rs@ietf.org" References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> In-Reply-To: <5393A47C.8020703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YrKNV0ZT15jm6uOT06ocHymduMk Cc: Carlos Pignataro , Gonzalo Salgueiro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 00:48:44 -0000 The model in section 5.1, and the requiremenets in section 5.2 make good sense to me. Given that there already exist high volume log collection protocols, with their own modeling, it seems that the log itself ought to be the domain of such systems (syslog et. al.) rather than the domain of I2RS. Thus I find section 5.5 confusing. Yours, Joel On 6/7/14, 7:47 PM, Joe Marcus Clarke wrote: > This update to i2rs-traceability addresses the comments made by Dean > concerning the Actor ID as well as changes the ABNF model to a YANG > model. The figure has been updated to convey some UML semantics similar > to what was done in the RIB info model. > > As always, comments are appreciated. > > Joe > > === > > A new version of I-D, draft-clarke-i2rs-traceability-02.txt > has been successfully submitted by Joe Clarke and posted to the > IETF repository. > > Name: draft-clarke-i2rs-traceability > Revision: 02 > Title: Interface to the Routing System (I2RS) Traceability: > Framework and Information Model > Document date: 2014-06-07 > Group: Individual Submission > Pages: 19 > URL: > http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-02.txt > Status: https://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/ > Htmlized: > http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-02 > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From Yael.Frank@compass-eos.com Sun Jun 8 04:09:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08C01A039F for ; Sun, 8 Jun 2014 04:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRLo14lOOab6 for ; Sun, 8 Jun 2014 04:09:37 -0700 (PDT) Received: from email.compass-eos.com (unknown [91.212.114.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D0D1A039B for ; Sun, 8 Jun 2014 04:09:36 -0700 (PDT) Received: from CMP-EX-DB01.cmpsys.com ([fe80::5d57:7842:870:967a]) by CMP-EX-CAS2.cmpsys.com ([::1]) with mapi id 14.02.0387.000; Sun, 8 Jun 2014 14:07:04 +0300 From: Yael Frank Dayan To: "i2rs@ietf.org" , "draft-ietf-i2rs-rib-info-model@tools.ietf.org" Thread-Topic: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-03.txt Thread-Index: AQHPedrPBZAS5r2nikmiW3yNEdcSU5tUwx2AgBJV0mA= Date: Sun, 8 Jun 2014 11:08:38 +0000 Message-ID: <70A1AFC4870DD34181EF6783D7DAF6917FD174FC@cmp-ex-db01.cmpsys.com> References: <20140527183808.6487.38364.idtracker@ietfa.amsl.com> <538506C5.3050604@joelhalpern.com> In-Reply-To: <538506C5.3050604@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.0.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/sf834AZs38TY6h10L7nk7JsPp0o X-Mailman-Approved-At: Sun, 08 Jun 2014 19:05:38 -0700 Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 13:42:44 -0000 Nitin, In section 2.3 it says: " A route is essentially a match condition and an action following the match. The match condition specifies the kind of route (IPv4, MPLS, etc.) and the set of fields to match on. Figure 3 represents the overall contents of a route ... This document specifies the following ma= tch types: o IPv4: Match on destination IP address in the IPv4 header o IPv6: Match on destination IP address in the IPv6 header=20 ... o IP multicast: Match on (S, G) or (*, G), where S and G are IP prefixes" However, section 6 defines: " ::=3D ( | | | | ) ::=3D | | | | ::=3D ( | | ( )) ... ::=3D ( | | ( )) " The terms using source address are probably meant for multicast, if this is= the intention it should be changed to match the definition: (S, G) or (*, G). Thanks, Yael=20 On 5/27/14, 2:38 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Interface to the Routing System Workin= g Group of the IETF. > > Title : Routing Information Base Info Model > Authors : Nitin Bahadur > Ron Folkes > Sriganesh Kini > Jan Medved > Filename : draft-ietf-i2rs-rib-info-model-03.txt > Pages : 24 > Date : 2014-05-27 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 9 03:35:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A51A006D for ; Mon, 9 Jun 2014 03:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DPiXbStZG_e for ; Mon, 9 Jun 2014 03:35:44 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929011A0064 for ; Mon, 9 Jun 2014 03:35:44 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:60191 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WtwvX-0005C5-7D; Mon, 09 Jun 2014 10:35:43 +0000 From: "Russ White" To: "'Anton Smith'" , References: <8CCC03580905AE4F98B89B784F5AE85A1A2A19A2@ESESSMB305.ericsson.se> In-Reply-To: <8CCC03580905AE4F98B89B784F5AE85A1A2A19A2@ESESSMB305.ericsson.se> Date: Mon, 9 Jun 2014 06:35:35 -0400 Message-ID: <031201cf83ce$8cfa4fb0$a6eeef10$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJpIxzj/6dCsz/N+rzdPBAPhl2vX5o1VkNQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ONpNSmSk5AdiH244cBsLr-jgKPY Subject: Re: [i2rs] Question and new usecase X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 10:35:45 -0000 > I have a question and a potential usecase. I was reading the charter today > and it mentioned some fairly specific usecases. I've been thinking of another > fairly specific class of usecase that I had hoped I2RS would deliver. If this new use case would add some specific new capability to the protocol or requirement set, then it might be interesting. From what you've described so far, I don't know if it would -- it seems like the requirements in what you describe would already be covered in one of the other use cases already put in draft format. If you think there are unique requirements your use case would bring to the table, ping some folks off list (probably Sue and I). :-) Russ From nobody Mon Jun 9 07:42:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545131A01DC for ; Mon, 9 Jun 2014 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rlN6XEvADYf for ; Mon, 9 Jun 2014 07:42:41 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F6A1A01D9 for ; Mon, 9 Jun 2014 07:42:41 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so3909927igd.14 for ; Mon, 09 Jun 2014 07:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=QmVD0qbpPiCW84ld05UMcUxFR5bFZrhOYxfQ06RRuuo=; b=QXonOhgBWj1bMt9IP479iEQ5FdVpR50VTldWIfypnhstg8f6g7vZ151ADpcPR65NKd PDeaIv+pGszsOB8vs5mDW7KoeryNgbOepWOWJ2w08UJOLcZ1fIem1i+2cUorvk0gOXX0 IKWS2ma9DSYWoWn6xy0TNltow/ZE/x9McDx9zGQ2wZ3OlJfVFui8u60My9QpzwQRg21a rGzp2VTuTq5ozMAJS7SGnLZmlZswJi/rSZgA2qpaOctOU9KK+IbC9L2zHWAAzDfA8Wlh ApUSKUGruWTOV9RCMuJuiL8DMULQb7NwklIULrYcEUmVQ9YcWJtdu573HHj1NNuXbSig 6KCw== MIME-Version: 1.0 X-Received: by 10.50.79.137 with SMTP id j9mr33545321igx.29.1402324960442; Mon, 09 Jun 2014 07:42:40 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 9 Jun 2014 07:42:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 16:42:40 +0200 X-Google-Sender-Auth: CJunfEJzEeaOglIbmRE6VF1HExU Message-ID: From: Robert Raszuk To: Edward Crabbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lmEDje_eAEuR5PriVPYRTzXev5E Cc: "i2rs@ietf.org" Subject: Re: [i2rs] working group last call: draft-atlas-i2rs-problem-statement X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:42:42 -0000 Regarding draft-ietf-i2rs-problem-statement-01 I have few minor comments: 1. Figure 1 sort of implies that I2RS client to I2RS Agent is always a point to point session. Is this intentional or accidental ? I can imagine bunch of I2RS clients feeding agends with pieces of required information which only putted together makes sense - is this out of scope as too complex ? Or is this what is called multi-headed control ? If so It's definition is not that clear. Does "multi-headed" just means number of independent clients feeding in async mode complete information chunks or is that I2RS agent can collect pieces of info for a given information and compiles the product itself. My question is for the latter mode. 2. > In addition to interfaces to the RIB layer, Are we always talking about global RIB or also RIB on line cards on distributed systems. While former is much easier the latter may help with scalability issues. 3. Pls change [I-D.gredler-idr-ls-distribution]) to draft-ietf-idr-ls-distribu= tion 4. > For applications to have a feedback loop that includes awareness of > the relevant traffic, an application must be able to request the > measurement and timely, scalable reporting of data." Frankly I am not sure if I like and support the idea of mixing control plane and data plane reporting netflow like data on the same I2RS channel/session. Not questioning the need .. just questioning the approach :) 5. > While a few of these (e.g. link up/down) may be available via > MIB Notifications today, the full range is not - nor is there the > standardized ability to set up the router to trigger different > actions upon an event=E2=80=99s occurrence so that a rapid reaction can b= e > accomplished. So I2RS will also define a router's policy language which will allow for setting via I2RS protocol conditional behavior upon specific network events ? Will it ever ship complete ? Will it require RIB redesign by some vendors which today may not have all opaque info there ? It's awsome goal and very attractive, but to me it means that this one is a bit separate effort which make take much much longer to agreed in IETF on then plain I2RS remote control idea. Thx, R. On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe wrote: > Hello all; > > Jeff and I would like to start the two week working group last call for > draft-atlas-i2rs-problem-statement. The document may be found here: > > http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 > > The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to > post the new version of the draft until the wglc is closed and the > comments are resolved. > > This working group last call will end on Friday, 5/30/14 > > best, > -ed > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jun 9 08:19:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A108E1A020B for ; Mon, 9 Jun 2014 08:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKH544FM0HEb for ; Mon, 9 Jun 2014 08:19:48 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CD71A01E8 for ; Mon, 9 Jun 2014 08:19:48 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so3952173igb.8 for ; Mon, 09 Jun 2014 08:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4yK7cqb3l6La4pAQp88J0Z7y2twUmM3shsbXJJ9RPvc=; b=0lWE/LcbP62X899g3JWo6DaaJ5w9szlg6LwDg2H06FmMgGTfrCsgwNo/mYB81yBVmn HzDRN8rQG7O8K1B7GhkPOv8pE3F89yMpiwRZCwkLb3rlqOp8CJkEe+5T96V7ubtHGV6f VCibQnAMXpBAwFkPib/DqVuCAD6uNn2RccKYZSImleMDW1CsV7AGgdEKdYaCtMm+tgVD CI+Hl5tVyKqt4gHOIGvBykJzE81PfG3SSRYGEBuJ+M9D2cvkD7FKFR1D6CKoVtjiakUl rOU94FFKcxijmu1SCjeW8IBn/hNrzqoM2Wb7z6Va62XT3V1u45fJHTu7P7tMhLsRq+Fv qiTw== MIME-Version: 1.0 X-Received: by 10.43.160.137 with SMTP id mc9mr30565173icc.4.1402327188226; Mon, 09 Jun 2014 08:19:48 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Mon, 9 Jun 2014 08:19:48 -0700 (PDT) In-Reply-To: <20140605202938.GP13606@pfrc> References: <20140605202938.GP13606@pfrc> Date: Mon, 9 Jun 2014 17:19:48 +0200 X-Google-Sender-Auth: dwnys6ldZhjO3swJJ0wZ2DPTnCU Message-ID: From: Robert Raszuk To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pyT8PR8xO-9oROifNSCI__TCCFw Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:19:50 -0000 Hi Jeff, Late but still few comments on the draft-ietf-i2rs-architecture-03: 1. > This I2RS architecture recognizes that the routing > system and a router=E2=80=99s OS provide useful mechanisms > that applications could harness to accomplish > application-level goals. What happens if multiple applications have mutually exclusive needs ? It is not really an error as applications and clients by design are independent. Where is the arbitration to take place ? In I2RS Client, in I2RS Agent or in global router's RIB ? 2. Fundamental question ... Is the I2RS protocol communication to take place in-band, out-of-band or both of the data plane ? If we are including in-band I presume there is serious risk that the information carried within the protocol may cause in-band channels to stop working hence the device becomes unreachable (at least for the I2RS system). It may be good for architecture document to be able to comment on it. 3. > Anticipated I2RS Services Is OEM hidden within the "Dynamic Data & Statistics" or is it just plain missing ? ;) Many thx, R. On Thu, Jun 5, 2014 at 10:29 PM, Jeffrey Haas wrote: > Working Group, > > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. > > While we all realize that there's a bit of exhaustion going on with regar= d > to these drafts, they are a bit of process we simply must get done in ord= er > to fully move forward with our agenda of putting together data models. > > We are *NOT* going to hold that work up further - it is clear that there = is > consenus to start making that progress. > > To assist us with putting this work behind us, please respond to the > following questions: > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > Do you think it is ready to be published as a RFC? > (Ditto.) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 9 08:30:01 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A31A01E8 for ; Mon, 9 Jun 2014 08:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMFWmnIeAMVV for ; Mon, 9 Jun 2014 08:29:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FE91A01B5 for ; Mon, 9 Jun 2014 08:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3367; q=dns/txt; s=iport; t=1402327791; x=1403537391; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HYRbgiQJiKyMIOF7EDAA7CPBPLPgc5J6R6X9PdTqHoI=; b=KY4Yx0S3hppBaxoxfL9B8KjFOw+Ckvy4M6oHygdfV8ggPZRQVuIzm3sz Jyi/gIhh7I8270Cx5rxPgZy+GyBkwgO+zFmYWjX8rbhoLrIzbqOq7JUkS 4glAO5ojWRz/ZHfJmyKdCeLHDmnyaf+LSh4yPzT3jaC+CBf+eY2A+rN14 g=; X-IronPort-AV: E=Sophos;i="4.98,1002,1392163200"; d="scan'208";a="51438009" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 09 Jun 2014 15:29:51 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-54-36.cisco.com [10.150.54.36]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s59FTouK012989; Mon, 9 Jun 2014 15:29:50 GMT Message-ID: <5395D2EC.2090409@cisco.com> Date: Mon, 09 Jun 2014 11:29:48 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joel M. Halpern" , "i2rs@ietf.org" References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> In-Reply-To: <5393B2E4.8020909@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rudBfdvVZFrV3wzemOa5aN4tjKA Cc: Carlos Pignataro , Gonzalo Salgueiro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:29:56 -0000 On 6/7/14, 8:48 PM, Joel M. Halpern wrote: > The model in section 5.1, and the requiremenets in section 5.2 make good > sense to me. > > Given that there already exist high volume log collection protocols, > with their own modeling, it seems that the log itself ought to be the > domain of such systems (syslog et. al.) rather than the domain of I2RS. > Thus I find section 5.5 confusing. Thanks for the read-through, Joel. The reason we wanted to bring this up in I2RS is that many times new protocols are built without intrinsic traceability. This results in implementors choosing their own ways to implement debugging, logging, etc. Coming from a support background, we wanted to try and chance that with I2RS. Thus, section 5.5 is an attempt to model the important bits of the log so that the diagnostics one gets from I2RS are complete. The specific on-the-wire formats (syslog, NETCONF notifications, SNMP notifications, etc.) would certainly be left to those domains. But the fields that must be logged and what those fields should look like seems to fit squarely in the domain or I2RS. Joe > > Yours, > Joel > > On 6/7/14, 7:47 PM, Joe Marcus Clarke wrote: >> This update to i2rs-traceability addresses the comments made by Dean >> concerning the Actor ID as well as changes the ABNF model to a YANG >> model. The figure has been updated to convey some UML semantics similar >> to what was done in the RIB info model. >> >> As always, comments are appreciated. >> >> Joe >> >> === >> >> A new version of I-D, draft-clarke-i2rs-traceability-02.txt >> has been successfully submitted by Joe Clarke and posted to the >> IETF repository. >> >> Name: draft-clarke-i2rs-traceability >> Revision: 02 >> Title: Interface to the Routing System (I2RS) Traceability: >> Framework and Information Model >> Document date: 2014-06-07 >> Group: Individual Submission >> Pages: 19 >> URL: >> http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-02.txt >> Status: https://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/ >> Htmlized: >> http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-02 >> >> Abstract: >> This document describes a framework for traceability in the Interface >> to the Routing System (I2RS) and information model for that >> framework. It specifies the motivation, requirements, use cases, and >> defines an information model for recording interactions between >> elements implementing the I2RS protocol. This framework provides a >> consistent tracing interface for components implementing the I2RS >> architecture to record what was done, by which component, and when. >> It aims to improve the management of I2RS implementations, and can be >> used for troubleshooting, auditing, forensics, and accounting >> purposes. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> From nobody Mon Jun 9 08:55:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF99A1A025B for ; Mon, 9 Jun 2014 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf49NjS1LNSC for ; Mon, 9 Jun 2014 08:54:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0612E1A021B for ; Mon, 9 Jun 2014 08:54:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9571824034A; Mon, 9 Jun 2014 08:54:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3BD6324073D; Mon, 9 Jun 2014 08:54:46 -0700 (PDT) Message-ID: <5395D8BE.30006@joelhalpern.com> Date: Mon, 09 Jun 2014 11:54:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Marcus Clarke , "i2rs@ietf.org" References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> In-Reply-To: <5395D2EC.2090409@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cRuH4F1BV8wpywUVc0u3V0fEnRs Cc: Carlos Pignataro , Gonzalo Salgueiro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:55:01 -0000 I agree that describing clearly the information to be logged is very important. I not not think it takes either an ABNF or a YANG description to do that. Just a list of: The following events are to be logged; The following information is to be included in log entries. You could include a note that the internal format of the log entry is implementation dependent and the reporting format will depend upon the protocol being used to report the log. As written I think it will cause many readers to leap to conclusions you do not intend. Yours, Joel On 6/9/14, 11:29 AM, Joe Marcus Clarke wrote: > On 6/7/14, 8:48 PM, Joel M. Halpern wrote: >> The model in section 5.1, and the requiremenets in section 5.2 make good >> sense to me. >> >> Given that there already exist high volume log collection protocols, >> with their own modeling, it seems that the log itself ought to be the >> domain of such systems (syslog et. al.) rather than the domain of I2RS. >> Thus I find section 5.5 confusing. > > Thanks for the read-through, Joel. The reason we wanted to bring this > up in I2RS is that many times new protocols are built without intrinsic > traceability. This results in implementors choosing their own ways to > implement debugging, logging, etc. Coming from a support background, we > wanted to try and chance that with I2RS. > > Thus, section 5.5 is an attempt to model the important bits of the log > so that the diagnostics one gets from I2RS are complete. The specific > on-the-wire formats (syslog, NETCONF notifications, SNMP notifications, > etc.) would certainly be left to those domains. But the fields that > must be logged and what those fields should look like seems to fit > squarely in the domain or I2RS. > > Joe > >> >> Yours, >> Joel >> >> On 6/7/14, 7:47 PM, Joe Marcus Clarke wrote: >>> This update to i2rs-traceability addresses the comments made by Dean >>> concerning the Actor ID as well as changes the ABNF model to a YANG >>> model. The figure has been updated to convey some UML semantics similar >>> to what was done in the RIB info model. >>> >>> As always, comments are appreciated. >>> >>> Joe >>> >>> === >>> >>> A new version of I-D, draft-clarke-i2rs-traceability-02.txt >>> has been successfully submitted by Joe Clarke and posted to the >>> IETF repository. >>> >>> Name: draft-clarke-i2rs-traceability >>> Revision: 02 >>> Title: Interface to the Routing System (I2RS) Traceability: >>> Framework and Information Model >>> Document date: 2014-06-07 >>> Group: Individual Submission >>> Pages: 19 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-02.txt >>> >>> Status: https://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-02 >>> >>> Abstract: >>> This document describes a framework for traceability in the >>> Interface >>> to the Routing System (I2RS) and information model for that >>> framework. It specifies the motivation, requirements, use cases, >>> and >>> defines an information model for recording interactions between >>> elements implementing the I2RS protocol. This framework provides a >>> consistent tracing interface for components implementing the I2RS >>> architecture to record what was done, by which component, and when. >>> It aims to improve the management of I2RS implementations, and >>> can be >>> used for troubleshooting, auditing, forensics, and accounting >>> purposes. >>> >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> > > From nobody Mon Jun 9 10:20:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB41A01EF for ; Mon, 9 Jun 2014 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIcrOtztEQKW for ; Mon, 9 Jun 2014 10:20:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7801A01AC for ; Mon, 9 Jun 2014 10:20:00 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.98,1003,1392181200"; d="scan'208";a="344787781" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Jun 2014 13:19:44 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 9 Jun 2014 13:20:00 -0400 From: "George, Wes" To: Jeffrey Haas , "i2rs@ietf.org" Date: Mon, 9 Jun 2014 13:19:58 -0400 Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: Ac+EBwrY7CaNkNt+RpqQ1hJTFUxWVw== Message-ID: References: <20140605202938.GP13606@pfrc> In-Reply-To: <20140605202938.GP13606@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lFK0JsSsoaQMGN3Fa95V_s8UawI Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:20:02 -0000 Pg0KPlRvIGFzc2lzdCB1cyB3aXRoIHB1dHRpbmcgdGhpcyB3b3JrIGJlaGluZCB1cywgcGxlYXNl IHJlc3BvbmQgdG8gdGhlDQo+Zm9sbG93aW5nIHF1ZXN0aW9uczoNCj4NCj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wcm9ibGVtLXN0YXRlbWVudC8NCj5I YXZlIHlvdSByZWFkIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdD8geWVzDQo+RG8geW91IHRo aW5rIGl0IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCBhcyBhIFJGQz8NCg0KWWVzLCBidXQgd2l0 aCB0d28gcmVsYXRpdmVseSBtaW5vciBjb21tZW50czoNClNlY3Rpb24gMjogSXQgd291bGQgYmUg dXNlZnVsIHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NlZCBkYXRhDQptb2RlbC4g SSByZWFsaXplIHRoZXJl4oCZcyBhIHNlcGFyYXRlIGRyYWZ0IGZvciBkYXRhIG1vZGVsLCBidXQg c2luY2UgdGhpcw0KaXMgdGhlIHByaW1hcnkgZHJhZnQgdGhhdCBvbmUgc2hvdWxkIHJlYWQgYmVm b3JlIGRpdmluZyBpbnRvIHRoZSBnb3J5DQpkZXRhaWxzLCBzb21lIGNsYXJpdHkgd291bGQgYmUg aGVscGZ1bC4gVGhlIGJpZyBkaWFncmFtIGluY2x1ZGVzIGEgbG90IG9mDQppbnRlcmZhY2VzIGFu ZCBvYmplY3RzIHRoYXQgYXJlICJvdXQgb2Ygc2NvcGUgZm9yIEkyUlMiLCBidXQgaXTigJlzIHVu Y2xlYXINCnRvIG1lIHdoZXRoZXIgeW91IGFsc28gbWVhbiB0aGF0IGFsbCBvZiB0aG9zZSB3b3Vs ZCBiZSBvdXQgb2Ygc2NvcGUgd2hlbg0KaXQgY29tZXMgdG8gdGhlIGRhdGEgbW9kZWwsIG9yIGlm IHlvdSBhY3R1YWxseSBtZWFuIHRoYXQgdGhleSBhcmUgc2ltcGx5DQpvdXQgb2Ygc2NvcGUgd2hl biByZWZlcnJpbmcgdG8gd2hpY2ggaW50ZXJmYWNlIHdl4oCZcmUgdHJ5aW5nIHRvIGJ1aWxkDQpi ZXR3ZWVuIHdoaWNoIG9iamVjdHMuIEkgdGhpbmsgaXTigJlzIHRoZSBsYXR0ZXIsIHNpbmNlIHlv dSBuZWVkIHRvDQpyZXByZXNlbnQgYSBtdWNoIGxhcmdlciByYW5nZSBvZiB0aGluZ3MgaW4gdGhl IGRhdGEgbW9kZWwgdGhhbiBpbiB0aGUNCmludGVyZmFjZSwgYnV0IHlvdSBtYXkgd2FudCB0byBi ZSBtb3JlIGV4cGxpY2l0IGluIHRoZSBsYXR0ZXIgaGFsZiBvZg0Kc2VjdGlvbiAyLCBhcyB3ZWxs IGFzIHJlcGxhY2luZyDigJxJMlJTIiB3aXRoIHNvbWV0aGluZyBtb3JlIGRlc2NyaXB0aXZlIGlu DQp0aGUgZGlhZ3JhbSB0byBhdm9pZCBuYW1pbmcgY29uZnVzaW9uIHNpbmNlIOKAnEkyUlPigJ0g Y2FuIG1lYW4gSUVURiBXRy9lZmZvcnQNCk9SIHRoZSBhY3R1YWwgaW50ZXJmYWNlIHRvIHRoZSBy b3V0aW5nIHN5c3RlbSBhbmQgcmVsYXRlZCBwcm90b2NvbC4NCg0KU2luY2Ugc2VjdGlvbiAzIGRp c2N1c3NlcyBNSUJzIGFuZCBjb25maWd1cmF0aW9uLCBhIHJlZmVyZW5jZSB0byB0aGUNCnJlY2Vu dCBzdGF0ZW1lbnQgYWJvdXQgd3JpdGVhYmxlIE1JQnMgbWlnaHQgYWxzbyBiZSBhcHByb3ByaWF0 ZSBoZXJlIGFzDQpvbmUgbW9yZSBib2xzdGVyIHRvIHRoZSBuZWVkIGZvciBhIGRpZmZlcmVudCBw cm90b2NvbCB0byBkbyB0aGlzIHdvcmsuDQoNCj4NCj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUvDQo+SGF2ZSB5b3UgcmVhZCB0aGUg YXJjaGl0ZWN0dXJlIGRyYWZ0PyB5ZXMNCj5EbyB5b3UgdGhpbmsgaXQgaXMgcmVhZHkgdG8gYmUg cHVibGlzaGVkIGFzIGEgUkZDPw0KWWVzLCBhZ2FpbiB3aXRoIGEgY291cGxlIG9mIGNvbW1lbnRz Og0KDQoxLjIgLSBhcmUgd2UgY29uc2lkZXJpbmcgZmxvdyBkYXRhIGFzIGEgcGFydCBvZiBkeW5h bWljIHN5c3RlbSBzdGF0ZSBhbmQNCmF2YWlsYWJsZSB0byBJMlJTLCBvciBub3Q/IFdvdWxkIGJl IHVzZWZ1bCB0byBjbGFyaWZ5LCBlc3BlY2lhbGx5IHNpbmNlDQphdmFpbGFiaWxpdHkgb2YgZmxv dyBkYXRhIGlzIG9mdGVuIGxpbWl0ZWQgKG5vdCB0eXBpY2FsbHkgc3RvcmVkIGluIGxhcmdlDQph bW91bnRzIG9uLWJveCksIGFuZCBzaW1pbGFybHkgdG8gdGhlIG90aGVyIHN0YXRzIG1lbnRpb25l ZCwgbWF5IGJlDQphdmFpbGFibGUgdmlhIG90aGVyIHNvdXJjZXMuDQoNCg0KNi4yIC0gSSByZWNv bW1lbmQgdGhhdCB5b3UgZXhwbGljaXRseSBjYWxsIG91dCB0aGUgbmVlZCB0byBiZSBhYmxlIHRv DQpyZXZpZXcgKGUuZy4gdmlhIENMSSkgdGhlIGNoYW5nZXMgbWFkZSBieSB0aGUgSTJSUyBhZ2Vu dCBhbmQgaXRzIHN0YXRlDQpkYXRhIHdpdGhvdXQgYSBkZXBlbmRlbmN5IG9uIHRoZSBjbGllbnQg aXRzZWxmLiBUaGUgc2ltcGxlc3QNCmltcGxlbWVudGF0aW9uIGNhc2UgZm9yIG1ha2luZyBvbmJv YXJkIENMSSBhbmQgSTJSUyBhZ2VudHMgcGxheSB0b2dldGhlcg0KaXMgdGhhdCB0aGUgcm91dGVy IENMSSBpcyBzaW1wbHkgYW5vdGhlciBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgdGhlIEkyUlMNCmFn ZW50IGluIG9yZGVyIHRvIHJlcHJlc2VudCB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uLCBidXQg SSB0aGluayB0aGF0DQpkZXBlbmRlbmN5IG1pZ2h0IGJlIHByb2JsZW1hdGljLiBJIHRoaW5rIHdo YXQgaXMgbmVlZGVkIGhlcmUgaXMgYSB3YXkgdG8NCnZlcmlmeSB3aGF0IGlzIGdvaW5nIG9uIHdp dGggdGhlIEkyUlMgYWdlbnQgdmlhIHNlcGFyYXRlIG1lYW5zLCBzdWNoIHRoYXQNCmlmIHRoZSBJ MlJTIGFnZW50IGdvZXMgaW5zYW5lLCBJIGNhbiB1c2UgYW5vdGhlciBtZXRob2QgdG8gZmlndXJl IG91dCB3aGF0DQppdHMgcGFydGljdWxhciBwc3ljaG9zaXMgbWlnaHQgYmUuIEl0IG1heSBub3Qg YmUgcHJhY3RpY2FsIHRvIGFzc3VtZSB0aGF0DQptYWtpbmcgdGhlIG9uYm9hcmQgQ0xJIGEgY2xp ZW50IG9mIHRoZSBzYW1lIGFnZW50IHdpbGwgcHJvZHVjZSB2YWxpZA0KcmVzdWx0cy4gaS5lLiBJ IG1heSBub3QgZ2V0IGEgdXNlZnVsIGFuc3dlciBpZiBJIHF1ZXJ5IHRoZSBJMlJTIGFnZW50DQri gJx0ZWxsIG1lIHdoeSB5b3XigJlyZSBpbnNhbmXigJ0gYnV0IEkgbWlnaHQgYmUgYWJsZSB0byBm aWd1cmUgb3V0IHdoYXQgdGhlDQphZ2VudCB3YXMgZG9pbmcgd2hlbiBpdCB3ZW50IGluc2FuZSBp ZiBJIGNhbiBnZXQgYWNjZXNzIHRvIHRoZSBpbmZvIGFib3V0DQp3aGF0IGFjdGlvbnMgaXQgdG9v ay93aGF0IGRhdGEgaXQgbWFuaXB1bGF0ZWQgb25jZSBpdCB3ZW50IGluc2FuZSwgb3IgbG9vaw0K ZGlyZWN0bHkgYXQgaXRzIHVuZGVybHlpbmcgc3RhdGUgZGF0YWJhc2Ugd2l0aG91dCBpdHMg4oCc aGVscCIuIEkgdGhpbmsgdGhpcw0KaXMgYSBwcmV0dHkgaW1wb3J0YW50IHRoaW5nIGZyb20gYSB0 cmFjZWFiaWxpdHkgYW5kIGZhaWx1cmUgbWFuYWdlbWVudA0KcGVyc3BlY3RpdmUuDQoNClRoYW5r cw0KDQpXZXMgR2VvcmdlDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Mon Jun 9 10:58:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B981A0280 for ; Mon, 9 Jun 2014 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra-xJjjTcMyu for ; Mon, 9 Jun 2014 10:58:50 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 569441A01C5 for ; Mon, 9 Jun 2014 10:58:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.189.161; From: "Susan Hares" To: "'Joe Marcus Clarke'" , "'Alia Atlas'" , "'Dean Bogdanovic'" References: <20140605202938.GP13606@pfrc> <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> <5391E36F.7060605@cisco.com> In-Reply-To: <5391E36F.7060605@cisco.com> Date: Mon, 9 Jun 2014 13:58:34 -0400 Message-ID: <001001cf840c$6f3cc000$4db64000$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw2WzTgNBoR3VxxqV/A44onIvVAAFC6bolAjvAC6wCJhzUypv5P1YA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/DJEGdxKm-zziRyIEUY2xOIOBJR4 Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 17:58:51 -0000 Joe: Yes, I did try to send you off-list the comments the "silent" comments. Next time I will send onlist. Thank you for resending the comments. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Marcus Clarke Sent: Friday, June 06, 2014 11:51 AM To: Alia Atlas; Dean Bogdanovic Cc: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) On 6/6/14, 10:10 AM, Alia Atlas wrote: > Dean, > > On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic > wrote: > > Jeff, > > Problem statement: suggested changes, several times, still waiting > for those to be addressed in the draft. As my comments are not > addressed, I don't think draft is ready for WGLC or RFC. > > > Just a reminder - I have the changes ready to go as discussed. We > were waiting on any other comments from the WGLC before updating the draft. > Given the paucity of such comments and the availability of integers, > I'll just submit it. I also had some comments on the last architecture draft. While some of them were silently addressed, there were a couple where I expected the authors to respond. I can resend the email if you missed it. It was a while ago. Joe > > Alia > > Architecture document: ready for WGLC, ready for RFC > > Dean > > On Jun 5, 2014, at 4:29 PM, Jeffrey Haas > wrote: > > > Working Group, > > > > The original deadline for comments on WGLC for the problem > statement and > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on > with regard > > to these drafts, they are a bit of process we simply must get > done in order > > to fully move forward with our agenda of putting together data > models. > > > > We are *NOT* going to hold that work up further - it is clear > that there is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 9 11:21:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDA91A0294 for ; Mon, 9 Jun 2014 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRvAXnmRFTxX for ; Mon, 9 Jun 2014 11:21:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B71A02A3 for ; Mon, 9 Jun 2014 11:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3836; q=dns/txt; s=iport; t=1402338067; x=1403547667; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=y7sr7vDQiuOS4KbaO3NCxFor7yiRU9qlp1J0dyXw3rA=; b=CDzPPDk+99VbQP5FvnVC3eH5Mc+d1Tc5VWJhzkVRi0Cl6claPd+ILzdm kDfeiGn0DVR9cQi1ERfMN64sFKrPfzRvld6TY0QqezmPMGcTDcl5/NsgE ycnpwKskcmsGyWKzKhxjPRoMbUhmlnl3+g0nqmF8G2NAGJvzS2ExG2cZX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4LAELxlVOtJV2U/2dsb2JhbABZgw1Sq0AFAZFUhzwBgRIWdYQDAQEBAwEBAQE1NgoBDAQLDgMBAwEBAQkWCAcJAwIBAgEVHwMGCAYBDAEFAgEBiDYIDctpF4VdiC0RAVAHBoQ7AQOWF4QKgUKSA4F8gVwhgTk X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208";a="331756859" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 09 Jun 2014 18:21:03 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-54-36.cisco.com [10.150.54.36]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s59IL2lH026537; Mon, 9 Jun 2014 18:21:02 GMT Message-ID: <5395FB0C.8050301@cisco.com> Date: Mon, 09 Jun 2014 14:21:00 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Susan Hares , "'Alia Atlas'" , "'Dean Bogdanovic'" References: <20140605202938.GP13606@pfrc> <10C65F38-1E4E-47FB-8344-DA1579635233@juniper.net> <5391E36F.7060605@cisco.com> <001001cf840c$6f3cc000$4db64000$@ndzh.com> In-Reply-To: <001001cf840c$6f3cc000$4db64000$@ndzh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lTkzZdCmVjLAfnT35acRBeorTjg Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 18:21:09 -0000 On 6/9/14, 1:58 PM, Susan Hares wrote: > Joe: > > Yes, I did try to send you off-list the comments the "silent" comments. > Next time I will send onlist. Thank you for resending the comments. Hmmm, sorry, then Susan. I don't think I saw your email. I have been traveling a lot lately, so maybe it just slipped through the cracks. Joe > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Marcus Clarke > Sent: Friday, June 06, 2014 11:51 AM > To: Alia Atlas; Dean Bogdanovic > Cc: Jeffrey Haas; i2rs@ietf.org > Subject: Re: [i2rs] Working Group Last Call on architecture and problem > statement drafts (redux) > > On 6/6/14, 10:10 AM, Alia Atlas wrote: >> Dean, >> >> On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic > > wrote: >> >> Jeff, >> >> Problem statement: suggested changes, several times, still waiting >> for those to be addressed in the draft. As my comments are not >> addressed, I don't think draft is ready for WGLC or RFC. >> >> >> Just a reminder - I have the changes ready to go as discussed. We >> were waiting on any other comments from the WGLC before updating the > draft. >> Given the paucity of such comments and the availability of integers, >> I'll just submit it. > > I also had some comments on the last architecture draft. While some of them > were silently addressed, there were a couple where I expected the authors to > respond. I can resend the email if you missed it. It was a while ago. > > Joe > >> >> Alia >> >> Architecture document: ready for WGLC, ready for RFC >> >> Dean >> >> On Jun 5, 2014, at 4:29 PM, Jeffrey Haas > > wrote: >> >> > Working Group, >> > >> > The original deadline for comments on WGLC for the problem >> statement and >> > architecture drafts of May 30 has passed with no comment > whatsoever. >> > >> > While we all realize that there's a bit of exhaustion going on >> with regard >> > to these drafts, they are a bit of process we simply must get >> done in order >> > to fully move forward with our agenda of putting together data >> models. >> > >> > We are *NOT* going to hold that work up further - it is clear >> that there is >> > consenus to start making that progress. >> > >> > To assist us with putting this work behind us, please respond to > the >> > following questions: >> > >> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ >> > Have you read the problem statement draft? >> > Do you think it is ready to be published as a RFC? >> > (If no, please respond to the list with issues.) >> > >> > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ >> > Have you read the architecture draft? >> > Do you think it is ready to be published as a RFC? >> > (Ditto.) >> > >> > -- Jeff >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 10 04:37:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8A1B27B8 for ; Tue, 10 Jun 2014 04:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caFSl2ZUR9uX for ; Tue, 10 Jun 2014 04:37:42 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385931A0080 for ; Tue, 10 Jun 2014 04:37:42 -0700 (PDT) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 10 Jun 2014 11:37:35 +0000 Message-ID: <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas , References: <20140605202938.GP13606@pfrc> Date: Tue, 10 Jun 2014 12:12:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA002.eurprd07.prod.outlook.com (10.242.77.170) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0238AEEDB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(377454003)(51704005)(13464003)(102836001)(81342001)(85852003)(92566001)(44736004)(23756003)(101416001)(86362001)(61296002)(33646001)(81686999)(104166001)(21056001)(64706001)(20776003)(47776003)(15202345003)(87976001)(93916002)(42186004)(74662001)(76482001)(74502001)(77156001)(46102001)(84392001)(50226001)(77982001)(76176999)(87286001)(62236002)(81816999)(89996001)(80022001)(4396001)(83072002)(66066001)(14496001)(19580395003)(31966008)(92726001)(83322001)(99396002)(81542001)(19580405001)(15975445006)(88136002)(50986999)(44716002)(50466002)(62966002)(79102001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0310HT004.eurprd03.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wAA42dXarLJZi5-6XkbeUzjY3r4 Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 11:37:45 -0000 Architecture After reading this, I struggle to see the point of I2RS:-( As was said two months ago, "And the basic premise of I2RS is that there are requirements for the work that were not addressed properly by the existing configuration protocols. " but reading Architecture, the examples I see are ones that seem to fall within the remit of NETCONF (being config) as and when a suitable data model has been defined (e.g. for OSPF or BGP). Initially I had thought of several things that I2RS might do but these have been ruled out, either on the list or in this I-D, so I am left wondering what it is that I2RS will do that NETCONF potentially cannot. I do find the I-D quite hard to follow as the terminology seems inconsistent - the word 'state' is much used but it is unclear to me if the term can be given a single definition in this context; and even if it can, the word seems an unfortunate choice since the IETF Ops Area has given it a precise definition which is at odds with its use here. Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: Sent: Thursday, June 05, 2014 9:29 PM > Working Group, > > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. > > While we all realize that there's a bit of exhaustion going on with regard > to these drafts, they are a bit of process we simply must get done in order > to fully move forward with our agenda of putting together data models. > > We are *NOT* going to hold that work up further - it is clear that there is > consenus to start making that progress. > > To assist us with putting this work behind us, please respond to the > following questions: > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > Do you think it is ready to be published as a RFC? > (Ditto.) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 10 05:35:54 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7431A0085 for ; Tue, 10 Jun 2014 05:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff-zZU1Oz-RD for ; Tue, 10 Jun 2014 05:35:49 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DEA1A0084 for ; Tue, 10 Jun 2014 05:35:49 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 5abf6935.2ad167d2c940.2850097.00-2457.7947093.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 10 Jun 2014 12:35:49 +0000 (UTC) X-MXL-Hash: 5396fba50656d398-0bcf171e2afda92a75a144b24e2d28aa22765145 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id b9bf6935.0.2850028.00-2284.7946894.nbfkord-smmo05.seg.att.com (envelope-from ); Tue, 10 Jun 2014 12:35:41 +0000 (UTC) X-MXL-Hash: 5396fb9d48ce9302-83b76a3c8c233c9456fa5a3593119bfc2370b64c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5ACZc29003343; Tue, 10 Jun 2014 08:35:39 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5ACZSdo003161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2014 08:35:32 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 10 Jun 2014 12:35:10 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.251]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 08:35:10 -0400 From: "UTTARO, JAMES" To: "'t.petch'" , "'Jeffrey Haas'" , "'i2rs@ietf.org'" Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: AQHPhJzh7CaNkNt+RpqQ1hJTFUxWV5tqRxpw Date: Tue, 10 Jun 2014 12:35:09 +0000 Message-ID: References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> In-Reply-To: <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=BqQqN/r5 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=JRBvaEDbprEA:10 a=ofMgfj31e3cA:10 a=lB4lNuC3LbQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=Tg0nUI2_AAAA:8 a=NGf6-gD_g8lzyF5] X-AnalysisOut: [yyWMA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=3ODoesluOjEA] X-AnalysisOut: [:10 a=xDtYXBb9OYzhrMsV:21 a=HIqcauIuB6u8tXQx:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kwVFyfMWVtv7gFPy4aJvCusNJ2E Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 12:35:51 -0000 A document clearly stating the reqs would help me understand the need I2RS = is addressing. I would suggest writing the reqs info doc first Jim Uttaro -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch Sent: Tuesday, June 10, 2014 7:13 AM To: Jeffrey Haas; i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem sta= tement drafts (redux) Architecture After reading this, I struggle to see the point of I2RS:-( As was said two months ago, "And the basic premise of I2RS is that there are requirements for the work that were not addressed properly by the existing configuration protocols. " but reading Architecture, the examples I see are ones that seem to fall within the remit of NETCONF (being config) as and when a suitable data model has been defined (e.g. for OSPF or BGP). Initially I had thought of several things that I2RS might do but these have been ruled out, either on the list or in this I-D, so I am left wondering what it is that I2RS will do that NETCONF potentially cannot. I do find the I-D quite hard to follow as the terminology seems inconsistent - the word 'state' is much used but it is unclear to me if the term can be given a single definition in this context; and even if it can, the word seems an unfortunate choice since the IETF Ops Area has given it a precise definition which is at odds with its use here. Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: Sent: Thursday, June 05, 2014 9:29 PM > Working Group, > > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. > > While we all realize that there's a bit of exhaustion going on with regard > to these drafts, they are a bit of process we simply must get done in order > to fully move forward with our agenda of putting together data models. > > We are *NOT* going to hold that work up further - it is clear that there is > consenus to start making that progress. > > To assist us with putting this work behind us, please respond to the > following questions: > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > Do you think it is ready to be published as a RFC? > (Ditto.) > > -- Jeff > > _______________________________________________ > 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 nobody Tue Jun 10 06:41:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F54C1A011C for ; Tue, 10 Jun 2014 06:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp_IcATYWUDt for ; Tue, 10 Jun 2014 06:41:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6C1A010D for ; Tue, 10 Jun 2014 06:41:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B2CCDC22F; Tue, 10 Jun 2014 09:41:33 -0400 (EDT) Date: Tue, 10 Jun 2014 09:41:33 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140610134133.GA18608@pfrc> References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gQxbcNAXvw9v17MSkPEJL4bzOg0 Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 13:41:36 -0000 Tom, Thanks for the comments. On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote: > but reading Architecture, the examples I see are ones that seem to fall > within the remit of NETCONF (being config) as and when a suitable data > model has been defined (e.g. for OSPF or BGP). Initially I had thought > of several things that I2RS might do but these have been ruled out, It'd help if you listed the ones in question. Some of these things may be part of the work that is left currently out of scope to attempt to constrain the WG to things we have decided to get done first. (Don't bite off more than you can chew.) > either on the list or in this I-D, so I am left wondering what it is > that I2RS will do that NETCONF potentially cannot. The longer term question and netconf/yang continue to evolve (perhaps with impetus from our use cases) will generally be what work belongs in various groups. Yang modules are being proposed in the various working groups to cover protocol specific configuration and general management. This is great! The question then becomes, where does I2RS fit into that sort of picture. One of the reasons I think nailing down specific requirements (as Jim Uttaro raised in a separete response) has come down to the somewhat nebulous ability to interact with functionality that is either not quite a fit for standard config/query or interact with models that are one or more levels of abstraction above a given protocol component. The degenerate case - the ability to ephemerally inject static routing information - certainly seems like work that could be done outside of I2RS. Definitely so if it is decided that the ephemeral model is something that becomes core to netconf/restconf. (The question of how this is represented in the data model is the longer question.) Where the use cases start getting more substance are when we get somewhat more abstract: - An API to the traffic engineering state in a routing system. This is not just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. Which working group produces that model if done on a per-protocol basis? - A policy layer on top of BGP. That's perhaps in-scope for IDR or GROW. As you definitely know (:-) ) such a policy layer will interact with a lot of non-BGP components and potentially other databases. - A management layer to provision VPN instances (service layer routing). Does that work get done in IDR? MPLS? L2/L3VPN? And of course, there's the whole matter of how do you bring together contributors with expertise in modeling, operations and the mix of routing and other protocols in question and where do you do it? From the first BoF, it was clear there are a lot of people who want to work on the things that fall in these nebulous gaps between working groups. I2RS is here to be the big tent to let us gather people under to do that sort of work. Maintaining enough focus to make progress on a constrained number of items is the main early challenge. A survey of the use case documents should definitely suggest there's a lot more that people would like to work on. > I do find the I-D quite hard to follow as the terminology seems > inconsistent - the word 'state' is much used but it is unclear to me if > the term can be given a single definition in this context; and even if > it can, the word seems an unfortunate choice since the IETF Ops Area has > given it a precise definition which is at odds with its use here. Are there specific edits you would suggest to clarify the document? -- Jeff From nobody Tue Jun 10 08:29:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEB1B2825 for ; Tue, 10 Jun 2014 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9AftZOCFcBP for ; Tue, 10 Jun 2014 08:29:25 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3AD1A01C4 for ; Tue, 10 Jun 2014 08:29:23 -0700 (PDT) Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 10 Jun 2014 15:29:21 +0000 Message-ID: <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> Date: Tue, 10 Jun 2014 16:25:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB3PR07CA001.eurprd07.prod.outlook.com (10.242.134.41) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0238AEEDB0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(24454002)(51914003)(13464003)(189002)(199002)(377454003)(87286001)(77982001)(50226001)(84392001)(76176999)(62236002)(89996001)(81816999)(87976001)(93916002)(20776003)(47776003)(77156001)(46102001)(74662001)(42186004)(74502001)(76482001)(88136002)(50986999)(92726001)(81542001)(99396002)(83322001)(15975445006)(19580405001)(62966002)(79102001)(50466002)(44716002)(31966008)(80022001)(4396001)(83072002)(19580395003)(66066001)(85852003)(92566001)(81342001)(23756003)(44736004)(102836001)(81686999)(61296002)(33646001)(21056001)(64706001)(104166001)(86362001)(101416001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:DBXPRD0610HT005.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/K623etNJryCaddqxieVQQVhYpU8 Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 15:29:28 -0000 ---- Original Message ----- From: "Jeffrey Haas" To: "t.petch" Cc: "Jeffrey Haas" ; Sent: Tuesday, June 10, 2014 2:41 PM > Tom, > > Thanks for the comments. > > On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote: > > but reading Architecture, the examples I see are ones that seem to fall > > within the remit of NETCONF (being config) as and when a suitable data > > model has been defined (e.g. for OSPF or BGP). Initially I had thought > > of several things that I2RS might do but these have been ruled out, > > It'd help if you listed the ones in question. Some of these things may be > part of the work that is left currently out of scope to attempt to constrain > the WG to things we have decided to get done first. (Don't bite off more > than you can chew.) e.g. 6.2.3. Reversion "In all such cases, the state will revert to what it would have been without the I2RS; that state is generally whatever was specified via the CLI, NETCONF, SNMP, etc." which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it to Y then disappears so it reverts to X, for all values of 'it' - i.e. 'it' is what NETCONF would call config and so could have been set by NETCONF, no need for I2RS! 6.3. Interactions with Local Config "Changes may originate from either Local Config or from I2RS." Taking Local Config to be what NETCONF/YANG calls 'config' then again, nothing there it seems that C/N/S cannot do 6.4.2" o writing policy information such as interface attributes that are specific to the routing protocol or BGP policy that may indirectly manipulate attributes of routes carried in BGP. o writing routes or prefixes to be advertised via the protocol" I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the I-D goes on to say " direct modification of the link-state database MUST NOT be allowed" (which I have seen on the list w.r.t. the BGP RIB). or 8" The interaction of state installed via the I2RS and via a router's configuration needs to be clearly defined." which again implies that I2RS and C/N/S are writing to the same data. The examples of data that can be changed are few, such as "For example, the interaction with OSPF might include modifying the local routing element's link metrics, announcing a locally-attached prefix, .." which leaves me wondering, do you expect an OSPF YANG model to be unable to change a link metric:-) Whereever I look, I struggle to see what I2RS will write that C/N/S will not. If I2RS were aiming at a higher level, say specifying policy and have the system translate that into actual config changes I would understand that, but I do not see I2RS going that far, rather when I2RS says policy, I think it means changing a community (config again) or some such ie more of an implementation detail than a high level strategy. Tom Petch > > > either on the list or in this I-D, so I am left wondering what it is > > that I2RS will do that NETCONF potentially cannot. > > The longer term question and netconf/yang continue to evolve (perhaps with > impetus from our use cases) will generally be what work belongs in various > groups. Yang modules are being proposed in the various working groups to > cover protocol specific configuration and general management. This is > great! The question then becomes, where does I2RS fit into that sort of > picture. > > One of the reasons I think nailing down specific requirements (as Jim Uttaro > raised in a separete response) has come down to the somewhat nebulous > ability to interact with functionality that is either not quite a fit for > standard config/query or interact with models that are one or more levels of > abstraction above a given protocol component. > > The degenerate case - the ability to ephemerally inject static routing > information - certainly seems like work that could be done outside of I2RS. > Definitely so if it is decided that the ephemeral model is something that > becomes core to netconf/restconf. (The question of how this is represented > in the data model is the longer question.) > > Where the use cases start getting more substance are when we get somewhat > more abstract: > - An API to the traffic engineering state in a routing system. This is not > just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. Which working > group produces that model if done on a per-protocol basis? > - A policy layer on top of BGP. That's perhaps in-scope for IDR or GROW. > As you definitely know (:-) ) such a policy layer will interact with a lot > of non-BGP components and potentially other databases. > - A management layer to provision VPN instances (service layer routing). > Does that work get done in IDR? MPLS? L2/L3VPN? > > And of course, there's the whole matter of how do you bring together > contributors with expertise in modeling, operations and the mix of routing > and other protocols in question and where do you do it? From the first BoF, > it was clear there are a lot of people who want to work on the things that > fall in these nebulous gaps between working groups. > > I2RS is here to be the big tent to let us gather people under to do that > sort of work. Maintaining enough focus to make progress on a constrained > number of items is the main early challenge. A survey of the use case > documents should definitely suggest there's a lot more that people would > like to work on. > > > > I do find the I-D quite hard to follow as the terminology seems > > inconsistent - the word 'state' is much used but it is unclear to me if > > the term can be given a single definition in this context; and even if > > it can, the word seems an unfortunate choice since the IETF Ops Area has > > given it a precise definition which is at odds with its use here. > > Are there specific edits you would suggest to clarify the document? > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 10 09:30:57 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D481A01FB for ; Tue, 10 Jun 2014 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1f1MD0HYkiO for ; Tue, 10 Jun 2014 09:30:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E7BCA1A019B for ; Tue, 10 Jun 2014 09:30:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4D88CC1AA; Tue, 10 Jun 2014 12:30:52 -0400 (EDT) Date: Tue, 10 Jun 2014 12:30:52 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140610163052.GC20397@pfrc> References: <005c01cf802a$82407d80$86c17880$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005c01cf802a$82407d80$86c17880$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ogNv2RqruO7mrUdYNItKtGn9NUk Cc: 'Jeffrey Haas' , i2rs@ietf.org, Edward Crabbe Subject: Re: [i2rs] draft-white-i2rs-use-case-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:30:54 -0000 Sue, On Wed, Jun 04, 2014 at 03:23:47PM -0400, Susan Hares wrote: > I2RS WG: > > This use case draft has been changed to provide a numbered list of > requirements (per Jeff's request). The authors welcome feedback on these > changes. Thanks for doing this work. I think this enumerated break-out of the requirements strongly benefits the use case documents. As we work through the adoption cycle for the use case drafts, we'll likely copy these to the WG wiki to provide a summary across multiple documents. -- Jeff From nobody Tue Jun 10 09:52:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE31A019B for ; Tue, 10 Jun 2014 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPenK0dnKHsM for ; Tue, 10 Jun 2014 09:52:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4325D1A021F for ; Tue, 10 Jun 2014 09:52:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E7C48C1AA; Tue, 10 Jun 2014 12:52:25 -0400 (EDT) Date: Tue, 10 Jun 2014 12:52:25 -0400 From: Jeffrey Haas To: Robert Raszuk Message-ID: <20140610165225.GD20397@pfrc> References: <20140605202938.GP13606@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kSdFDjHXxAOky-IlTmd9NfE4sIc Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 16:52:27 -0000 Robert, On Mon, Jun 09, 2014 at 05:19:48PM +0200, Robert Raszuk wrote: > Hi Jeff, > > Late but still few comments on the draft-ietf-i2rs-architecture-03: Thanks for the review! > 1. > > This I2RS architecture recognizes that the routing > > system and a router???s OS provide useful mechanisms > > that applications could harness to accomplish > > application-level goals. > > What happens if multiple applications have mutually exclusive needs ? > It is not really an error as applications and clients by design are > independent. Where is the arbitration to take place ? In I2RS Client, > in I2RS Agent or in global router's RIB ? You should find this addressed in section 7.8. > 2. > Fundamental question ... > > Is the I2RS protocol communication to take place in-band, out-of-band > or both of the data plane ? If we are including in-band I presume > there is serious risk that the information carried within the protocol > may cause in-band channels to stop working hence the device becomes > unreachable (at least for the I2RS system). > > It may be good for architecture document to be able to comment on it. This seemed like one of those sort of things that were too obvious to state, but perhaps it's worth stating it. Authors, would you consider a few sentences in section 7 to cover this point? > 3. > > Anticipated I2RS Services > > Is OEM hidden within the "Dynamic Data & Statistics" or is it just > plain missing ? ;) The usual derivation of: Architecture -> Models + Protocol -> XXX -> Profit! is left as an exercise to the implementor. -- Jeff From nobody Tue Jun 10 10:22:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76501A00E9 for ; Tue, 10 Jun 2014 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osqrnZAJ5dHb for ; Tue, 10 Jun 2014 10:21:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EAA521A00D4 for ; Tue, 10 Jun 2014 10:21:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8C6F9C1AA; Tue, 10 Jun 2014 13:21:36 -0400 (EDT) Date: Tue, 10 Jun 2014 13:21:36 -0400 From: Jeffrey Haas To: "George, Wes" Message-ID: <20140610172136.GF20397@pfrc> References: <20140605202938.GP13606@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/x3JJHq5hS4qdy9lSw1SI2XLMAeA Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:21:38 -0000 Wes, Thanks for taking the time to supply your review. On Mon, Jun 09, 2014 at 01:19:58PM -0400, George, Wes wrote: > > > >To assist us with putting this work behind us, please respond to the > >following questions: > > > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > >Have you read the problem statement draft? yes > >Do you think it is ready to be published as a RFC? > > Yes, but with two relatively minor comments: > Section 2: It would be useful to clarify the scope of the proposed data > model. I realize there???s a separate draft for data model, but since this > is the primary draft that one should read before diving into the gory > details, some clarity would be helpful. The big diagram includes a lot of > interfaces and objects that are "out of scope for I2RS", but it???s unclear > to me whether you also mean that all of those would be out of scope when > it comes to the data model, or if you actually mean that they are simply > out of scope when referring to which interface we???re trying to build > between which objects. I think it???s the latter, since you need to > represent a much larger range of things in the data model than in the > interface, The way I've interpreted the diagram is basically: - I2RS defines the client and agent and the interactions (protocol) - The Agent, by necessity, interacts with system components in a black-box implementation-specific fashion. While I understand you're looking for "where does a data model box fit into the diagram", I'm not sure there's enough flexibility in the ASCII diagram to cover that. :-) If this were UML (which would balloon the diagram an order of magnitude), we'd have Interface lollipops all over the place and even then, that's probably the best we'd have for the high level description. > but you may want to be more explicit in the latter half of > section 2, as well as replacing ???I2RS" with something more descriptive in > the diagram to avoid naming confusion since ???I2RS??? can mean IETF WG/effort > OR the actual interface to the routing system and related protocol. I think it's meant to cover both cases: Within the scope of the WG effort and also protocol interactions. > Since section 3 discusses MIBs and configuration, a reference to the > recent statement about writeable MIBs might also be appropriate here as > one more bolster to the need for a different protocol to do this work. I agree. Authors, would you please add an appropriate reference? The URL is: http://www.ietf.org/iesg/statement/writable-mib-module.html > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > >Have you read the architecture draft? yes > >Do you think it is ready to be published as a RFC? > Yes, again with a couple of comments: > > 1.2 - are we considering flow data as a part of dynamic system state and > available to I2RS, or not? Would be useful to clarify, especially since > availability of flow data is often limited (not typically stored in large > amounts on-box), and similarly to the other stats mentioned, may be > available via other sources. Flow data isn't specifically in-scope to chartered work - today. When the Working Group was formed, the ADs realized that we could easily take on a massive amount of work and thus dilute the attention of the group. Today we have a charter with a limited number of cases: http://datatracker.ietf.org/wg/i2rs/charter/ Once we've gotten some traction on those cases, I suspect a re-chartering to cover such things can occur. > 6.2 - I recommend that you explicitly call out the need to be able to > review (e.g. via CLI) the changes made by the I2RS agent and its state > data without a dependency on the client itself. The simplest > implementation case for making onboard CLI and I2RS agents play together > is that the router CLI is simply another application that uses the I2RS > agent in order to represent the necessary information, but I think that > dependency might be problematic. I think what is needed here is a way to > verify what is going on with the I2RS agent via separate means, such that > if the I2RS agent goes insane, I can use another method to figure out what > its particular psychosis might be. It may not be practical to assume that > making the onboard CLI a client of the same agent will produce valid > results. i.e. I may not get a useful answer if I query the I2RS agent > ???tell me why you???re insane??? but I might be able to figure out what the > agent was doing when it went insane if I can get access to the info about > what actions it took/what data it manipulated once it went insane, or look > directly at its underlying state database without its ???help". I think this > is a pretty important thing from a traceability and failure management > perspective. [Please note: Discussion, not necessarily disagreement.] I think there's a few challenges with this. The biggest one is that no matter how carefully we try to word such an architectural requirement, we're going to end up making demands on implementations that either will be difficult to standardize or perhaps even impossible. For what it's worth, this isn't much uglier (and probably is a case that brought this to mind for you) than configuration state imposed by SNMP rather than the CLI. Configuration constructs in SNMP may not have good mappings to those in the CLI and vice versa. A trivial comparison might be if your I2RS agent was implemented by doing CLI translation, then it might be possible to do CLI comparisons. But if it's not, such comparison may be hard. Given the above, what would you suggest? I realize what we want is a way to troubleshoot, but I'm not sure there can be any specific recommendation that will span the architectures well enough to be standardized. -- JeffO From nobody Tue Jun 10 10:42:13 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B99F1A025E for ; Tue, 10 Jun 2014 10:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFyQYPAum8mC for ; Tue, 10 Jun 2014 10:41:58 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD781A025D for ; Tue, 10 Jun 2014 10:41:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A1920C1AA; Tue, 10 Jun 2014 13:41:57 -0400 (EDT) Date: Tue, 10 Jun 2014 13:41:57 -0400 From: Jeffrey Haas To: Joe Marcus Clarke Message-ID: <20140610174157.GG20397@pfrc> References: <20140605202938.GP13606@pfrc> <539233C5.2070700@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539233C5.2070700@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Afv09q2OHV8NORS8hLaZrEwYw0g Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 17:41:59 -0000 Joe, Thanks for re-sending the comments. A few clarifying points: On Fri, Jun 06, 2014 at 05:33:57PM -0400, Joe Marcus Clarke wrote: [...] > Section 7.1. This is mainly an editorial, but in looking back at > things like NETCONF over BEEP, one goal might be to make sure the > transport chosen is both operator and implementor friendly in terms > of ease of adoption. I think we're leaving this broadly open because "easy to implement" will vary depending on your environment. PHP webserver based environments may prefer BEEP environments if you have the right tool chain, as an example. I'd probably prefer to just do it in SSH if I were writing it. But I think we're all generally aware that the client environment and ecosystem and the agent environment and ecosystems may be wildly different. Clients will be highly variable since they're user applications. Agents in many cases will have to co-exist with routing applications that have (near) real-time constraints. This disparity of environments will likely lead to some constraints on what a given vendor may care to deploy. Given the above, do you still think 7.1 needs additional clarification? > Section 7.5. Would a supervisory application work in this case? This seems like an implementation detail - and potentially a common one. However, I'm not sure if it's one we'd want to mandate in the architecture. > I > suppose it could if it shared the same ID, but that wouldn't work > for multiple applications. Likely a better approach would be to > allow the Client to accept some meta-instructions at the beginning > of a session as to what to do if the app goes away (as you state in > paragraph 4). I believe such details will hopefully fall-out very early on in the gap analysis work that is ahead of us. Perhaps even something like "Graceful restart" type semantics, if appropriate. -- Jeff From nobody Tue Jun 10 11:08:09 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A11A024A for ; Tue, 10 Jun 2014 11:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhizGMcX9cyY for ; Tue, 10 Jun 2014 11:07:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B95F51A0249 for ; Tue, 10 Jun 2014 11:07:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 78F6BC1AA; Tue, 10 Jun 2014 14:07:47 -0400 (EDT) Date: Tue, 10 Jun 2014 14:07:47 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140610180747.GH20397@pfrc> References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rA92TVbd8RTPjvXnWPAeiX6zni4 Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 18:07:49 -0000 Tom, [retaining lots of content for context] On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: > ---- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: "Jeffrey Haas" ; > Sent: Tuesday, June 10, 2014 2:41 PM > > > Tom, > > > > Thanks for the comments. > > > > On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote: > > > but reading Architecture, the examples I see are ones that seem to > fall > > > within the remit of NETCONF (being config) as and when a suitable > data > > > model has been defined (e.g. for OSPF or BGP). Initially I had > thought > > > of several things that I2RS might do but these have been ruled out, > > > > It'd help if you listed the ones in question. Some of these things > may be > > part of the work that is left currently out of scope to attempt to > constrain > > the WG to things we have decided to get done first. (Don't bite off > more > > than you can chew.) > > e.g. > 6.2.3. Reversion "In all such cases, the state will revert to what it > would have been without the I2RS; that state is generally whatever was > specified via the CLI, NETCONF, SNMP, etc." > which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it > to Y then disappears so it reverts to X, for all values of 'it' - i.e. > 'it' is what NETCONF would call config and so could have been set by > NETCONF, no need for I2RS! > > 6.3. Interactions with Local Config "Changes may originate from either > Local Config or from I2RS." > Taking Local Config to be what NETCONF/YANG calls 'config' then again, > nothing there it seems that C/N/S cannot do This is much of what I had suggested about the semantics of introducing ephemeral config into netconf. Our requirement is that these things are ephemeral. (Although Tom Nadeau presents some nice cases as to why we may want the equivalent of "write running-config" to permit persistence.) At this point, overlapping ephemeral configuration isn't something that netconf supports. If you scan mail from the last month or so, you'll also see some back and forth between Juergen and Andy and I about how we go about representing such a thing in the yang model/modules. (And we never fully converged.) >From the config perspective, this ephemeral state wasn't something that I believe was part of the config semantics of netconf/yang; it's an I2RS requirement. Admittedly, once we have such a think then clearly applications other than I2RS can make use of it. :-) Choosing a solution space will be the next challenge we have: - Overlapping modules with i2rs context? - Parallel modules? - How to ensure maximum re-use of the yang modules for config in an i2rs context if they are determined to have heavy overlap? > > 6.4.2" o writing policy information such as interface attributes that > are > specific to the routing protocol or BGP policy that may indirectly > manipulate attributes of routes carried in BGP. > > o writing routes or prefixes to be advertised via the protocol" > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the > I-D goes on to say > " direct modification of the link-state database MUST NOT be allowed" > (which I have seen on the list w.r.t. the BGP RIB). > > or > > 8" The interaction of state installed via the I2RS and via a router's > configuration needs to be clearly defined." > which again implies that I2RS and C/N/S are writing to the same data. *Maybe.* In some cases, the overlap with config state will be quite obvious and your observation will strongly hold. In other cases, I think a better perspective is that I2RS injected state is effectively like that of another routing protocol. If you'd like to argue that BGP is effectively the same as C/N/S... well, if we're talking Flowspec I might agree. :-) > The examples of data that can be changed are few, such as > "For example, the interaction with OSPF might include modifying the > local routing element's link metrics, announcing a locally-attached > prefix, .." > which leaves me wondering, do you expect an OSPF YANG model to be unable > to change a link metric:-) Sure. In a highly dynamic fashion? With a fallback to a default config when the application is done? By comparison to some vendor specific features, it's somewhat the difference between a policy database (config) and the dynamic policy API that doesn't require a system reconfiguration event. If you want to point out that the relationship is strong and that the defining differences are shallow - you could very well be right in those contexts. Again, we don't expect I2RS work to supplant netconf/yang. We expect to leverage the work. > If I2RS were aiming at a higher level, say specifying policy and have > the system translate that into actual config changes I would understand > that, but I do not see I2RS going that far, rather when I2RS says > policy, I think it means changing a community (config again) or some > such ie more of an implementation detail than a high level strategy. I hesitate to frame it this way, but one example application is a form of SDN. The front end says "provision this VPN" to a data model for that purpose. The fact that it may go behind the covers via client->agent and eventually install ephemeral netconf state is an implementation detail. If you want to argue that such a higher level model is simply netconf, then perhaps we should de-charter and do all of the work in that group. I was, however, under the impression that work for various models was being pushed to be done in appropriate working groups. :-) -- Jeff From nobody Tue Jun 10 11:19:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DC1A00BD for ; Tue, 10 Jun 2014 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw3b_UcNAD_v for ; Tue, 10 Jun 2014 11:19:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6771A024F for ; Tue, 10 Jun 2014 11:19:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D118CC1AA; Tue, 10 Jun 2014 14:19:25 -0400 (EDT) Date: Tue, 10 Jun 2014 14:19:25 -0400 From: Jeffrey Haas To: Dean Bogdanovic Message-ID: <20140610181925.GI20397@pfrc> References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <005b01cf81c9$e8d8ddd0$ba8a9970$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FmAQKTOOY0-PO9sKJGu8QfKZOMk Cc: "" , Susan Hares , "" , "t.petch" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White , Susan Hares Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 18:19:27 -0000 On Sat, Jun 07, 2014 at 01:50:50AM +0000, Dean Bogdanovic wrote: > On Jun 6, 2014, at 4:57 PM, Susan Hares wrote: > > Thank you for the complete review of version 3. Great review! > > > > On readability, Jeff Haas suggest putting all the requirements in the front. > > Would that make it better? It's an easy switch (other than listening to > > Jeff say "I told you so"). > I don't like giving Jeff opportunity to use that sentence, but I'm in agreement with Jeff. Putting the requirement list upfront makes more sense and then you don't have to repeat the whole requirement, you can just list it. Married life has taught me that "I told you so" is something better to think than ever say. :-) As mentioned elsewhere on-list by me, I think we'll probably end up summarizing the various requirements to the wiki before we're done. As long as they're centralized in the document, I'm not highly concerned about where they live in that document as long as it contributes to easy reading. > > On REQ01/02 - (01) Read/write access versus (02) notification and REQ08/09 > > - (08) Write versus (09) read/notify status --- I agree these could be > > combined if the WG desires or split on read/write versus notification. Do > > you have any preference? > My preference would be read/notify and write. The reason is that read/notify are used for operational and analytic purposes and write is an action based on operational and analytical result. A model that may be worth considering is the MIN-ACCESS/MAX-ACCESS form used by SNMP. In particular, this lets you distinguish between contents that may be retrieved (read*) vs. only delivered in notifications (accessible-for-notify). -- Jeff From nobody Tue Jun 10 11:30:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371171A01EA for ; Tue, 10 Jun 2014 11:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw8CQlW-J4lZ for ; Tue, 10 Jun 2014 11:30:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69A1A00BD for ; Tue, 10 Jun 2014 11:30:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1460CC1AA; Tue, 10 Jun 2014 14:30:03 -0400 (EDT) Date: Tue, 10 Jun 2014 14:30:03 -0400 From: Jeffrey Haas To: Joe Marcus Clarke Message-ID: <20140610183003.GJ20397@pfrc> References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5395D2EC.2090409@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oxfGwyQrLSzNF1Lj5rcRhrGaB2A Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 18:30:04 -0000 On Mon, Jun 09, 2014 at 11:29:48AM -0400, Joe Marcus Clarke wrote: > Thus, section 5.5 is an attempt to model the important bits of the > log so that the diagnostics one gets from I2RS are complete. The > specific on-the-wire formats (syslog, NETCONF notifications, SNMP > notifications, etc.) would certainly be left to those domains. But > the fields that must be logged and what those fields should look > like seems to fit squarely in the domain or I2RS. FWIW, I find this version of the draft to be much improved. A few comments: - The yang module seems to have indentation issues. - The log-entry-id key should receive a bit of documentation as to whether sequence number gaps are permitted. While I sympathize with Joel's point that "there are other systems that provide logging, don't reinvent the wheel", being a relative newcomer to yang myself I have to wonder if any of those systems provide for this type of representation. The usual pain point one has with syslog like services is the issues of convoluted greps or other free-form parse to extract data from the stream and the lack of structure. Being able to know from day one that I can get at this type of data using an XPath slice is very attractive. If that kind of functionality is provided in other mechanisms, let's not reinvent the wheel. If it isn't, this wheel may be better. -- Jeff From nobody Tue Jun 10 11:35:27 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CAA1A01EA for ; Tue, 10 Jun 2014 11:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBkSPoGpXvf1 for ; Tue, 10 Jun 2014 11:35:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A461A1A00BD for ; Tue, 10 Jun 2014 11:35:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7359CC1AA; Tue, 10 Jun 2014 14:35:06 -0400 (EDT) Date: Tue, 10 Jun 2014 14:35:06 -0400 From: Jeffrey Haas To: Sriganesh Kini Message-ID: <20140610183506.GK20397@pfrc> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/mpbJh33vY26oVkh-iNKzrFT4zqI Cc: Jeffrey Haas , "" , "" , Dean Bogdanovic , "t.petch" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 18:35:08 -0000 On Tue, May 20, 2014 at 09:23:13AM -0700, Sriganesh Kini wrote: > On Tue, May 20, 2014 at 8:06 AM, Dean Bogdanovic wrote: > > > Changes done by I2RS agent should have only device impact, not network > >> impact. If there is desire to change across network, then each I2RS agent > >> on each device should be updated. > >> > > > > It is not simple to classify a change to a device as having an impact > > scoped to just that device. E.g a route that is added to a device with a > > different preference can have network-wide traffic impact. > > > > > > How can I explain this better. The static route on device will be routed > > to the next destination, but at the next destination the dynamic protocol > > will take effect, unless, another static route directs the traffic > > differently. Makes sense? > > > I think what you really wanted to say is - An I2RS agent must not interface > with an I2RS agent on another network element. If an I2RS client requires > to interface with I2RS agents on multiple network elements, it must do so > itself without putting requirements on the I2RS agent on one network > element to interface with the I2RS agent on another network element. As mentioned elsewhere, I tend to perceive I2RS's impact on the network as being similar to that of a routing protocol. If I want something I do to a given device to propagate, the state that is injected must either be suitable for injection into another routing protocol (redistribute into BGP, or IGP, e.g.) or must be fully local. We will have cases for both. For Sri's point, if I inject state in to router A and it overlaps with state in router B, it better be because that state had arrived via a routing protocol. In such a case, the interaction between I2RS and the protocol would already be defined. -- Jeff From nobody Tue Jun 10 12:03:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6321A0271 for ; Tue, 10 Jun 2014 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67yEzBTnZA9P for ; Tue, 10 Jun 2014 12:02:31 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1521A0270 for ; Tue, 10 Jun 2014 12:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CA0FB780EF9; Tue, 10 Jun 2014 12:02:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 26233780F4F; Tue, 10 Jun 2014 12:02:23 -0700 (PDT) Message-ID: <53975642.9060104@joelhalpern.com> Date: Tue, 10 Jun 2014 15:02:26 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , Joe Marcus Clarke References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> In-Reply-To: <20140610183003.GJ20397@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EbOKjAjBsviwBwEpy58dNP-JQaY Cc: "i2rs@ietf.org" , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:02:39 -0000 In my personal view, it is clearly outside of our remit to reinvent logging, no matter whether we like it or not. As such, the structural specificity of a YANG model (or ABNF) simply does not belong in this document. The clarity about what fields will be logged is needed. if we focus on the job we need done, we can do it. If we get into fighting about how logs work, we will create confusion for operators without helping ourselves. Yours, Joel On 6/10/14, 2:30 PM, Jeffrey Haas wrote: > On Mon, Jun 09, 2014 at 11:29:48AM -0400, Joe Marcus Clarke wrote: >> Thus, section 5.5 is an attempt to model the important bits of the >> log so that the diagnostics one gets from I2RS are complete. The >> specific on-the-wire formats (syslog, NETCONF notifications, SNMP >> notifications, etc.) would certainly be left to those domains. But >> the fields that must be logged and what those fields should look >> like seems to fit squarely in the domain or I2RS. > > FWIW, I find this version of the draft to be much improved. A few comments: > - The yang module seems to have indentation issues. > - The log-entry-id key should receive a bit of documentation as to whether > sequence number gaps are permitted. > > While I sympathize with Joel's point that "there are other systems that > provide logging, don't reinvent the wheel", being a relative newcomer to > yang myself I have to wonder if any of those systems provide for this type > of representation. > > The usual pain point one has with syslog like services is the issues of > convoluted greps or other free-form parse to extract data from the stream > and the lack of structure. Being able to know from day one that I can get > at this type of data using an XPath slice is very attractive. > > If that kind of functionality is provided in other mechanisms, let's not > reinvent the wheel. If it isn't, this wheel may be better. > > -- Jeff > From nobody Tue Jun 10 12:09:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF791A0262 for ; Tue, 10 Jun 2014 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouY9n03Xtrvl for ; Tue, 10 Jun 2014 12:09:22 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4561A0081 for ; Tue, 10 Jun 2014 12:09:22 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id un15so1154961pbc.34 for ; Tue, 10 Jun 2014 12:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NdKiyI3PSZ21IowGEq4OYDP0uOQmMZXkSQlfNeUwVJg=; b=aK4x1/zSPrv9xW6KO+CtctFXE9ET+85nQauos/bhDm+qVDVhg8SkGt7m7rvJk6d25x rypo/3aQ2+8ibBYWAMwxj0cWBdE0+MZfwbGAGzC+TLYTlyp8vqSMgu1u3SEkBcondvab FDf7hJOFNkI8iGYf0wF2+b+usafDl3dsdzPmdgDg0tjDSmNyeG7j1RnPm52gmtsSSUGi fH4jXiCayjWkon0gUsPKLm+K8PRWQZtCVuj3HrUAKmRvzJ6N8WT5celtYuMpeZJ/mYvN 0fYymO8e4nOD00QDwj2BnLIUybK1cwXImLMS34u1SSusAjRSFkEwkMcDjNgD0kQ2jwo3 87iA== X-Received: by 10.67.14.37 with SMTP id fd5mr7676362pad.72.1402427362217; Tue, 10 Jun 2014 12:09:22 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.83.133 with HTTP; Tue, 10 Jun 2014 12:08:52 -0700 (PDT) In-Reply-To: <20140605202938.GP13606@pfrc> References: <20140605202938.GP13606@pfrc> From: Sriganesh Kini Date: Tue, 10 Jun 2014 12:08:52 -0700 X-Google-Sender-Auth: 3mKNALrERejsnc0QBsSVmxFEt7c Message-ID: To: Jeffrey Haas Content-Type: multipart/alternative; boundary=047d7b1121b3bf954104fb801075 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3Ja3NBuYKpXt7UkUQAAKKmhpwHU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:09:23 -0000 --047d7b1121b3bf954104fb801075 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 5, 2014 at 1:29 PM, Jeffrey Haas wrote: > Working Group, > > The original deadline for comments on WGLC for the problem statement and > architecture drafts of May 30 has passed with no comment whatsoever. > > While we all realize that there's a bit of exhaustion going on with regard > to these drafts, they are a bit of process we simply must get done in order > to fully move forward with our agenda of putting together data models. > > We are *NOT* going to hold that work up further - it is clear that there is > consenus to start making that progress. > > To assist us with putting this work behind us, please respond to the > following questions: > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > Have you read the problem statement draft? > Yes. > Do you think it is ready to be published as a RFC? > (If no, please respond to the list with issues.) > Yes. > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > Have you read the architecture draft? > yes > Do you think it is ready to be published as a RFC? > (Ditto.) > A question in sec 7.8. Second para. There is a sentence starting with "The mechanism for this is to ..." and later it says "In order for this approach to ...". The first sentence seems to imply that this is the only mechanism allowed by this architecture whereas the second sentence seems to imply that this is one possible mechanism and agents can choose other mechanisms too. Which one is correct ? I would suggest that the language be updated to reflect that. Otherwise the doc looks good to be published as a RFC. Sri > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b1121b3bf954104fb801075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 1:29 PM, Jeffrey Haas <= jhaas@pfrc.org><= /span> wrote:
Working Group,

The original deadline for comments on WGLC for the problem statement and architecture drafts of May 30 has passed with no comment whatsoever.

While we all realize that there's a bit of exhaustion going on with reg= ard
to these drafts, they are a bit of process we simply must get done in order=
to fully move forward with our agenda of putting together data models.

We are *NOT* going to hold that work up further - it is clear that there is=
consenus to start making that progress.

To assist us with putting this work behind us, please respond to the
following questions:

http://datatracker.ietf.org/doc/draft-ietf-i2rs-probl= em-statement/
Have you read the problem statement draft?

<= div>Yes.
=C2=A0
Do you think it is ready to be published as a RFC?
(If no, please respond to the list with issues.)

<= /div>
Yes.
=C2=A0

http://datatracker.ietf.org/doc/draft-ietf-i2rs-architectu= re/
Have you read the architecture draft?

y= es
=C2=A0
Do you think it is ready to be published as a RFC?
(Ditto.)

A question in sec 7.8. Second = para. There is a sentence starting with "The mechanism for this is to = ..." and later it says "In order for this approach to =C2=A0...&q= uot;. The first sentence seems to imply that this is the only mechanism all= owed by this architecture whereas the second sentence seems to imply that t= his is one possible mechanism and agents can choose other mechanisms too. W= hich one is correct ? I would suggest that the language be updated to refle= ct that.

Otherwise the doc looks good to be published as a RFC.<= /div>

Sri
=C2=A0

-- Jeff

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

--047d7b1121b3bf954104fb801075-- From nobody Tue Jun 10 12:34:59 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390251A0081 for ; Tue, 10 Jun 2014 12:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoQWpYXUO9XC for ; Tue, 10 Jun 2014 12:34:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9E1A0279 for ; Tue, 10 Jun 2014 12:34:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1F78DC1AA; Tue, 10 Jun 2014 15:34:34 -0400 (EDT) Date: Tue, 10 Jun 2014 15:34:34 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20140610193433.GB32305@pfrc> References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53975642.9060104@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LLD5PQOpnvQX09_KaF2GFHVpAsQ Cc: Jeffrey Haas , "i2rs@ietf.org" , Joe Marcus Clarke , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:34:36 -0000 On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: > In my personal view, it is clearly outside of our remit to reinvent > logging, no matter whether we like it or not. Agreed. Not in-scope for I2RS currently. Where would you suggest such work be done? > As such, the structural specificity of a YANG model (or ABNF) simply > does not belong in this document. The clarity about what fields > will be logged is needed. Would you agree that if the yang module is dropped that the info model is sufficiently clear for I2RS purposes? -- Jeff From nobody Tue Jun 10 12:43:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14D1A02A6 for ; Tue, 10 Jun 2014 12:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRH4GZs7EVWM for ; Tue, 10 Jun 2014 12:43:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0407C1A028E for ; Tue, 10 Jun 2014 12:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1526; q=dns/txt; s=iport; t=1402429396; x=1403638996; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DmfLEyXtXE4CQgWDNY36yJe0X7LCeY8hHJVFiG05AnA=; b=Ba/zrxDR2hB6YHN8DobsgDrZ4T44DvKH49zsROMTex+DkM6n3+tavFdK VYPaxkrS695tJNYxhcRAvtfyKMx8Hv/O/kMNOOawyn6uRNjXWJ6WGBW75 wjEHSKvRaMFzOTQG+GSlUMVz7kWt3LuJSkKNuiVdRCOTZ02/mwWQUOzGX k=; X-IronPort-AV: E=Sophos;i="4.98,1010,1392163200"; d="scan'208";a="51939198" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 10 Jun 2014 19:43:15 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-54-71.cisco.com [10.150.54.71]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5AJhEoC008448; Tue, 10 Jun 2014 19:43:15 GMT Message-ID: <53975FD2.2020707@cisco.com> Date: Tue, 10 Jun 2014 15:43:14 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , "Joel M. Halpern" References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> In-Reply-To: <20140610193433.GB32305@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gy_Y1BwbEPxWCeY8Wx7u4WmM48s Cc: "i2rs@ietf.org" , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:43:17 -0000 On 6/10/14, 3:34 PM, Jeffrey Haas wrote: > On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: >> In my personal view, it is clearly outside of our remit to reinvent >> logging, no matter whether we like it or not. > > Agreed. Not in-scope for I2RS currently. I want to be very clear that we are not trying to reinvent logging. What we are trying to do is define _what_ should get logged within the I2RS scope. _How_ that is logged (syslog, NETCONF, SNMP, etc.) is not within scope. We don't want a new log protocol. What we want is to ensure that implementors of I2RS have a model on which to base their traceability so that vendor X and vendor Y have consistency for a consumer using I2RS (while perhaps allowing for some extensibility down the road). We (the authors) strongly feel there must be some core consistent elements of I2RS operations that must be logged, and that is all we are trying to define here. > > Where would you suggest such work be done? > >> As such, the structural specificity of a YANG model (or ABNF) simply >> does not belong in this document. The clarity about what fields >> will be logged is needed. > > Would you agree that if the yang module is dropped that the info model is > sufficiently clear for I2RS purposes? To us, the YANG module simply represents a way to clearly articulate what the fields are [syntactically] from the I2RS protocol. It isn't an attempt to discuss overall transmission or on-disk formats. Joe From nobody Tue Jun 10 12:45:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132A11A02D2 for ; Tue, 10 Jun 2014 12:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ds_LnE18MKwq for ; Tue, 10 Jun 2014 12:45:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 936141A02BF for ; Tue, 10 Jun 2014 12:45:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 603ABC1AA; Tue, 10 Jun 2014 15:45:06 -0400 (EDT) Date: Tue, 10 Jun 2014 15:45:06 -0400 From: Jeffrey Haas To: Joe Marcus Clarke Message-ID: <20140610194506.GC32305@pfrc> References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <53975FD2.2020707@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53975FD2.2020707@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/beA_wWZL0At_vQQTNarNrevUO6Q Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:45:08 -0000 Joe, On Tue, Jun 10, 2014 at 03:43:14PM -0400, Joe Marcus Clarke wrote: > To us, the YANG module simply represents a way to clearly articulate > what the fields are [syntactically] from the I2RS protocol. It > isn't an attempt to discuss overall transmission or on-disk formats. I must admit even as a netconf/yang newbie that the presence of a yang module with a defined URN does strongly imply something that could be implemented and retrieved using netconf. Note that I agree with your point about logging consistency. -- Jeff From nobody Tue Jun 10 12:51:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9783B1A02BF for ; Tue, 10 Jun 2014 12:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeJ8fwB_Dx8v for ; Tue, 10 Jun 2014 12:51:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4341A02B4 for ; Tue, 10 Jun 2014 12:51:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 495EB742; Tue, 10 Jun 2014 21:51:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OwnSVM2xq3bc; Tue, 10 Jun 2014 21:51:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Jun 2014 21:51:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16BFA20017; Tue, 10 Jun 2014 21:51:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kmp15iowM-SY; Tue, 10 Jun 2014 21:51:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6251020013; Tue, 10 Jun 2014 21:51:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 48EA52D613BD; Tue, 10 Jun 2014 21:51:16 +0200 (CEST) Date: Tue, 10 Jun 2014 21:51:16 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140610195116.GB29148@elstar.local> Mail-Followup-To: Jeffrey Haas , "Joel M. Halpern" , "i2rs@ietf.org" , Joe Marcus Clarke , Gonzalo Salgueiro , Carlos Pignataro References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140610193433.GB32305@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/IdFaQA2gECCz1rwy_KsTq-XLEW0 Cc: "i2rs@ietf.org" , Carlos Pignataro , "Joel M. Halpern" , Joe Marcus Clarke , Gonzalo Salgueiro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 10 Jun 2014 19:51:21 -0000 On Tue, Jun 10, 2014 at 03:34:34PM -0400, Jeffrey Haas wrote: > On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: > > In my personal view, it is clearly outside of our remit to reinvent > > logging, no matter whether we like it or not. > > Agreed. Not in-scope for I2RS currently. > > Where would you suggest such work be done? > > > As such, the structural specificity of a YANG model (or ABNF) simply > > does not belong in this document. The clarity about what fields > > will be logged is needed. > > Would you agree that if the yang module is dropped that the info model is > sufficiently clear for I2RS purposes? > I have been silently following this discussion and I do not have a strong opinion but I think it might help to understand that a) NETCONF has a notification mechanism (RFC 5277), and b) SYSLOG has in its standards-track version support for carrying structured data (RFC 5424). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jun 10 12:53:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED711A02A6 for ; Tue, 10 Jun 2014 12:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4g4TZIZs_Y8s for ; Tue, 10 Jun 2014 12:53:29 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB3B1A0296 for ; Tue, 10 Jun 2014 12:53:29 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.98,1010,1392181200"; d="scan'208";a="354392446" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jun 2014 15:53:09 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 10 Jun 2014 15:53:29 -0400 From: "George, Wes" To: Jeffrey Haas Date: Tue, 10 Jun 2014 15:53:27 -0400 Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: Ac+E5aXUvm/i55ZfTQ673kd/h5+ugA== Message-ID: References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> In-Reply-To: <20140610172136.GF20397@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HxxvuzFf6cFsRBV-rwG6JmjYRw4 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:53:31 -0000 DQpPbiA2LzEwLzE0LCAxOjIxIFBNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNAcGZyYy5vcmc+IHdy b3RlOg0KDQpQcm9ibGVtIHN0YXRlbWVudDoNCj4+IFNlY3Rpb24gMjogSXQgd291bGQgYmUgdXNl ZnVsIHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIHRoZSBwcm9wb3NlZCBkYXRhDQo+PiBtb2RlbC4g PHNuaXA+DQoNCj5UaGUgd2F5IEkndmUgaW50ZXJwcmV0ZWQgdGhlIGRpYWdyYW0gaXMgYmFzaWNh bGx5Og0KPi0gSTJSUyBkZWZpbmVzIHRoZSBjbGllbnQgYW5kIGFnZW50IGFuZCB0aGUgaW50ZXJh Y3Rpb25zIChwcm90b2NvbCkNCj4tIFRoZSBBZ2VudCwgYnkgbmVjZXNzaXR5LCBpbnRlcmFjdHMg d2l0aCBzeXN0ZW0gY29tcG9uZW50cyBpbiBhIGJsYWNrLWJveA0KPiAgaW1wbGVtZW50YXRpb24t c3BlY2lmaWMgZmFzaGlvbi4NCj4NCj5XaGlsZSBJIHVuZGVyc3RhbmQgeW91J3JlIGxvb2tpbmcg Zm9yICJ3aGVyZSBkb2VzIGEgZGF0YSBtb2RlbCBib3ggZml0DQo+aW50bw0KPnRoZSBkaWFncmFt IiwgSSdtIG5vdCBzdXJlIHRoZXJlJ3MgZW5vdWdoIGZsZXhpYmlsaXR5IGluIHRoZSBBU0NJSSBk aWFncmFtDQo+dG8gY292ZXIgdGhhdC4gOi0pICBJZiB0aGlzIHdlcmUgVU1MICh3aGljaCB3b3Vs ZCBiYWxsb29uIHRoZSBkaWFncmFtIGFuDQo+b3JkZXIgb2YgbWFnbml0dWRlKSwgd2UnZCBoYXZl IEludGVyZmFjZSBsb2xsaXBvcHMgYWxsIG92ZXIgdGhlIHBsYWNlIGFuZA0KPmV2ZW4gdGhlbiwg dGhhdCdzIHByb2JhYmx5IHRoZSBiZXN0IHdlJ2QgaGF2ZSBmb3IgdGhlIGhpZ2ggbGV2ZWwNCj5k ZXNjcmlwdGlvbi4NCldHXSBOb3QgbmVjZXNzYXJpbHkgYXNraW5nIGZvciBhZGRpdGlvbmFsIGJv eGVzIGluIHRoZSBkaWFncmFtLCBiZWNhdXNlIEkNCmFncmVlIHRoYXQgdGhlcmXigJlzIG5vIHdh eSB0byByZXByZXNlbnQgaXQgdW5sZXNzIHlvdSBkdXBsaWNhdGUgdGhlIHNhbWUNCmRpYWdyYW0g KHdpdGggYXBwcm9wcmlhdGUgY2hhbmdlcyBpbiBzY29wZSkgZm9yIHRoZSBkYXRhIG1vZGVsLiBJ IHdhcyBtb3JlDQp0aGlua2luZyBpbiB0ZXJtcyBvZiBtYWtpbmcgaXQgYSBiaXQgY2xlYXJlciBp biB0aGUgdGV4dCBmb2xsb3dpbmcgdGhlDQpkaWFncmFtIHRoYXQgdGhlIGRhdGEgbW9kZWwgbWF5 IG5lY2Vzc2FyaWx5IGluY2x1ZGUgdGhpbmdzIHRoYXQgYXJlIGxpc3RlZA0KYXMgb3V0IG9mIHNj b3BlIGZvciB0aGUgSTJSUyBpbnRlcmZhY2UvcHJvdG9jb2wsIGJlY2F1c2UgaXQgbmVlZHMgYSB3 YXkgdG8NCnJlcHJlc2VudCB0aGUgdGhpbmdzIHRoYXQgaXQgZ2V0cyBmcm9tIHRoZSBJMlJTIGFn ZW50IGJhc2VkIG9uIGl0cyBibGFjaw0KYm94IGludGVyYWN0aW9uIHdpdGggb3RoZXIgcGFydHMg b2YgdGhlIHJvdXRpbmcgc3lzdGVtLg0KDQo+DQo+PiAgYnV0IHlvdSBtYXkgd2FudCB0byBiZSBt b3JlIGV4cGxpY2l0IGluIHRoZSBsYXR0ZXIgaGFsZiBvZg0KPj4gc2VjdGlvbiAyLCBhcyB3ZWxs IGFzIHJlcGxhY2luZyA/Pz9JMlJTIiB3aXRoIHNvbWV0aGluZyBtb3JlDQo+PmRlc2NyaXB0aXZl IGluDQo+PiB0aGUgZGlhZ3JhbSB0byBhdm9pZCBuYW1pbmcgY29uZnVzaW9uIHNpbmNlID8/P0ky UlM/Pz8gY2FuIG1lYW4gSUVURg0KPj5XRy9lZmZvcnQNCj4+IE9SIHRoZSBhY3R1YWwgaW50ZXJm YWNlIHRvIHRoZSByb3V0aW5nIHN5c3RlbSBhbmQgcmVsYXRlZCBwcm90b2NvbC4NCj4NCj5JIHRo aW5rIGl0J3MgbWVhbnQgdG8gY292ZXIgYm90aCBjYXNlczogV2l0aGluIHRoZSBzY29wZSBvZiB0 aGUgV0cgZWZmb3J0DQo+YW5kIGFsc28gcHJvdG9jb2wgaW50ZXJhY3Rpb25zLg0KV0ddIFRoYXTi gJlzIHNvcnQgb2YgdGhlIHByb2JsZW0gSSB3YXMgcG9pbnRpbmcgb3V0LiBNYXliZSB0aGlzIG9u bHkgbWF0dGVycw0Kd2hpbGUgd2XigJlyZSBpbiB0aGUgbWlkZGxlIG9mIHRoZSBkaXNjdXNzaW9u IGFuZCBwZW9wbGUgcmVtZW1iZXIgdGhlIG5hbWUNCm9mIHRoZSBXRyBhbmQgYXJlIHRoZXJlZm9y ZSBsaWtlbHkgdG8gY29uZmxhdGUgdGhlIHR3bywgYnV0IGZvciByaWdodCBub3csDQppdCBkb2Vz IGhhdmUgc29tZSBwb3RlbnRpYWwgZm9yIGNvbmZ1c2lvbi4gSSBsZWF2ZSBpdCB0byB0aGUgV0cg YW5kDQphdXRob3JzIHRvIGRlY2lkZSB3aGV0aGVyIHRoYXTigJlzIGEgdHJpdmlhbCBjb25jZXJu IG9yIG5vdC4NCg0KQXJjaGl0ZWN0dXJlOg0KPg0KPkZsb3cgZGF0YSBpc24ndCBzcGVjaWZpY2Fs bHkgaW4tc2NvcGUgdG8gY2hhcnRlcmVkIHdvcmsgLSB0b2RheS4NCuKAmFdHXSBZZXMsIHdhc27i gJl0IGFkdm9jYXRpbmcgdG8gaW5jbHVkZSBpdCwgbWVyZWx5IG9ic2VydmluZyB0aGF0IHRoZQ0K ZG9jdW1lbnQgaXMgbm90IGV4cGxpY2l0IG9uZSB3YXkgb3IgdGhlIG90aGVyIGhlcmUsIGFuZCBv bmUgY291bGQgbWFrZSB0aGUNCmFyZ3VtZW50IHRoYXQgZmxvdyBkYXRhIGlzIGEgdHlwZSBvZiBz dGF0cy4gU28gaWYgaXQgaXMgaW5kZWVkIG91dCBvZg0Kc2NvcGUsIEkgdGhpbmsgdGhlcmXigJlz IHZhbHVlIGluIGNhbGxpbmcgdGhhdCBvdXQgc3BlY2lmaWNhbGx5Lg0KPg0KPg0KPj4gNi4yIC0g SSByZWNvbW1lbmQgdGhhdCB5b3UgZXhwbGljaXRseSBjYWxsIG91dCB0aGUgbmVlZCB0byBiZSBh YmxlIHRvDQo+PiByZXZpZXcgKGUuZy4gdmlhIENMSSkgdGhlIGNoYW5nZXMgbWFkZSBieSB0aGUg STJSUyBhZ2VudCBhbmQgaXRzIHN0YXRlDQo+PiBkYXRhIHdpdGhvdXQgYSBkZXBlbmRlbmN5IG9u IHRoZSBjbGllbnQgaXRzZWxmLiA8c25pcD4NCg0KPltQbGVhc2Ugbm90ZTogRGlzY3Vzc2lvbiwg bm90IG5lY2Vzc2FyaWx5IGRpc2FncmVlbWVudC5dDQo+DQo+SSB0aGluayB0aGVyZSdzIGEgZmV3 IGNoYWxsZW5nZXMgd2l0aCB0aGlzLiAgVGhlIGJpZ2dlc3Qgb25lIGlzIHRoYXQgbm8NCj5tYXR0 ZXIgaG93IGNhcmVmdWxseSB3ZSB0cnkgdG8gd29yZCBzdWNoIGFuIGFyY2hpdGVjdHVyYWwgcmVx dWlyZW1lbnQsDQo+d2UncmUNCj5nb2luZyB0byBlbmQgdXAgbWFraW5nIGRlbWFuZHMgb24gaW1w bGVtZW50YXRpb25zIHRoYXQgZWl0aGVyIHdpbGwgYmUNCj5kaWZmaWN1bHQgdG8gc3RhbmRhcmRp emUgb3IgcGVyaGFwcyBldmVuIGltcG9zc2libGUuDQo+DQo+DQo+Rm9yIHdoYXQgaXQncyB3b3J0 aCwgdGhpcyBpc24ndCBtdWNoIHVnbGllciAoYW5kIHByb2JhYmx5IGlzIGEgY2FzZSB0aGF0DQo+ YnJvdWdodCB0aGlzIHRvIG1pbmQgZm9yIHlvdSkgdGhhbiBjb25maWd1cmF0aW9uIHN0YXRlIGlt cG9zZWQgYnkgU05NUA0KPnJhdGhlciB0aGFuIHRoZSBDTEkuICBDb25maWd1cmF0aW9uIGNvbnN0 cnVjdHMgaW4gU05NUCBtYXkgbm90IGhhdmUgZ29vZA0KPm1hcHBpbmdzIHRvIHRob3NlIGluIHRo ZSBDTEkgYW5kIHZpY2UgdmVyc2EuDQpXR10gYW5kIGFzIG5vdGVkLCB3ZSByZWNvbW1lbmQgYWdh aW5zdCB1c2luZyBTTk1QIHRvIGltcG9zZSBzdGF0ZSBhbnltb3JlDQpmb3IgbG90cyBvZiBnb29k IHJlYXNvbnMsIHNvIEnigJltIG5vdCBhdCBhbGwgY29udmluY2VkIHRoYXQg4oCcbm90IG11Y2gN CnVnbGllciB0aGFuIFNOTVDigJ0gaXMgYSBmZWF0dXJl4oCmDQo+DQo+QSB0cml2aWFsIGNvbXBh cmlzb24gbWlnaHQgYmUgaWYgeW91ciBJMlJTIGFnZW50IHdhcyBpbXBsZW1lbnRlZCBieSBkb2lu Zw0KPkNMSSB0cmFuc2xhdGlvbiwgdGhlbiBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBkbyBDTEkg Y29tcGFyaXNvbnMuICBCdXQgaWYNCj5pdCdzIG5vdCwgc3VjaCBjb21wYXJpc29uIG1heSBiZSBo YXJkLg0KV0ddIFRoZSByZWFsaXR5IGlzIHRoYXQgb3BlcmF0b3JzIGhhdmUgYmVlbiBkZWFsaW5n IHdpdGggdGhpcyBkaXNjb25uZWN0DQpmb3IgeWVhcnMsIHdoZXJlIGEgdmVuZG9yIGltcGxlbWVu dHMgYSBmZWF0dXJlIHRoYXQgaXMgZWl0aGVyIGZ1bGx5DQpzdXBwb3J0ZWQgaW4gQ0xJIGJ1dCBu b3Qgc2ltdWx0YW5lb3VzbHkgaW4gJG1hZ2ljX21hbmFnZW1lbnRfaW50ZXJmYWNlIGR1DQpqb3Vy LCBvciB2aWNlIHZlcnNhLiBJdCBjYW4gYmUgYSB0ZW1wb3JhcnkgZ2FwIGR1ZSB0byBtaXNtYXRj aGVzIGluDQpyZWxlYXNlIGNhZGVuY2UsIG9yIGl0IGNvdWxkIGJlIGEgcGVybWFuZW50IGdhcCBi YXNlZCBvbiBhIGNvbnNjaW91cw0KZGVjaXNpb24sIGJ1dCBlaXRoZXIgd2F5IHRob3NlIGdhcHMg bWFrZSBpdCBkaWZmaWN1bHQgZm9yIG9wZXJhdG9ycyB0bw0KaW1wbGVtZW50IHRoZSBmZWF0dXJl LCBiZWNhdXNlIGVpdGhlciB5b3UgZG9u4oCZdCBoYXZlIGEgd2F5IHRvIHZlcmlmeSBhbmQNCnRy b3VibGVzaG9vdCBpdCBvdXRzaWRlIG9mIHRoZSBwcmltYXJ5IChzeXN0ZW1hdGljKSBpbnRlcmZh Y2UsIG9yIHlvdQ0KZG9u4oCZdCBoYXZlIGEgd2F5IHRvIHN5c3RlbWF0aWNhbGx5IGludGVyYWN0 IHdpdGggaXQgYW5kIHlvdSBoYXZlIHRvIHNjcmVlbg0Kc2NyYXBlIG9yIHN3aXZlbCBzZWF0LiBU aGlzIGNhbuKAmXQgYmUgYW4gZWl0aGVyLW9yLCBiZWNhdXNlIGZvciB0aGUNCmZvcmVzZWVhYmxl IGZ1dHVyZSB3ZSBhcmUgbm90IGdvaW5nIHRvIGJlIGFibGUgdG8gYXNzdW1lIHRoYXQgaWYgdGhl DQphZ2VudC9zeXN0ZW1hdGljIGludGVyZmFjZSBpcyBwcmVzZW50LCB0aGF0IG5vIG9uZSB3aWxs IGV2ZXIgdXNlIG9yIG5lZWQNCnRoZSBDTEkgZm9yIGFueXRoaW5nIHRoYXQgY2FuIGJlIGRvbmUg dmlhIHRoZSBhZ2VudCwgb3IgdGhhdCB0aGUgdXNlcyBmb3INCmVhY2ggY2FuIGJlIG11dHVhbGx5 IGV4Y2x1c2l2ZS4gVGhhdCBqdXN0IG1ha2VzIHRoZSBzeXN0ZW0gYnJpdHRsZSBhbmQgdGhlDQpt ZXRob2RzIGZvciB0cm91Ymxlc2hvb3RpbmcgaXQgbmVlZGxlc3NseSBjb21wbGV4LiBUaGVyZSBh cmUgYSBsb3Qgb2YNCmZvbGtzIGluIG9wZXJhdGlvbnMgd2l0aCBhIGhlYWx0aHkgZGlzdHJ1c3Qg Zm9yIGxhcmdlLXNjYWxlLCBjb21wbGV4DQphdXRvbWF0aW9uIHdoZXJlIHRoZSBzeXN0ZW0gaXMg bWFraW5nIGEgbG90IG9mIGRlY2lzaW9ucyBvbiBpdHMgb3duLA0KYmVjYXVzZSBvZiB0aGUgcmlz ayB0byBleHBlcmllbmNlIGEgbWFqb3Igb3V0YWdlIGR1ZSB0byB0aGUgImdob3N0IGluIHRoZQ0K bWFjaGluZeKAnSAtIGZvciB0aGVtLCB0aGF0IG1ha2VzIGhhdmluZyBhIG1lYW5zIHRvIG9ic2Vy dmUvbWFuaXB1bGF0ZS9maXgNCnRoaW5ncyBpbmRlcGVuZGVudCBvZiB0aGUgbWFjaGluZXJ5IGlz IGEgbm9uLW5lZ290aWFibGUgcmVxdWlyZW1lbnQsIGF0DQpsZWFzdCB1bnRpbCB0aGVyZSBpcyBz b21lIHRydXN0IGJ1aWx0IHVwIHRoYXQgdGhlIG1hY2hpbmUgaXNu4oCZdCBnb2luZyB0bw0KZ28g aW5zYW5lIGFuZCBudWtlIHRoZSBuZXR3b3JrLiBUaGVyZeKAmXMgYSByZWFzb24gSeKAmW0gdXNp bmcgdGhlIGxhbmd1YWdlDQpJ4oCZdmUgY2hvc2VuIGhlcmUsIHRoZSBmZWFycyBhcmUgbm90IHRv dGFsbHkgcmF0aW9uYWwsIGJ1dCB0aGV5IGRvIHNlcnZlIGFzDQphIHJlYWwgYmFycmllciB0byBk ZXBsb3ltZW50LCBzbyB3ZSBpZ25vcmUgdGhlbSBhdCBvdXIgb3duIHBlcmlsLg0KDQoNCj4NCj5H aXZlbiB0aGUgYWJvdmUsIHdoYXQgd291bGQgeW91IHN1Z2dlc3Q/ICBJIHJlYWxpemUgd2hhdCB3 ZSB3YW50IGlzIGEgd2F5DQo+dG8NCj50cm91Ymxlc2hvb3QsIGJ1dCBJJ20gbm90IHN1cmUgdGhl cmUgY2FuIGJlIGFueSBzcGVjaWZpYyByZWNvbW1lbmRhdGlvbg0KPnRoYXQNCj53aWxsIHNwYW4g dGhlIGFyY2hpdGVjdHVyZXMgd2VsbCBlbm91Z2ggdG8gYmUgc3RhbmRhcmRpemVkLg0KV0ddIFdl bGwsIEkgdGhpbmsgdGhlcmXigJlzIGEgdmFsaWQgdHJhY2VhYmlsaXR5IGFuZCB0cm91Ymxlc2hv b3RpbmcNCnJlcXVpcmVtZW50IGluIHRoZSBmb3JtIG9mIG5lZWRpbmcgdGhlIGFiaWxpdHkgdG8g ZG8gdmVyaWZpY2F0aW9uIGFuZA0KZXhhbWluYXRpb24gb2YgdGhlIHN0YXRlIGFuZCBhY3Rpb25z IHRha2VuIGJ5IEkyUlMgYWdlbnQocykgd2l0aG91dA0KaW52b2tpbmcgdGhlIGFnZW50IGJlaW5n IGV4YW1pbmVkLiBXZSBkb27igJl0IG5lZWQgdG8gYmUgcHJlc2NyaXB0aXZlIG9uIHRoZQ0KZm9y bWF0IGZvciB0aGF0IGluZm9ybWF0aW9uLCBub3IgdGhlIG1ldGhvZCBmb3IgcHJvdmlkaW5nIHRo YXQgaW5kZXBlbmRlbnQNCmF2ZW51ZSBmb3IgYWNjZXNzaW5nIGl0LCB3ZSBtdXN0IG9ubHkgbm90 ZSB0aGF0IGl0IG5lZWRzIHRvIGJlIGF2YWlsYWJsZS4NCkZvciBleGFtcGxlLCBpbiBhIHJvdXRp bmcgZWxlbWVudCB0aGF0IGRvZXNu4oCZdCByZWFsbHkgaGF2ZSBhIENMSSwgdGhlDQppbmRlcGVu ZGVudCBtZXRob2QgZG9lc27igJl0IGhhdmUgdG8gYmUgdmlhIENMSSwgaXQgY291bGQgYmUgdmlh IGEgd2ViIFVJIG9yDQpzb21lIHByZXR0eSBHVUkgaWYgdGhhdOKAmXMgdGhlIG90aGVyIG1ldGhv ZCB0byBtYW5hZ2UgdGhlIGRldmljZS4gSSBtZW50aW9uDQpDTEkgYXMgYW4gZXhhbXBsZSBiZWNh dXNlIGZvciB0aGUgbW9zdCBwYXJ0LCB0aGUgZmFpbC1zYWZlIG1ldGhvZCBmb3INCmludGVyYWN0 aW5nIHdpdGggdGhlIHJvdXRpbmcgc3lzdGVtIHRvZGF5IGlzIGluZGVlZCBDTEkuDQoNCg0KVGhh bmtzDQpXZXMgR2VvcmdlDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Tue Jun 10 12:55:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931B1A02C4 for ; Tue, 10 Jun 2014 12:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoZra-sB4f9i for ; Tue, 10 Jun 2014 12:55:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695831A0296 for ; Tue, 10 Jun 2014 12:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1211; q=dns/txt; s=iport; t=1402430124; x=1403639724; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=fvzIzYqgYJBW/bVvKDtCLa180zf7tYgutsFWfJNLDaQ=; b=l8skp3GPTvjIG5h+1qxSRP4iw9jEJQOS7ABNZPVoIXKdH9OfCFd+dOZZ HaGlhdMzNHWS65mZR12M2HZf8YGWeZnRZtZXiHOKMemXnFmUvYc6E8/f9 79pOOLHPAqL9byTjmM/YzH9AIbf6/rplLMf6pm6B0O8Li9tQrd9hzcYwv I=; X-IronPort-AV: E=Sophos;i="4.98,1010,1392163200"; d="scan'208";a="51941970" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 10 Jun 2014 19:55:23 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-54-71.cisco.com [10.150.54.71]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5AJtNfK006073; Tue, 10 Jun 2014 19:55:23 GMT Message-ID: <539762AB.8050208@cisco.com> Date: Tue, 10 Jun 2014 15:55:23 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , "Joel M. Halpern" , "i2rs@ietf.org" , Gonzalo Salgueiro , Carlos Pignataro References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <20140610195116.GB29148@elstar.local> In-Reply-To: <20140610195116.GB29148@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gLgRhpjPTWvoQaxf_1JUCG-S20c Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:55:25 -0000 On 6/10/14, 3:51 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 10, 2014 at 03:34:34PM -0400, Jeffrey Haas wrote: >> On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: >>> In my personal view, it is clearly outside of our remit to reinvent >>> logging, no matter whether we like it or not. >> >> Agreed. Not in-scope for I2RS currently. >> >> Where would you suggest such work be done? >> >>> As such, the structural specificity of a YANG model (or ABNF) simply >>> does not belong in this document. The clarity about what fields >>> will be logged is needed. >> >> Would you agree that if the yang module is dropped that the info model is >> sufficiently clear for I2RS purposes? >> > > I have been silently following this discussion and I do not have a > strong opinion but I think it might help to understand that > > a) NETCONF has a notification mechanism (RFC 5277), and > > b) SYSLOG has in its standards-track version support for carrying > structured data (RFC 5424). Thanks, Juergen. I was aware, and I feel that once we decide on what gets logged, then we can certainly use mechanisms like these down the road to answer the "how" question. Joe From nobody Tue Jun 10 12:58:55 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD981A033D for ; Tue, 10 Jun 2014 12:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozwxNFtC88nf for ; Tue, 10 Jun 2014 12:58:28 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068DC1A02FB for ; Tue, 10 Jun 2014 12:58:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AF9B21D89E1; Tue, 10 Jun 2014 12:58:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 7369F7814D1; Tue, 10 Jun 2014 12:58:26 -0700 (PDT) Message-ID: <53976366.90001@joelhalpern.com> Date: Tue, 10 Jun 2014 15:58:30 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> In-Reply-To: <20140610193433.GB32305@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/xNPjG3aY-08yvxG5GIcAJSmMrqQ Cc: "i2rs@ietf.org" , Joe Marcus Clarke , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:58:32 -0000 Yes, I would agree that if the YANG model is dropped the document is both useful and sufficiently clear. Yours, Joel On 6/10/14, 3:34 PM, Jeffrey Haas wrote: > On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: >> In my personal view, it is clearly outside of our remit to reinvent >> logging, no matter whether we like it or not. > > Agreed. Not in-scope for I2RS currently. > > Where would you suggest such work be done? > >> As such, the structural specificity of a YANG model (or ABNF) simply >> does not belong in this document. The clarity about what fields >> will be logged is needed. > > Would you agree that if the yang module is dropped that the info model is > sufficiently clear for I2RS purposes? > > -- Jeff > From nobody Tue Jun 10 13:13:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98191A02D3 for ; Tue, 10 Jun 2014 13:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPhclLqL_Z43 for ; Tue, 10 Jun 2014 13:12:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7052D1A0282 for ; Tue, 10 Jun 2014 13:12:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BFD5CF7B; Tue, 10 Jun 2014 22:12:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qEFc8e3JjYtb; Tue, 10 Jun 2014 22:12:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Jun 2014 22:12:52 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F35C20017; Tue, 10 Jun 2014 22:12:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4Fo65Q5hMorY; Tue, 10 Jun 2014 22:12:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9FAD20013; Tue, 10 Jun 2014 22:12:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 721C32D614E8; Tue, 10 Jun 2014 22:12:51 +0200 (CEST) Date: Tue, 10 Jun 2014 22:12:50 +0200 From: Juergen Schoenwaelder To: Joe Marcus Clarke Message-ID: <20140610201248.GA29273@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Jeffrey Haas , "Joel M. Halpern" , "i2rs@ietf.org" , Gonzalo Salgueiro , Carlos Pignataro References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <20140610195116.GB29148@elstar.local> <539762AB.8050208@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539762AB.8050208@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Wbw84QrGfeYyE54e8rPlTl-fbrw Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , Gonzalo Salgueiro , Carlos Pignataro Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 10 Jun 2014 20:12:56 -0000 On Tue, Jun 10, 2014 at 03:55:23PM -0400, Joe Marcus Clarke wrote: > > > >I have been silently following this discussion and I do not have a > >strong opinion but I think it might help to understand that > > > >a) NETCONF has a notification mechanism (RFC 5277), and > > > >b) SYSLOG has in its standards-track version support for carrying > > structured data (RFC 5424). > > Thanks, Juergen. I was aware, and I feel that once we decide on what > gets logged, then we can certainly use mechanisms like these down the > road to answer the "how" question. > The text in section 4.1 made me believe you were not aware of structured data in SYSLOG. [...] So, while the data contained within the syslog message would adhere to this information model, and may be consumable by a human operator, it would not be easily parseable by a machine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jun 10 13:14:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEAE1A02D3 for ; Tue, 10 Jun 2014 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU7tu9UkJWtW for ; Tue, 10 Jun 2014 13:14:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E391A0282 for ; Tue, 10 Jun 2014 13:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1031; q=dns/txt; s=iport; t=1402431261; x=1403640861; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=t1MMv4oNiDnaO7risSbRGsf1iAqoJj7mHVjzXpF6XcI=; b=EWcwYkyPgE7rqfFHdOHrK1izhZDPlahKxTuZFVybcd2asg2ihuqKgfYk 4nnHCw4Bd6jdJWg25McvNfF/iELLEcP26RpiQ2wAdYN9NrYGLxikZRApH wzgqNrBH7ePG/fSNLfpy730o0PIpOzNjFYhUqQf5SDeg5RVa3Kj1NVFik o=; X-IronPort-AV: E=Sophos;i="4.98,1011,1392163200"; d="scan'208";a="332115872" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2014 20:14:21 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (dhcp-10-150-54-71.cisco.com [10.150.54.71]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5AKEKAY023609; Tue, 10 Jun 2014 20:14:20 GMT Message-ID: <5397671C.2080302@cisco.com> Date: Tue, 10 Jun 2014 16:14:20 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas , "Joel M. Halpern" , "i2rs@ietf.org" , Gonzalo Salgueiro , Carlos Pignataro References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <20140610195116.GB29148@elstar.local> <539762AB.8050208@cisco.com> <20140610201248.GA29273@elstar.local> In-Reply-To: <20140610201248.GA29273@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/kXhu_TNNaqBmhJNJa9FHKOpvhfw Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:14:23 -0000 On 6/10/14, 4:12 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 10, 2014 at 03:55:23PM -0400, Joe Marcus Clarke wrote: >>> >>> I have been silently following this discussion and I do not have a >>> strong opinion but I think it might help to understand that >>> >>> a) NETCONF has a notification mechanism (RFC 5277), and >>> >>> b) SYSLOG has in its standards-track version support for carrying >>> structured data (RFC 5424). >> >> Thanks, Juergen. I was aware, and I feel that once we decide on what >> gets logged, then we can certainly use mechanisms like these down the >> road to answer the "how" question. >> > > The text in section 4.1 made me believe you were not aware of > structured data in SYSLOG. > > [...] So, while the data contained within the > syslog message would adhere to this information model, and may be > consumable by a human operator, it would not be easily parseable by a > machine. Ah, yes. Good catch. That can certainly be restated. Thanks. Joe From nobody Tue Jun 10 13:14:47 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524051A02D3 for ; Tue, 10 Jun 2014 13:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlZjeLeqBNz5 for ; Tue, 10 Jun 2014 13:14:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 30C361A0282 for ; Tue, 10 Jun 2014 13:14:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DC693C1AA; Tue, 10 Jun 2014 16:14:27 -0400 (EDT) Date: Tue, 10 Jun 2014 16:14:27 -0400 From: Jeffrey Haas To: "George, Wes" Message-ID: <20140610201427.GF32305@pfrc> References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/cy0Y8rj0XTpVoLFwlrXkfb-UgY8 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:14:29 -0000 Wes, [snipping a lot of very good commentary that the authors should pay attention to.] On Tue, Jun 10, 2014 at 03:53:27PM -0400, George, Wes wrote: > >Given the above, what would you suggest? I realize what we want is a way > >to > >troubleshoot, but I'm not sure there can be any specific recommendation > >that > >will span the architectures well enough to be standardized. > WG] Well, I think there???s a valid traceability and troubleshooting > requirement in the form of needing the ability to do verification and > examination of the state and actions taken by I2RS agent(s) without > invoking the agent being examined. We don???t need to be prescriptive on the > format for that information, nor the method for providing that independent > avenue for accessing it, we must only note that it needs to be available. > For example, in a routing element that doesn???t really have a CLI, the > independent method doesn???t have to be via CLI, it could be via a web UI or > some pretty GUI if that???s the other method to manage the device. I mention > CLI as an example because for the most part, the fail-safe method for > interacting with the routing system today is indeed CLI. The traceability draft should hopefully give you the "what was requested" end of the auditing spectrum. (Please comment in that thread, if otherwise.) What I believe you're asking is roughly something like the following text in the architecture draft: X. Operational Considerations In order to facilitate troubleshooting of routing elements implementing I2RS agents, those routing elements should provide for a mechanism to show actively provisioned I2RS state. Note that this information may contain highly sensitive material subject to the Security Considerations of any data models implemented by that Agent and thus must be protected according to those considerations. ? -- Jeff From nobody Tue Jun 10 13:42:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913D1A045D for ; Tue, 10 Jun 2014 13:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sTJgGlj8Ii1 for ; Tue, 10 Jun 2014 13:42:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564071A03FF for ; Tue, 10 Jun 2014 13:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2907; q=dns/txt; s=iport; t=1402432933; x=1403642533; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XZ4Fr39VytHpbT5S+jq2HKAsWHvaygELXgvsnvQgX3k=; b=em3zZvfhrctBcX02Rqm78cDqspiXweo2lyyk19SAl335GRNvSkTc59PN Z2W9fzxumQsZH2FFb7qMhJlVbz/ftXTTnIsLNM2OcrdBnKrlGD9v/Ub3P CW2No9wH3dUtjzK28yOh5UDM13KPEluaXFfjzM9buJq5xTXMPhHVuc6i6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4KAGJtl1OtJV2S/2dsb2JhbABZgw2BK6pnAQEGmRIBgQoWdYQDAQEBAwEpTgIFCwIBAgYSBi4yFw4CBAENBRSIJgjNJxeFVohAMweDK4EWAQOJeZArk0WDPIIv X-IronPort-AV: E=Sophos;i="4.98,1011,1392163200"; d="scan'208";a="332121978" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2014 20:42:12 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5AKgCqS008238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 20:42:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 15:42:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Joel M. Halpern" , Jeffrey Haas , Juergen Schoenwaelder Thread-Topic: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt Thread-Index: AQHPhNoBaNEewmIPf0Gb6rI3yZPCJ5trByYAgAAI+wCAAAawAIAADDMA Importance: high X-Priority: 1 Date: Tue, 10 Jun 2014 20:42:11 +0000 Message-ID: <8CE1CDBC-BFCC-484F-92CC-C281F85C527B@cisco.com> References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <53976366.90001@joelhalpern.com> In-Reply-To: <53976366.90001@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.58] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <35048B5DFB491F4681F8734805BE10D4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ght7jQx2TO-duTREdYiVc_H3Ndk Cc: "i2rs@ietf.org" , "Joe Clarke \(jclarke\)" , "Gonzalo Salgueiro \(gsalguei\)" , "Carlos Pignataro \(cpignata\)" Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 20:42:15 -0000 Joel, Jeff, Juergen -=20 As stated, the intent of this draft is to specify in a logging-agnostic man= ner the minimum mandatory elements for I2RS traceability. I think we all a= gree this has real value and I don't view it as an obstacle in getting this= work done (IMO in I2RS WG). It seems the sticking point seems to be around the need for data modeling. = To be clear, there was no intent to constrain or specify a preferred loggi= ng format or protocol. In fact, this was intended to be similar to the mode= l used for SIP CLF where a format-agnostic data model (RFC6872) can be acco= mpanied by one or many format-specific specifications (RFC6873 as an exampl= e), as deemed necessary by the community. The original ABNF and subsequent= YANG was simply to provide a generic modeling of the mandatory logged elem= ents that were described in the text with only the most minimal constraints= possible imposed on character sets, etc based on the I2RS architecture. T= his was aimed at providing operation simplicity for implementors. If this = goal is not met or if it is mis-interpreted as anything other than a loggin= g format agnostic model, then it violates our prime directive and we can do= one of three things: 1. Add supplementary clarifying text to the data modeling section explainin= g the intent described above. 2. If YANG is perceived as having more of a NETCONF bias we can go back to = ABNF that is perhaps more universally viewed as protocol-agnostic. 3. Remove any data modeling elements from the draft entirely (ABNF or YANG = or otherwise). We're as interested as anyone in making sure this work remains logging form= at and protocol agnostic, so we will happily comply with the preferred WG d= irection. To this point, could we perhaps adopt this work in the I2RS WG (= presumably with all modeling removed) as a basis for defining the minimum m= andatory elements needed for a traceability model for I2RS? Thanks, Gonzalo On Jun 10, 2014, at 3:58 PM, Joel M. Halpern wrote: > Yes, I would agree that if the YANG model is dropped the document is both= useful and sufficiently clear. >=20 > Yours, > Joel >=20 > On 6/10/14, 3:34 PM, Jeffrey Haas wrote: >> On Tue, Jun 10, 2014 at 03:02:26PM -0400, Joel M. Halpern wrote: >>> In my personal view, it is clearly outside of our remit to reinvent >>> logging, no matter whether we like it or not. >>=20 >> Agreed. Not in-scope for I2RS currently. >>=20 >> Where would you suggest such work be done? >>=20 >>> As such, the structural specificity of a YANG model (or ABNF) simply >>> does not belong in this document. The clarity about what fields >>> will be logged is needed. >>=20 >> Would you agree that if the yang module is dropped that the info model i= s >> sufficiently clear for I2RS purposes? >>=20 >> -- Jeff >>=20 From nobody Tue Jun 10 14:07:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D4D1A02EC for ; Tue, 10 Jun 2014 14:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsIX-KVQfI2Q for ; Tue, 10 Jun 2014 14:06:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD591A02E3 for ; Tue, 10 Jun 2014 14:06:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 17FB4C1AA; Tue, 10 Jun 2014 17:06:37 -0400 (EDT) Date: Tue, 10 Jun 2014 17:06:37 -0400 From: Jeffrey Haas To: "Gonzalo Salgueiro (gsalguei)" Message-ID: <20140610210637.GB3265@pfrc> References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <53976366.90001@joelhalpern.com> <8CE1CDBC-BFCC-484F-92CC-C281F85C527B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CE1CDBC-BFCC-484F-92CC-C281F85C527B@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GNcneBxLHG5OkP6qoiACVqbpF1E Cc: "Carlos Pignataro \(cpignata\)" , "i2rs@ietf.org" , "Joe Clarke \(jclarke\)" , Juergen Schoenwaelder , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:06:39 -0000 On Tue, Jun 10, 2014 at 08:42:11PM +0000, Gonzalo Salgueiro (gsalguei) wrote: > We're as interested as anyone in making sure this work remains logging > format and protocol agnostic, so we will happily comply with the preferred > WG direction. To this point, could we perhaps adopt this work in the I2RS > WG (presumably with all modeling removed) as a basis for defining the > minimum mandatory elements needed for a traceability model for I2RS? As I've been telling people much of today in various correspondence, various adoption calls will be going out shortly. The traceability draft was one of the candidates. -- Jeff From nobody Tue Jun 10 14:08:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7531A01B9 for ; Tue, 10 Jun 2014 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9K5d-qEDVPH for ; Tue, 10 Jun 2014 14:08:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A8E1A0300 for ; Tue, 10 Jun 2014 14:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=840; q=dns/txt; s=iport; t=1402434479; x=1403644079; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QKTgcnNvyhx2lFT0/Af2xnRmpeQT6/NzJYroD+WKSQ0=; b=HPBTfNoY/jEy4aj78hZ8kLeNlVehVW5tBAXjhbRrSQxV2RN49GYWHMpF IX5tbFW9zmo1DmcZYobKPu9J6DxdeBsVmhy1THMgfPRMB9OrvTEsLfm9M 3mwaBG6RKwTKR8QlWyYJQ1Neq9XSyxg38fZqG7uNFXNHYfwzmRNZNX0hn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0KANxyl1OtJA2I/2dsb2JhbABZgw2BK6ppAQEGmRIBgQoWdYQDAQEBAwEpET0CBQsCAQIGDgoeEDIlAgQOBYg6CM0yF4VWiEAzB4MrgRYBA5okk0WDPIIv X-IronPort-AV: E=Sophos;i="4.98,1011,1392163200"; d="scan'208";a="51973201" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 10 Jun 2014 21:07:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5AL7viP009628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 21:07:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 16:07:57 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Jeffrey Haas Thread-Topic: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt Thread-Index: AQHPhNoBaNEewmIPf0Gb6rI3yZPCJ5trByYAgAAI+wCAAAawAIAADDMAgAAG1YCAAABdgA== Importance: high X-Priority: 1 Date: Tue, 10 Jun 2014 21:07:56 +0000 Message-ID: References: <20140607234311.1909.87378.idtracker@ietfa.amsl.com> <5393A47C.8020703@cisco.com> <5393B2E4.8020909@joelhalpern.com> <5395D2EC.2090409@cisco.com> <20140610183003.GJ20397@pfrc> <53975642.9060104@joelhalpern.com> <20140610193433.GB32305@pfrc> <53976366.90001@joelhalpern.com> <8CE1CDBC-BFCC-484F-92CC-C281F85C527B@cisco.com> <20140610210637.GB3265@pfrc> In-Reply-To: <20140610210637.GB3265@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.52.58] Content-Type: text/plain; charset="us-ascii" Content-ID: <570612511942EA46ACE57DC33CA3E549@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3ajssVYNwk9D1ZTYzygL0Yzs9zo Cc: "Joe Clarke \(jclarke\)" , "Carlos Pignataro \(cpignata\)" , "Joel M. Halpern" , Juergen Schoenwaelder , "i2rs@ietf.org" Subject: Re: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:08:06 -0000 On Jun 10, 2014, at 5:06 PM, Jeffrey Haas wrote: > On Tue, Jun 10, 2014 at 08:42:11PM +0000, Gonzalo Salgueiro (gsalguei) wr= ote: >> We're as interested as anyone in making sure this work remains logging >> format and protocol agnostic, so we will happily comply with the preferr= ed >> WG direction. To this point, could we perhaps adopt this work in the I2= RS >> WG (presumably with all modeling removed) as a basis for defining the >> minimum mandatory elements needed for a traceability model for I2RS? >=20 > As I've been telling people much of today in various correspondence, vari= ous > adoption calls will be going out shortly. The traceability draft was one= of > the candidates. Thanks, Jeff. It would certainly help us from a cat herding perspective ;-= ) -G >=20 > -- Jeff From nobody Tue Jun 10 17:21:36 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339B1A00DF for ; Tue, 10 Jun 2014 17:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4UXqjXt91Qi for ; Tue, 10 Jun 2014 17:21:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBEC1A0071 for ; Tue, 10 Jun 2014 17:21:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeffrey Haas'" References: <005c01cf802a$82407d80$86c17880$@ndzh.com> <20140610163052.GC20397@pfrc> In-Reply-To: <20140610163052.GC20397@pfrc> Date: Tue, 10 Jun 2014 20:21:31 -0400 Message-ID: <013901cf850b$18c54670$4a4fd350$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKXbswJiRI8mYZ+StEwp4D5wmEKygEroylNmdGiKcA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/3HxLc19c7IUVYP_JcAo55HTuDec Cc: i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 00:21:36 -0000 Jeff and I2RS: Thank for your feedback. With your OK, I will continue copying these to the use cases to the wiki. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Tuesday, June 10, 2014 12:31 PM To: Susan Hares Cc: i2rs@ietf.org; 'Jeffrey Haas'; Edward Crabbe Subject: Re: [i2rs] draft-white-i2rs-use-case-03.txt Sue, On Wed, Jun 04, 2014 at 03:23:47PM -0400, Susan Hares wrote: > I2RS WG: > > This use case draft has been changed to provide a numbered list of > requirements (per Jeff's request). The authors welcome feedback on > these changes. Thanks for doing this work. I think this enumerated break-out of the requirements strongly benefits the use case documents. As we work through the adoption cycle for the use case drafts, we'll likely copy these to the WG wiki to provide a summary across multiple documents. -- Jeff From nobody Tue Jun 10 22:46:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3B1A038A for ; Tue, 10 Jun 2014 22:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qlrq-0A804vq for ; Tue, 10 Jun 2014 22:46:24 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351201A0388 for ; Tue, 10 Jun 2014 22:46:24 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id p10so6352301wes.37 for ; Tue, 10 Jun 2014 22:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=lUFtFCE2xipaZumOsC5Ekd8gD5CJH5OYy2xB1ctLXPg=; b=ki6AV3aO+AR/NWhBzztZfUii1EHgEEbadbFZ+LJx9cCHvWBeD/olyNAqBYoymd8W8Q RvexbAzLQULUgi0wVRD7fGdAr8bQcKHmMEBIPo89mdRCkTzx1k4fQeDZIOO9+EOi6lKt raM1xFsz99/AhTRLdfroQk8z2B4SbuLM0VcqPc9FVpgi+GpuZt9j/5eHzKeifPS18iyO IoHfJKJtd7RylXfSRx90DNBzhK3dJTA9R4zreu9cgljIUxo3pBpr5mX0I8KjkBoZeCTJ om9hv975RXVuSaf7gP4RvJyWSZdpkIPN/5HCf7nhDjOQwtjsmZ1xSnFcNJuipkiMkRBF o/Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=lUFtFCE2xipaZumOsC5Ekd8gD5CJH5OYy2xB1ctLXPg=; b=HknQlI2thuOf/23rPpHSMH9a4xKc0n/5KQyWyv1FeflUoIlhFMUVW/f5sI726KLTDL XwUrqKBd/HVYwd4/uFWuYnqRQghuI3vxfiZlfretLL7+hK9qcSxjfS7MlkHchRh2bhrs 9VdQhB4ieStEb4St0sPXbU/IWl/6b5SlzLGLX/IV377bUKAplaz+nBIjBQ3KD2AhJVOw 1bFMsqx1RH/idDvbZbzEfuBsAh8d2tUTatyxHZJansX+/llsiiJP++DWOcAYuj02noGZ 6mWWyHk4DvyMpIK3JcebmyHglNxg2D34z5qxi6yqxv7DUS9SZPfMJE20xTwgPlNbXIJ1 1bog== X-Gm-Message-State: ALoCoQnA7iAhl/Vwo2Zj8Xm4jSpEfyPjiBgxbsXjw1jFBbEFQvkqiBHdy8O5kpSUu2CuY4ORJsWx X-Received: by 10.180.228.6 with SMTP id se6mr43829301wic.52.1402465582774; Tue, 10 Jun 2014 22:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.201 with HTTP; Tue, 10 Jun 2014 22:45:42 -0700 (PDT) From: Edward Crabbe Date: Tue, 10 Jun 2014 22:45:42 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a1135e398df1e3a04fb88f62e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/yk6Iq4MNk15W6Xb5lW2b5qilAlY Subject: [i2rs] I2RS WG Adoption Calls X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 05:46:25 -0000 --001a1135e398df1e3a04fb88f62e Content-Type: text/plain; charset=ISO-8859-1 All; Jeff and I are looking to adopt the following drafts, loosely grouped into the areas listed below: ================================ Protocol Functionality: ================================ draft-clarke-i2rs-traceability http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 draft-hares-i2rs-security http://tools.ietf.org/html/draft-hares-i2rs-security-00 ================================ Specific Use Cases: ================================ draft-keyupate-i2rs-bgp-usecases http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 draft-bitar-i2rs-service-chaining http://tools.ietf.org/html/draft-bitar-i2rs-service-chaining-01 draft-amante-i2rs-topology-use-cases-01 http://tools.ietf.org/html/draft-amante-i2rs-topology-use-cases-01 draft-white-i2rs-use-case http://tools.ietf.org/html/draft-white-i2rs-use-case-03 ================================ If the authors have no issue with adoption of the drafts in their current form we will be proceeding with individual adoption calls for each of the drafts. best, -Jeff and ed --001a1135e398df1e3a04fb88f62e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All;

Jeff and I are looking to adopt the following = drafts, loosely grouped into the areas listed below:

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Protocol Functionality:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

draft-clarke-i2rs-traceability
http://tools.ietf.org/html/draft-clarke= -i2rs-traceability-02


draft-hares-i2rs-security
http://tools.i= etf.org/html/draft-hares-i2rs-security-00


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Specific Use Cases:
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

draft-keyupate-i2rs-bgp-usecases
http://tools.ietf.org/html/d= raft-keyupate-i2rs-bgp-usecases-02

draft-bitar-i2rs-service-chaining
http://tools.ietf.org/html/draft-= bitar-i2rs-service-chaining-01


draft-amante-i2rs-topology-us= e-cases-01
http://tools.ietf.org/html/draft-amante-i2rs-topology-use-cases-01<= br>
draft-white-i2rs-use-case
http://tools.ietf.org/html/draft-white-i2rs-us= e-case-03

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If the authors = have no issue with adoption of the drafts in their current form we will be = proceeding with individual adoption calls for each of the drafts. =A0

best,
=A0 -Jeff and ed=A0
--001a1135e398df1e3a04fb88f62e-- From nobody Tue Jun 10 23:27:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22E1A0422 for ; Tue, 10 Jun 2014 23:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow_6AnYokiKw for ; Tue, 10 Jun 2014 23:27:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420131A03EC for ; Tue, 10 Jun 2014 23:27:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 735FF9A; Wed, 11 Jun 2014 08:27:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NgchPKp4DvoZ; Wed, 11 Jun 2014 08:27:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 11 Jun 2014 08:27:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E893E20017; Wed, 11 Jun 2014 08:27:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E5TNki3kldtr; Wed, 11 Jun 2014 08:27:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7373120013; Wed, 11 Jun 2014 08:27:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B0C02D61B95; Wed, 11 Jun 2014 08:27:13 +0200 (CEST) Date: Wed, 11 Jun 2014 08:27:12 +0200 From: Juergen Schoenwaelder To: Edward Crabbe Message-ID: <20140611062712.GB32389@elstar.local> Mail-Followup-To: Edward Crabbe , "i2rs@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/9_IiQXJPfkQLjKT4-bdC-xxclik Cc: "i2rs@ietf.org" Subject: Re: [i2rs] I2RS WG Adoption Calls X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 11 Jun 2014 06:27:20 -0000 On Tue, Jun 10, 2014 at 10:45:42PM -0700, Edward Crabbe wrote: > All; > > Jeff and I are looking to adopt the following drafts, loosely grouped into > the areas listed below: > > ================================ > Protocol Functionality: > ================================ > > draft-clarke-i2rs-traceability > http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 I do agree that traceability is an important requirement. I am wondering why this is not mentioned in draft-ietf-i2rs-architecture-03. If it would be discussed in the architecture draft, we likely would not need this I-D at this point in time (wait until we have a clearer view how i2rs will work on the wire so we better understand logging requirements or it might be that logging requirements should not be addressed just for i2rs but in general for the selected i2rs protocol). > draft-hares-i2rs-security > http://tools.ietf.org/html/draft-hares-i2rs-security-00 The author list is impressive, the actual contribution I find kind of limited at this point in time. It is not clear to me what exactly the contribution is nor is it clear to me why an expansion of the security architecture found in the i2rs architecture is needed. If an expansion is needed, why not put it into the i2rs architecture? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 11 03:20:12 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDAB1A04B8 for ; Wed, 11 Jun 2014 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zfaZW5WyQLV for ; Wed, 11 Jun 2014 03:19:55 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 051A41A044D for ; Wed, 11 Jun 2014 03:19:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Edward Crabbe'" References: <20140611062712.GB32389@elstar.local> In-Reply-To: <20140611062712.GB32389@elstar.local> Date: Wed, 11 Jun 2014 06:19:47 -0400 Message-ID: <01ac01cf855e$ac5b2c30$05118490$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcqk9r8sCCxha4LD7BiP4+LC2tPgJQXv6am77lgTA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/2p4kP2TJ58e2Fj1OLXHZJsxIJh4 Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS WG Adoption Calls X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 10:19:56 -0000 Juergen: You are correct. This is the initial draft that shows our thinking. A second draft was planned before IETF. I will hurry that up, and send within this review cycle. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, June 11, 2014 2:27 AM To: Edward Crabbe Cc: i2rs@ietf.org Subject: Re: [i2rs] I2RS WG Adoption Calls On Tue, Jun 10, 2014 at 10:45:42PM -0700, Edward Crabbe wrote: > All; > > Jeff and I are looking to adopt the following drafts, loosely grouped > into the areas listed below: > > ================================ > Protocol Functionality: > ================================ > > draft-clarke-i2rs-traceability > http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 I do agree that traceability is an important requirement. I am wondering why this is not mentioned in draft-ietf-i2rs-architecture-03. If it would be discussed in the architecture draft, we likely would not need this I-D at this point in time (wait until we have a clearer view how i2rs will work on the wire so we better understand logging requirements or it might be that logging requirements should not be addressed just for i2rs but in general for the selected i2rs protocol). > draft-hares-i2rs-security > http://tools.ietf.org/html/draft-hares-i2rs-security-00 The author list is impressive, the actual contribution I find kind of limited at this point in time. It is not clear to me what exactly the contribution is nor is it clear to me why an expansion of the security architecture found in the i2rs architecture is needed. If an expansion is needed, why not put it into the i2rs architecture? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Jun 11 04:57:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB681A03ED for ; Wed, 11 Jun 2014 04:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n0q2XRS4Rpz for ; Wed, 11 Jun 2014 04:56:53 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352D61A004B for ; Wed, 11 Jun 2014 04:56:52 -0700 (PDT) Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 11 Jun 2014 11:56:50 +0000 Message-ID: <044d01cf856b$cd49e280$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> Date: Wed, 11 Jun 2014 12:53:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA001.eurprd07.prod.outlook.com (10.242.16.41) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0239D46DB6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(189002)(199002)(51444003)(377454003)(83072002)(85852003)(61296002)(77156001)(89996001)(81816999)(80022001)(14496001)(66066001)(19580395003)(84392001)(102836001)(23756003)(87286001)(77982001)(62966002)(104166001)(88136002)(92566001)(92726001)(76176999)(50986999)(81542001)(87976001)(4396001)(76482001)(21056001)(42186004)(33646001)(44736004)(86362001)(93916002)(46102001)(62236002)(101416001)(79102001)(44716002)(50466002)(74502001)(19580405001)(83322001)(81342001)(47776003)(20776003)(50226001)(31966008)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR07MB062; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/LhhvKu8JR9xNvOxWmGcDNJtt7MM Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 11:56:56 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "t.petch" Cc: "Jeffrey Haas" ; Sent: Tuesday, June 10, 2014 2:41 PM > Tom, > > Thanks for the comments. > > > > I do find the I-D quite hard to follow as the terminology seems > > inconsistent - the word 'state' is much used but it is unclear to me if > > the term can be given a single definition in this context; and even if > > it can, the word seems an unfortunate choice since the IETF Ops Area has > > given it a precise definition which is at odds with its use here. > > Are there specific edits you would suggest to clarify the document? I think that the problem is pervasive. 'State' appears everywhere, starting with the Abstract in this I-D, and also on the list, and I really do not know what it means. It gets qualified - protocol state, active state, programmed state, routing-related state, operational state, structured information and state that is frequently not directly configurable, ephemeral state, dynamic system state, static system state etc. - but perhaps the killer phrase comes in 6.2 I2RS State Storage with "These sets of data form the I2RS data store." The model in the Ops Area, which might be familiar to those enthusiastic about YANG and NETCONF, is a split into 'config' and 'state' as in RFC6241, a split that was explicitly requested by Operators (RFC3535) so using the term state in a different sense here I struggle with. At least a definition is needed to contrast it with the Ops Area usage (but I am too unclear to offer such a definition). Tom Petch > -- Jeff From nobody Wed Jun 11 08:39:41 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD41A0185 for ; Wed, 11 Jun 2014 08:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsjsDQiColyZ for ; Wed, 11 Jun 2014 08:39:39 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DC11A017F for ; Wed, 11 Jun 2014 08:39:38 -0700 (PDT) Received: from AMXPRD0111HT003.eurprd01.prod.exchangelabs.com (157.56.250.117) by DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 11 Jun 2014 15:39:35 +0000 Message-ID: <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> Date: Wed, 11 Jun 2014 16:14:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AMXPR07CA003.eurprd07.prod.outlook.com (10.242.64.43) To DBXPR07MB062.eurprd07.prod.outlook.com (10.242.147.20) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0239D46DB6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(24454002)(51704005)(199002)(189002)(13464003)(79102001)(44716002)(101416001)(62236002)(46102001)(50466002)(42186004)(21056001)(76482001)(4396001)(33646001)(44736004)(86362001)(93916002)(50226001)(74662001)(31966008)(74502001)(20776003)(47776003)(83322001)(64706001)(19580405001)(81342001)(19580395003)(14496001)(66066001)(77156001)(80022001)(83072002)(85852003)(61296002)(89996001)(81816999)(50986999)(81686999)(76176999)(99396002)(87976001)(81542001)(87286001)(84392001)(102836001)(23756003)(77982001)(92726001)(92566001)(62966002)(104166001)(88136002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR07MB062; H:AMXPRD0111HT003.eurprd01.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Pr4w2uWcHwFuEuiSpCG-tEOSxnQ Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:39:41 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "t.petch" Cc: "Jeffrey Haas" ; Sent: Tuesday, June 10, 2014 7:07 PM > Tom, > > [retaining lots of content for context] now elided as it is not so much about references to extracts of the architecture I-D > On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: > > ---- Original Message ----- > > From: "Jeffrey Haas" > > To: "t.petch" > > Cc: "Jeffrey Haas" ; > > Sent: Tuesday, June 10, 2014 2:41 PM > > > > > Tom, > > > > > This is much of what I had suggested about the semantics of introducing > ephemeral config into netconf. Our requirement is that these things are > ephemeral. (Although Tom Nadeau presents some nice cases as to why we may > want the equivalent of "write running-config" to permit persistence.) > > At this point, overlapping ephemeral configuration isn't something that > netconf supports. If you scan mail from the last month or so, you'll also > see some back and forth between Juergen and Andy and I about how we go about > representing such a thing in the yang model/modules. (And we never fully > converged.) > > From the config perspective, this ephemeral state wasn't something that I > believe was part of the config semantics of netconf/yang; it's an I2RS > requirement. Admittedly, once we have such a think then clearly > applications other than I2RS can make use of it. :-) > > Choosing a solution space will be the next challenge we have: > - Overlapping modules with i2rs context? > - Parallel modules? > - How to ensure maximum re-use of the yang modules for config in an i2rs > context if they are determined to have heavy overlap? Jeff Yes, I saw the thread - I think I started it and ended it! Leaving aside the question of just what objects I2RS wants to edit that NETCONF cannot (perhaps none:-), the rest of that thread seems clear to me. The architecture I-D talks of data store which I think unclear; I think that it should be datastore, as used in Ops Area (e.g. by NETCONF). The view that has evolved, and is reflected in the thread, is that NETCONF 'config true' is not really the configuration. The real configuration is the operational state, part learnt from protocols and hardware and part derived from 'config true'; but 'config true' is only what the operator would like to happen, the operational state is the reality. Currently we only have 'config true' written by NETCONF in a configuration datastore (with operational state not being part of any datastore, just part of state, using that term in the Ops Area sense). What I2RS then adds is an I2RS datastore, may be one, may be several, which is another expression of hope as to what the box will do; operational state, as ever, tells us what actually happens. The rules of persistence for I2RS are whatever I2RS wants them to be with no impact on NETCONF. So I suggest that it is wrong, as I and others have said in the past, to talk of editing operational state; the writing of the basic NETMOD models have shown that that does not work. The model that has evolved is what I call twin trees, one of 'config true' - an aspiration of the operator - and the other of 'config false' - operational state, the reality. You can see signs of this in the NETMOD models of interfaces-cfg, routing-cfg, system-cfg and so on. I2RS then adds a third tree to the model, of what it would like the box to do. I2RS would also need to specify how to resolve conflicts between NETCONF and I2RS should they specify different values for the same object. This is already an issue, IMO not fully resolved, when the user and the system have different views of what should happen - look for user-controlled and system-controlled in interfaces-cfg. So one module, three trees, an additional YANG substatement for a leaf that is writable by I2RS. Tom Petch > > 6.4.2" o writing policy information such as interface attributes that > > are > > specific to the routing protocol or BGP policy that may indirectly > > manipulate attributes of routes carried in BGP. > > > > o writing routes or prefixes to be advertised via the protocol" > > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the > > I-D goes on to say > > " direct modification of the link-state database MUST NOT be allowed" > > (which I have seen on the list w.r.t. the BGP RIB). > > > > or > > > > 8" The interaction of state installed via the I2RS and via a router's > > configuration needs to be clearly defined." > > which again implies that I2RS and C/N/S are writing to the same data. > > *Maybe.* > > In some cases, the overlap with config state will be quite obvious and your > observation will strongly hold. > > In other cases, I think a better perspective is that I2RS injected state is > effectively like that of another routing protocol. > > If you'd like to argue that BGP is effectively the same as C/N/S... well, if > we're talking Flowspec I might agree. :-) > > > The examples of data that can be changed are few, such as > > "For example, the interaction with OSPF might include modifying the > > local routing element's link metrics, announcing a locally-attached > > prefix, .." > > which leaves me wondering, do you expect an OSPF YANG model to be unable > > to change a link metric:-) > > Sure. In a highly dynamic fashion? With a fallback to a default config when > the application is done? > > By comparison to some vendor specific features, it's somewhat the difference > between a policy database (config) and the dynamic policy API that doesn't > require a system reconfiguration event. If you want to point out that the > relationship is strong and that the defining differences are shallow - you > could very well be right in those contexts. > > Again, we don't expect I2RS work to supplant netconf/yang. We expect to > leverage the work. > > > If I2RS were aiming at a higher level, say specifying policy and have > > the system translate that into actual config changes I would understand > > that, but I do not see I2RS going that far, rather when I2RS says > > policy, I think it means changing a community (config again) or some > > such ie more of an implementation detail than a high level strategy. > > I hesitate to frame it this way, but one example application is a form of > SDN. The front end says "provision this VPN" to a data model for that > purpose. The fact that it may go behind the covers via client->agent and > eventually install ephemeral netconf state is an implementation detail. > > If you want to argue that such a higher level model is simply netconf, then > perhaps we should de-charter and do all of the work in that group. I was, > however, under the impression that work for various models was being pushed > to be done in appropriate working groups. :-) > > -- Jeff From nobody Wed Jun 11 08:45:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5881A01DC for ; Wed, 11 Jun 2014 08:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE55BDnkR-5k for ; Wed, 11 Jun 2014 08:45:27 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E2C1A0190 for ; Wed, 11 Jun 2014 08:45:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 98AB7240863; Wed, 11 Jun 2014 08:45:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 86A9F240E0D; Wed, 11 Jun 2014 08:45:26 -0700 (PDT) Message-ID: <5398799B.6000908@joelhalpern.com> Date: Wed, 11 Jun 2014 11:45:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "t.petch" , Jeffrey Haas References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> In-Reply-To: <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HbcdZJEk22BL2qBMdVzZisoHeng Cc: i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:45:29 -0000 I would agree to calling it a YANG datastore if the archtiecture was to be conditioned on the data model. As I understand it, we are not supposed to put the horse and cart in that order. So I prefer the less specific wording we now use. Yours, Joel On 6/11/14, 11:14 AM, t.petch wrote: > ----- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: "Jeffrey Haas" ; > Sent: Tuesday, June 10, 2014 7:07 PM >> Tom, >> >> [retaining lots of content for context] > > now elided as it is not so much about references to extracts of the > architecture I-D > >> On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: >>> ---- Original Message ----- >>> From: "Jeffrey Haas" >>> To: "t.petch" >>> Cc: "Jeffrey Haas" ; >>> Sent: Tuesday, June 10, 2014 2:41 PM >>> >>>> Tom, >>>> > >> >> This is much of what I had suggested about the semantics of > introducing >> ephemeral config into netconf. Our requirement is that these things > are >> ephemeral. (Although Tom Nadeau presents some nice cases as to why we > may >> want the equivalent of "write running-config" to permit persistence.) >> >> At this point, overlapping ephemeral configuration isn't something > that >> netconf supports. If you scan mail from the last month or so, you'll > also >> see some back and forth between Juergen and Andy and I about how we go > about >> representing such a thing in the yang model/modules. (And we never > fully >> converged.) >> >> From the config perspective, this ephemeral state wasn't something > that I >> believe was part of the config semantics of netconf/yang; it's an I2RS >> requirement. Admittedly, once we have such a think then clearly >> applications other than I2RS can make use of it. :-) >> >> Choosing a solution space will be the next challenge we have: >> - Overlapping modules with i2rs context? >> - Parallel modules? >> - How to ensure maximum re-use of the yang modules for config in an > i2rs >> context if they are determined to have heavy overlap? > > Jeff > > Yes, I saw the thread - I think I started it and ended it! > > Leaving aside the question of just what objects I2RS wants to edit that > NETCONF cannot (perhaps none:-), the rest of that thread seems clear to > me. > > The architecture I-D talks of data store which I think unclear; I think > that it should be datastore, as used in Ops Area (e.g. by NETCONF). > > The view that has evolved, and is reflected in the thread, is that > NETCONF 'config true' is not really the configuration. The real > configuration is the operational state, part learnt from protocols and > hardware and part derived from 'config true'; but 'config true' is only > what the operator would like to happen, the operational state is the > reality. > > Currently we only have 'config true' written by NETCONF in a > configuration datastore (with operational state not being part of any > datastore, just part of state, using that term in the Ops Area sense). > What I2RS then adds is an I2RS datastore, may be one, may be several, > which is another expression of hope as to what the box will do; > operational state, as ever, tells us what actually happens. The rules > of persistence for I2RS are whatever I2RS wants them to be with no > impact on NETCONF. > > So I suggest that it is wrong, as I and others have said in the past, to > talk of editing operational state; the writing of the basic NETMOD > models have shown that that does not work. The model that has evolved > is what I call twin trees, one of 'config true' - an aspiration of the > operator - and the other of 'config false' - operational state, the > reality. You can see signs of this in the NETMOD models of > interfaces-cfg, routing-cfg, system-cfg and so on. > > I2RS then adds a third tree to the model, of what it would like the box > to do. I2RS would also need to specify how to resolve conflicts between > NETCONF and I2RS should they specify different values for the same > object. This is already an issue, IMO not fully resolved, when the user > and the system have different views of what should happen - look for > user-controlled and system-controlled in interfaces-cfg. > > So one module, three trees, an additional YANG substatement for a leaf > that is writable by I2RS. > > Tom Petch > > >>> 6.4.2" o writing policy information such as interface attributes > that >>> are >>> specific to the routing protocol or BGP policy that may > indirectly >>> manipulate attributes of routes carried in BGP. >>> >>> o writing routes or prefixes to be advertised via the protocol" >>> I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but > the >>> I-D goes on to say >>> " direct modification of the link-state database MUST NOT be > allowed" >>> (which I have seen on the list w.r.t. the BGP RIB). >>> >>> or >>> >>> 8" The interaction of state installed via the I2RS and via a > router's >>> configuration needs to be clearly defined." >>> which again implies that I2RS and C/N/S are writing to the same > data. >> >> *Maybe.* >> >> In some cases, the overlap with config state will be quite obvious and > your >> observation will strongly hold. >> >> In other cases, I think a better perspective is that I2RS injected > state is >> effectively like that of another routing protocol. >> >> If you'd like to argue that BGP is effectively the same as C/N/S... > well, if >> we're talking Flowspec I might agree. :-) >> >>> The examples of data that can be changed are few, such as >>> "For example, the interaction with OSPF might include modifying the >>> local routing element's link metrics, announcing a > locally-attached >>> prefix, .." >>> which leaves me wondering, do you expect an OSPF YANG model to be > unable >>> to change a link metric:-) >> >> Sure. In a highly dynamic fashion? With a fallback to a default > config when >> the application is done? >> >> By comparison to some vendor specific features, it's somewhat the > difference >> between a policy database (config) and the dynamic policy API that > doesn't >> require a system reconfiguration event. If you want to point out that > the >> relationship is strong and that the defining differences are shallow - > you >> could very well be right in those contexts. >> >> Again, we don't expect I2RS work to supplant netconf/yang. We expect > to >> leverage the work. >> >>> If I2RS were aiming at a higher level, say specifying policy and > have >>> the system translate that into actual config changes I would > understand >>> that, but I do not see I2RS going that far, rather when I2RS says >>> policy, I think it means changing a community (config again) or some >>> such ie more of an implementation detail than a high level strategy. >> >> I hesitate to frame it this way, but one example application is a form > of >> SDN. The front end says "provision this VPN" to a data model for that >> purpose. The fact that it may go behind the covers via client->agent > and >> eventually install ephemeral netconf state is an implementation > detail. >> >> If you want to argue that such a higher level model is simply netconf, > then >> perhaps we should de-charter and do all of the work in that group. I > was, >> however, under the impression that work for various models was being > pushed >> to be done in appropriate working groups. :-) >> >> -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Jun 11 09:33:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6BB1B27C7 for ; Wed, 11 Jun 2014 09:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8f55gCISRxi for ; Wed, 11 Jun 2014 09:33:40 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7971A016C for ; Wed, 11 Jun 2014 09:33:39 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so945459wes.33 for ; Wed, 11 Jun 2014 09:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=gqWW29Na8W39aI7LY6MH04LNmFmdNK4qPra6cDdBxn8=; b=cZLg4CZxLZytsVRJ/HfePWvKFPPxwjKAMe424LwtP2yKnv5by6vKi3iKCo7icAM+mh isp6mNGr/jmpWkvSdjCMU3s5uikLP+ad0EH4LWoM0vIiFrucnO3p6lWJNFG5jCuY7Z/9 VuiRPTwb7Yv4VBOp2KgPI20Rx7GIqeL4YGHon8RYn0gNgQipUeO1UHfcoGG1y6V/x+m3 S6NYXSRc7hHkV2zby1qM5QxhTTFVZChpOqibhSwiqpDd47/4a524dUhaYqMysaRipPoN +McJWpqjoV9WO7BpRSaXfhsucx7lXklrhJnUxBkjIZF1k8S6c+Y8tDKeMerxoJg4a+Kk f/ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=gqWW29Na8W39aI7LY6MH04LNmFmdNK4qPra6cDdBxn8=; b=NjfgmnclEbNA/fQbPsNKXZPHLFgPh90gpt5CHn232MR+APdLYJW1rgzkS0/x5vQ6eo YK3ZqpgHYmCHZ9qDFymgxZCjLfHMCJH4y0RxTIPBGu1m/CS3Hf36jCziDmobfXxBj5S+ mY26xo6Q679xcWXQcid3kJNci1BcsHGKddYSGhDbA8SBjHscp8xwiN1NShpimViZdWhv 3Ymu2Kf/efSvECJNbGX5aV0BtZbL8GpZ5cAm1kCQIpweS4eja4fMhbVTr51TeKO5VOQV 9gyPeudFuvfp579QG69Y5BqitqXIOzi6wyD+qVhKjepcYsEaNpEYz3p4inG4FKGQi9O7 7LZA== X-Gm-Message-State: ALoCoQlp5hDHsXUhPayM8dhdaZ4XTLBr0PquDL69gNOMfAkp60WeyupPcrYDRtepYbO++d1bVk7g X-Received: by 10.194.93.228 with SMTP id cx4mr10221366wjb.61.1402504418529; Wed, 11 Jun 2014 09:33:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.201 with HTTP; Wed, 11 Jun 2014 09:32:58 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Wed, 11 Jun 2014 09:32:58 -0700 Message-ID: To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03cfaa9b4e504fb920187 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wBQMih2SyzhPAu86K-qsbO0gdUg Subject: [i2rs] Fwd: Improving and Restructuring the Routing Area X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:33:43 -0000 --047d7bb03cfaa9b4e504fb920187 Content-Type: text/plain; charset=ISO-8859-1 Hey all; Just a heads up: there's a thread starting about this on the "routing-discussion" mailing list. ---------- Forwarded message ---------- From: Alia Atlas Date: Tue, Jun 10, 2014 at 3:57 PM Subject: Improving and Restructuring the Routing Area To: routing-discussion@ietf.org To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. October 2014: Formal rechartering process completes. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable goals. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian --047d7bb03cfaa9b4e504fb920187 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hey all;

Just a heads up: there’s a th= read starting about this on the "routing-discussion" mailing list= .


---------- Forwarded message ----------=
From: Alia Atlas &l= t;akatlas@gmail.com<= /a>>
Date: Tue, Jun 10, 2014 at 3:57 PM
Subject: Improving and Restructuring = the Routing Area
To: routing-discussion@ietf.org


<= div> To all participants in the Routing Area,

Adrian and I are working on improving the quality, spee= d, and
experience of getting work done in the IETF Routing Area. =  There are
three initiatives that we are working: WG Draft QA, Routing Area
=
specific WG chair training, and reorganizing the working groups in the=
area.

First, we intend to use our Routi= ng Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will revie= w
a draft during WG draft adoption and during WG last call.  = ;The process
will be documented on the Routing Area wiki
dir= ectorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release note= s).

Second, as was discussed during the recent IES= G retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics=
such as judging consensus, project management, motivating volunt= eers,
using the datatracker (via a sandbox version that can be played
<= div>with safely), and sharing experiences between WG chairs.

=
Third, we intend to reorganize the working groups in the Routing= area.
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new = work
into the area.  As you know, we have had several new wo= rking groups
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in.  W= e would
also like to improve the signal-to-noise ratio experience= d by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews.  It is likely that no= t all WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.
   NOW: public discussion on routing-discussion@ietf.org a= bout how to
   reorganize the working groups to best meet our motivation= s.
   Additional focused discussions are expected on the
<= div>   r= tg-chairs@ietf.org and rtg-dir@ietf.org mailing lists.

   In Toronto: There will be meetings with the WG chai= rs and the
   Routing Directorate to get the ideas desc= ribed and agreed upon.

   At the Routing= Area Meeting in Toronto: Discuss the set of
   reorganized WGs and general charter content in the Routin= g Area
   meeting.

  &nbs= p;September 2014: Based upon the feedback, suggestions, and
 = ;  discussion, Adrian and I finalize the reorganized WG charters. &nbs= p;We
   start the internal IESG discussion and public reviews.

   October 2014: Formal rechartering proce= ss completes.

   In Honolulu: The new se= t of WGs meet.

   After Honolulu: Adrian and I deal with any issues a= nd charter
   updates based upon a few months of experi= ence.

Here are the motivations that Adrian and I w= ould like to be considered
when coming up with ideas for how the WGs should be reorganized.
=

   1) Move towards organizing working groups = on functional
   responsibilities rather than scoping t= hem to specific protocols.

   2) Split giant working groups so relevant = work is done in one place
   and there is an improved s= ignal-to-noise ratio for participants who
   are only i= nterested in a slice of the current working group's work.

   3) Create synergies for scattered function= ality (example ideas:
   OAM, FRR, traffic-engineering)=

   4) Create a DISPATCH working group f= or clear new idea discussion;
   rtgwg serves some of this purpose but doesn't have a = clear process
   and isn't drawing in the new ideas= .

   5) Focus Routing Area time on desig= n centers rather than on far
   corner cases.

   6) Ea= ch working group should have clear, well defined, and achievable goals.

Noting that the Routing Area has inherited some of it= s WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of t= his reorganization is not closing working groups.  Adrian
an= d Alia are perfectly capable of closing working groups without going
through restructuring.

For those of you that = have read this far, thank you.  Getting this 80%
right is go= ing to take some serious discussion and thought.  We all
wor= k in the Routing Area together with different perspectives.  Please
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian



--047d7bb03cfaa9b4e504fb920187-- From nobody Wed Jun 11 10:09:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00151A01F6 for ; Wed, 11 Jun 2014 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vkvOTVHUSdl for ; Wed, 11 Jun 2014 10:09:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C8E1A01A7 for ; Wed, 11 Jun 2014 10:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1630; q=dns/txt; s=iport; t=1402506543; x=1403716143; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gs4u4HOa+cr6Tx48i58PBq7cPS+pp5lxNpHU3Wj0ib4=; b=Q2kGQiC+X2ev0ngGfqLo90hsc9fA60BgFOp2WhorqlrKCY4NDDNvNhkl h1eusiK20+902BQyldDB5CiZfo2/baWvUFoR7IOyR1u0tEkJQCxnWg1GC +OO1mlkPHDVGLXLHQkjci8mkvALOONPr3xEw1kpE1OrOXHFcnuS5sF3Kb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAMaMmFOtJA2K/2dsb2JhbABagw1SqzUBAQEBAQEFAZkbAYEHFnWEAwEBAQR4EQsSBgkWDwkDAgECATcOBg0IAQGIPg3PfxeFXIhKOoRBAQOaLoFCkgmDWCE X-IronPort-AV: E=Sophos;i="5.01,459,1400025600"; d="scan'208";a="332368245" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jun 2014 17:08:53 +0000 Received: from dhcp-10-150-54-120.cisco.com (dhcp-10-150-54-120.cisco.com [10.150.54.120]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5BH8rSi012054 for ; Wed, 11 Jun 2014 17:08:53 GMT Message-ID: <53988D24.1050205@cisco.com> Date: Wed, 11 Jun 2014 13:08:52 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20140611062712.GB32389@elstar.local> In-Reply-To: <20140611062712.GB32389@elstar.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oawSOVAvpnDNddPc6UMTSA3l2hg Subject: Re: [i2rs] I2RS WG Adoption Calls X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:09:05 -0000 On 6/11/14, 2:27 AM, Juergen Schoenwaelder wrote: > On Tue, Jun 10, 2014 at 10:45:42PM -0700, Edward Crabbe wrote: >> All; >> >> Jeff and I are looking to adopt the following drafts, loosely grouped into >> the areas listed below: >> >> ================================ >> Protocol Functionality: >> ================================ >> >> draft-clarke-i2rs-traceability >> http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02 > > I do agree that traceability is an important requirement. I am > wondering why this is not mentioned in draft-ietf-i2rs-architecture-03. > If it would be discussed in the architecture draft, we likely would > not need this I-D at this point in time (wait until we have a clearer > view how i2rs will work on the wire so we better understand logging > requirements or it might be that logging requirements should not be > addressed just for i2rs but in general for the selected i2rs > protocol). One of the reasons this draft is separate was a desire from the architecture draft authors to have this stand as its own document. This work is important enough to merit such attention IMHO. We feel strongly this work should be done in the I2RS WG because this we want this to evolve with choices made by the WG with respect to protocol. This should be an effort to define elements for proper I2RS traceability independent of protocol or format. Those protocol-specific implementations of this I2RS Traceability can happen in their respective WGs. Keeping this tightly aligned to I2RS makes things easier and prevents a never-ending bike shed debate. Joe From nobody Wed Jun 11 18:08:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10D1B2924 for ; Wed, 11 Jun 2014 18:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.146 X-Spam-Level: ** X-Spam-Status: No, score=2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_22=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTsgolDckUeU for ; Wed, 11 Jun 2014 18:08:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 441171B291B for ; Wed, 11 Jun 2014 18:08:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.4.95; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> In-Reply-To: <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> Date: Wed, 11 Jun 2014 21:08:22 -0400 Message-ID: <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CF_01CF85B9.47813DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qAGayTg4AbY3QWQChw5Z8wECQGW8mvyl9qA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bsJn-j08TvPLSjLgvSPhlo_ws6o Cc: i2rs@ietf.org, 'Susan Hares' , rex@cisco.com, "'t.petch'" , "'Keyur Patel \(keyupate\)'" , 'Hannes Gredler' , 'Russ White' Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 01:08:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CF_01CF85B9.47813DD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D0_01CF85B9.47813DD0" ------=_NextPart_001_00D0_01CF85B9.47813DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean: I combined REQ01/02 and REQ08/09. I've put the requirements in the front of the text. Please let know if have any suggestions on these approved changes. I wait 24 hours, and then spin the draft. On the agreement on REQ04, I cannot find a firm consensus. I would ask Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on the WG. I highlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus. Sue Hares Search for Consensus ===== Based on your comment, I sent looking for WG Direction regarding BGP or I2RS putting state. I cannot find it. BGP has a Flow specification (RFC5575). Where do you think those flow specifications end up? Writing into runtime configuration state? Writing into something like I2RS running data store? BGP ORFs might be kept in the BGP state or in associated features (Add/delete) in BGP, but Flow specifications are targeted toward data flow. On the list I could find the following: 1. I2RS BGP state to configuration - Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is the debate for the architecture document regarding keeping state in the I2RS Begin: http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Joel's: no state across a reboot: http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html 3. Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Multiple clients writing to agents (raised by Himanshu Shah) http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html Jeff (chair hat off) states he does not want to have I2rs changing state tables come from routing protocols (BGP--> I2RS state). He also feel dynamic state tables should be read-only, and not writable as suggested by the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html In the same thread, Sri states the I2RS agent should not provide an interface to change a table if there is no use-case to support it. Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri states " I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case." However, here it has been in the BGP use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html Jeff responds to Sri in tends to agree and does not mention the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html Sue Hares -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; ; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Reachability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you get to the very and where all requirements are listed and then it makes sense. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should impose persistent policies? It says it should be recorded in the configuration of the local device. I agree that those policies should be visible to operators and other applications, but not sure if dynamic protocols should be allowed to implement persistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the running or ephemeral configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a good idea. If you plan to change only what is configured on the local device, then that is OK, but if you start changing entries that are pushed from other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourselves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" > To: > Cc: "'Keyur Patel (keyupate)'" ; "Hannes Gredler" > ; "Russ White" ; "'Susan Hares'" > ; > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_001_00D0_01CF85B9.47813DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean: =

 

I combined REQ01/02 = and REQ08/09.  I've put the requirements in the front of the = text.  Please let know if have any suggestions on these approved = changes.  I wait 24 hours, and then spin the draft. =

 

On the agreement on = REQ04, I cannot find a firm consensus.  I would ask Jeff Haas or Ed = Crabbe to indicate if they think there is a consensus on the WG. I = highlight a few messages below. The document is proposed for WG = consensus so I will change it if the WG has consensus. =

 

 

Sue Hares =

 

 

Search for = Consensus

=3D=3D=3D=3D=3D

Based on your = comment, I sent looking for WG Direction regarding BGP or I2RS putting = state.   I cannot find it.  BGP has a Flow specification = (RFC5575).  Where do you think those flow specifications end = up?  Writing into runtime configuration state? Writing into = something like I2RS running data store?  BGP ORFs might be kept in = the BGP state or in associated features (Add/delete) in BGP, but Flow = specifications are targeted toward data flow.

 

On the list I could = find the following:

 

1. I2RS BGP state = to configuration - Wes George (operator) makes a comment that I2RS = configuration should not replace current configuration related to = BGP. 

 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html<= /o:p>

 

 

 

2. There is the = Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is = the debate for the architecture document regarding keeping state in the = I2RS

Begin:  =

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html<= /o:p>

 

Joel's: no state = across a reboot: 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html<= /o:p>

 

 

3. Wes George = (operator) makes a comment that I2RS configuration should not replace = current configuration related to BGP. 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html<= /o:p>

 

 

There is the = Architecture Discussion 2: Persistence (ephemeral vs. = permanent)

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html<= /o:p>

 

 

Multiple clients = writing to agents (raised by Himanshu Shah)

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html<= /o:p>

 

 

Jeff (chair hat = off) states he does not want to have I2rs changing state tables come = from routing protocols (BGP--> I2RS state).  He also feel = dynamic state tables should be read-only, and not writable as suggested = by the use case.

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html<= /o:p>

 

 

In the same thread, = Sri states the I2RS agent should not provide an interface to change a = table if there is no use-case to support it.  Dynamic protocols = --> I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri = states " I am yet to see a use-case that requires direct = manipulation of a single dynamic routing-protocol-instance specific = route table by something other than that protocol. I don't believe there = should be any such case."    However, here it has = been in the BGP use case.

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html<= /o:p>

 

 

Jeff responds to = Sri in tends to agree and does not mention the use case. =

= http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html<= /o:p>

 

 

Sue = Hares

 

-----Original Message-----

From: Dean Bogdanovic [mailto:deanb@juniper.net] =

Sent: Friday, June 06, 2014 4:03 = PM

To: Susan = Hares

Cc: t.petch; = <i2rs@ietf.org>; Keyur Patel (keyupate); Hannes Gredler; Russ = White; Susan Hares; <rex@cisco.com>

Subject: Re: [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

 

Susan,

 

Many = people don't know what NLRI abbreviation stands for (Network Layer = Reachability Information , so writing it out first time would be a good = idea.

 

Throughout the text, the requirement number = sequence is confusing until you get to the very and where all = requirements are listed and then it makes sense.

 

REQ04: = The ability to interact with various policies configured = on

      = the forwarding devices, in order to inform the policies

      implemented by the = dynamic routing processes.  This interaction

      should be through = existing configuration mechanisms, such as

      NETCONF, and should = be recorded in the configuration of the local

      device so operators = are aware of the full policy implemented in

      the network from the = running configuration.

It is not = clear to me if your requirement is that dynamic protocols should impose = persistent policies? It says it should be recorded in the configuration = of the local device.

 

I = agree that those policies should be visible to operators and other = applications, but not sure if dynamic protocols should be allowed to = implement persistent policies. IMO, those should be ephemeral = policies.

So maybe text should = look like this

This interaction = should be through existing configuration mechanisms, such as NETCONF, = and should be recorded in the running or ephemeral configuration of the = local device so operators are aware of the full policy implemented in = the network from the running configuration.

 

I'm = trying to see major difference between REQ01/REQ02 and = REQ08/REQ09?

 

In = general I'm not sure if changing entries by dynamic protocol in RIB is a = good idea. If you plan to change only what is configured on the local = device, then that is OK, but if you start changing entries that are = pushed from other devices in the network, the system would get unstable. = And it looks to me that REQ09 would allow that.

 

Dean

 

 

On Jun = 5, 2014, at 4:47 AM, Susan Hares <shares@ndzh.com> = wrote:

 

> Tom:

>

> = I'm glad to change the citation in the abstract.    On = the authors, this was

> merge = of two drafts.

> =

> Sue

>

> = -----Original Message-----

> = From: t.petch [mailto:ietfc@btconnect.com]

> Sent: Thursday, June 05, 2014 4:35 = AM

> To: Susan Hares; = i2rs@ietf.org

> Cc: 'Keyur = Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan

> Hares'; rex@cisco.com

> Subject: Re: [i2rs] FW: I-D Action: =

> = draft-keyupate-i2rs-bgp-usecases-02.txt

>

> = Sue

>

> Currently you have six authors which is too = many for an RFC - someone's

> = got to go!   For me, this is not just an admin point - when = commenting,

> I like to have = one or two names, no more, as the clear pen holders

> whom I can expect to act.  Too often, = with so many names, everyone

> = thinks that someone else will do something and nothing happens, so, in =

> all seriousness, I oppose = adoption until you sort this out amongst yourselves.

>

> = Note too that you have a citation in the Abstract, again not allowed - =

> this can be surprising = difficult to get round but get round it you,

> one or more thereof, must.

>

> = Tom Petch

>

>

> = ----- Original Message -----

> = From: "Susan Hares" <shares@ndzh.com>

> To: <i2rs@ietf.org>

> Cc: "'Keyur Patel (keyupate)'" = <keyupate@cisco.com>; "Hannes Gredler"

> <hannes@juniper.net>; "Russ = White" <russw@riw.us>; "'Susan = Hares'"

> = <skh@ndzh.com>; <rex@cisco.com>

> Sent: Wednesday, June 04, 2014 7:49 = PM

> Subject: [i2rs] FW: I-D = Action:

> = draft-keyupate-i2rs-bgp-usecases-02.txt

>

> =

>> Jeff and = Ed:

>>

>> This updated draft has all the changes = that Keyur Patel promised and

> = updates

>> to the reference = the current i2rs internet drafts.

>>

>> Would you please do a Working Group = adoption call?

>> =

>> Thank = you,

>> Sue = Hares

>>

>>

>> -----Original = Message-----

>> From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of

>> internet-drafts@ietf.org

>> Sent: Wednesday, June 04, 2014 1:44 = PM

>> To: = i-d-announce@ietf.org

>> Cc: = i2rs@ietf.org

>> Subject: = [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

>>

>>

>> A New Internet-Draft is available from the = on-line Internet-Drafts

>> = directories.

>> This draft = is a work item of the Interface to the Routing System

> Working

>> Group of the IETF.

>>

>>        = Title           : Use = Cases for an Interface to BGP Protocol

>>        = Authors         : Keyur = Patel

>>       &n= bsp;           &nb= sp;      Rex Fernando

>>       &n= bsp;           &nb= sp;      Hannes Gredler

>>       &n= bsp;           &nb= sp;      Shane Amante

>>       &n= bsp;           &nb= sp;      Russ White

>>       &n= bsp;           &nb= sp;      Susan Hares

>> = Filename        : = draft-keyupate-i2rs-bgp-usecases-02.txt

>> = Pages           : = 17

>> = Date            : = 2014-06-04

>> =

>> = Abstract:

>>   A = network routing protocol like BGP is typically configured = and

>>   analyzed = through some form of Command Line Interface (CLI) or

>>   NETCONF.  These = interactions to control BGP and diagnose its

>>   operation encompass: = configuration of protocol parameters, display

> of

>>   protocol data, setting of = certain protocol state and debugging of

> the

>>   protocol.

>>

>>   Interface to the Routing = System's (I2RS) Programmatic interfaces,

> as

>>   defined in = draft-ietf-i2rs-architecture, provides an alternate way

> to

>>   control and diagnose the = operation of the BGP protocol.  I2RS may

> be

>>   used for the configuration, = manipulation, analyzing or collecting

> the

>>   protocol data.  This = document describes set of use cases for which

>>   I2RS can be used for BGP = protocol.  It is intended to provide a

> base

>>   for the solution draft = describing a set of interfaces to the BGP

>>   protocol.

>>

>>

>> The IETF datatracker status page for this = draft is:

>> = https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/

>>

>> There's also a htmlized version available = at:

>> = http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02=

>>

>> A diff from the previous version is = available at:

>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02

>>

>>

>> Please note that it may take a couple of = minutes from the time of

> = submission

>> until the = htmlized version and diff are available at = tools.ietf.org.

>> =

>> Internet-Drafts are also = available by anonymous FTP at:

>> = ftp://ftp.ietf.org/internet-drafts/

>>

>> = _______________________________________________

>> i2rs mailing list

>> i2rs@ietf.org

>> = https://www.ietf.org/mailman/listinfo/i2rs

>>

>> = _______________________________________________

>> i2rs mailing list

>> i2rs@ietf.org

>> = https://www.ietf.org/mailman/listinfo/i2rs

>>

>

> =

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org

> = https://www.ietf.org/mailman/listinfo/i2rs

 

------=_NextPart_001_00D0_01CF85B9.47813DD0-- ------=_NextPart_000_00CF_01CF85B9.47813DD0 Content-Type: text/plain; name="draft-keyupate-i2rs-bgp-usecases-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-keyupate-i2rs-bgp-usecases-03.txt" =0A= =0A= =0A= =0A= I2RS Working Group K. Patel=0A= Internet-Draft R. Fernando=0A= Intended status: Informational Cisco Systems=0A= Expires: December 13, 2014 H. Gredler=0A= Juniper Networks=0A= S. Amante=0A= Apple=0A= R. White=0A= Ericsson=0A= S. Hares=0A= Huawei=0A= June 11, 2014=0A= =0A= =0A= Use Cases for an Interface to BGP Protocol=0A= draft-keyupate-i2rs-bgp-usecases-03.txt=0A= =0A= Abstract=0A= =0A= A network routing protocol like BGP is typically configured and=0A= analyzed through some form of Command Line Interface (CLI) or=0A= NETCONF. These interactions to control BGP and diagnose its=0A= operation encompass: configuration of protocol parameters, display of=0A= protocol data, setting of certain protocol state and debugging of the=0A= protocol.=0A= =0A= Interface to the Routing System's (I2RS) Programmatic interfaces=0A= provides an alternate way to control and diagnose the operation of=0A= the BGP protocol. I2RS may be used for the configuration,=0A= manipulation, analyzing or collecting the protocol data. This=0A= document describes set of use cases for which I2RS can be used for=0A= BGP protocol. It is intended to provide a base for the solution=0A= draft describing a set of interfaces to the BGP protocol.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 1]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= This Internet-Draft will expire on December 13, 2014.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2014 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= This document may contain material from IETF Documents or IETF=0A= Contributions published or made publicly available before November=0A= 10, 2008. The person(s) controlling the copyright in some of this=0A= material may not have granted the IETF Trust the right to allow=0A= modifications of such material outside the IETF Standards Process.=0A= Without obtaining an adequate license from the person(s) controlling=0A= the copyright in such materials, this document may not be modified=0A= outside the IETF Standards Process, and derivative works of it may=0A= not be created outside the IETF Standards Process, except to format=0A= it for publication as an RFC or to translate it into languages other=0A= than English.=0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4=0A= 1.2. Requirements for I2S . . . . . . . . . . . . . . . . . . 4=0A= 2. Summary of Requirements for I2RS . . . . . . . . . . . . . . 4=0A= 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 6=0A= 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . 6=0A= 3.2. Summary of I2RS Capabilities and Interactions . . . . . . 7=0A= 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 7=0A= 4.1. Customized Best Path Selection Criteria . . . . . . . . . 7=0A= 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 8=0A= 4.3. Route Filter Routes for Legacy Routers . . . . . . . . . 8=0A= 4.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 9=0A= 4.5. Summary of I2RS Capabilities and Interactions . . . . . . 9=0A= 5. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.1. Notification of Routing Events . . . . . . . . . . . . . 10=0A= 5.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 11=0A= 5.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 12=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 2]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= 5.4. Summary of I2RS Capabilities and Interactions for Event=0A= statistics . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 6. Central membership computation for MPLS based VPNs . . . . . 14=0A= 7. Marking Overlapping Traffic Engineering Routes for Removal . 15=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15=0A= 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . 16=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . 16=0A= Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 17=0A= A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 18=0A= A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 19=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20=0A= =0A= 1. Introduction=0A= =0A= Typically, a network routing protocol like BGP is configured and=0A= results of its operation are analyzed through some form of Command=0A= Line Interface (CLI) or NETCONF. These interactions to control BGP=0A= and diagnose its operation encompass: configuration of protocol=0A= parameters, display of protocol data, setting of certain protocol=0A= state and debugging of the protocol.=0A= =0A= The I2RS architecture document [I-D.ietf-i2rs-architecture] describes=0A= a mechanism to control network protocols like BGP using a set of=0A= programmatic interfaces. These programmatic interfaces allow one to=0A= control the BGP protocol by analyzing its operational state and=0A= routing protocol data, plus manipulating BGP's configuration to=0A= achieve various goals. The I2RS is not intended to replace any=0A= existing configuration mechanisms, (i.e.: Command Line Interface or=0A= NETCONF). Instead, I2RS is intended to augment those existing=0A= mechanisms by defining a standardized set of programmatic interfaces=0A= to enable easier configuration, interrogation and analysis of the BGP=0A= protocol.=0A= =0A= This document describes set of use cases for which I2RS's=0A= programmatic interfaces can be used to control and analyze the=0A= operation of BGP. The use cases described in this document cover the=0A= following aspects of BGP: protocol parameter configuration, protocol=0A= route manipulation and tracking of protocol events. The goal is to=0A= inform the community's understanding of where the I2RS BGP extensions=0A= fit within the overall I2RS architecture. It is intended to provide=0A= a basis for the solutions draft describing the set of Interfaces to=0A= the BGP protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 3]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= 1.1. Requirements Language=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= 1.2. Requirements for I2S=0A= =0A= Each of the sections below (BGP protocol operation, BGP Route=0A= Manipulation, BGP Events, Central Membership for MPLS based VPNs, and=0A= Marking Overlapping BGP Routes) have specified a use case=0A= descriptions followed by a summary of I2RS requirements. Each=0A= requirement listed in these sections is given an number [REQnn] where=0A= nn is the unique BGP Requirement. Requirements duplicated from=0A= previous sections are repeated with the original requirements number.=0A= =0A= 2. Summary of Requirements for I2RS=0A= =0A= This is a summary of the requirements listed in this document.=0A= =0A= o REQ01: I2RS client/agent exchange SHOULD support the read, write=0A= and quick notification of status of the BGP peer operational state=0A= on each router within a given Autonomous System (AS). This=0A= operational status includes the quick notification of protocol=0A= events that proceed a destructive tear-down of BGP session=0A= =0A= o REQ02: I2RS client SHOULD be able to push BGP routes with custom=0A= cost communities to specific I2RS agents on BGP routers for=0A= insertion in specific BGP Peer(s) to aid Traffic engineering of=0A= data paths. These routes SHOULD be tracked by the I2RS Agent as=0A= specific BGP routes with customer cost communities. These routes=0A= (will/will not) installed via the RIB-Info.=0A= =0A= o REQ03: I2RS client SHOULD be able to track via read/notifications=0A= all Traffic engineering changes applied via I2RS agents to BGP=0A= route processes in all routers in a network.=0A= =0A= o REQ04: I2RS Agents SHOULD support identification of routers as BGP=0A= ASBRs, PE routers, and IBGP routers.=0A= =0A= o REQ05: I2RS client-agent SHOULD support writing traffic flow=0A= specifications to I2RS Agents that will install them in associated=0A= BGP ASBRs and the PE routers.=0A= =0A= o REQ06: I2RS Client SHOULD be able to track flow specifications=0A= installed within a IBGP Cloud within an AS via reads of BGP Flow=0A= Specification information in I2RS Agent, or via notifications from=0A= I2RS agent=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 4]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= o REQ07: I2RS client-agent exchange SHOULD support the I2RS client=0A= being able to prioritize and control BGP's announcement of flow=0A= specifications after status information reading BGP ASBR and PE=0A= router's capacity. BGP ASBRs and PE routers functions within a=0A= router MAY forward traffic flow specifications received from EBGP=0A= speakers to I2RS agents, so the I2RS Agent SHOULD be able to send=0A= these flow specifications from EBGP sources to a client in=0A= response to a read or notification.=0A= =0A= o REQ08: I2RS Client SHOULD be able to read BGP route filter=0A= information from I2RS Agents associated with legacy BGP routers,=0A= and write filter information via the I2RS agent to be installed in=0A= BGP RR. The I2RS Agent SHOULD be able to install these routes in=0A= the BGP RR, and engage a BGP protocol action to push these routers=0A= to ASBR and PE routers.=0A= =0A= o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to=0A= read BGP routes with all BGP parameters that influence BGP best=0A= path decision, and write appropriate changes to the BGP Routes to=0A= BGP and to the RIB-Info in order to manipulate BGP routes=0A= =0A= o REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) to=0A= notify the I2RS client when the BGP processes on an associated=0A= routing system observe a route change to a specific set of IP=0A= Prefixes and associated prefixes. Route changes include: 1)=0A= prefixes being announced or withdrawn, 2) prefixes being=0A= suppressed due to flap damping, or 3) prefixes using an alternate=0A= best-path for a given IP Prefix. The I2RS agent should be able to=0A= notify the client via publish or subscribe mechanism.=0A= =0A= o REQ11: I2RS client SHOULD be able to read BGP route information=0A= from BGP routers on routes in received but rejected from ADJ-RIB-=0A= IN due to policy, on routes installed in ADJ-RIB-IN, but not=0A= selected as best path, and on route not sent to IBGP peers (due to=0A= non-selection).=0A= =0A= o REQ12: I2RS client SHOULD be able to request the I2RS agent to=0A= read installed BGP Policies.=0A= =0A= o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to=0A= write BGP Policies into the running BGP protocols and into the BGP=0A= configurations.=0A= =0A= o REQ14: I2RS client-agent SHOULD be able to read BGP statistics=0A= associated with Peer, and to receive notifications when certain=0A= statistics have exceeded limits. An example of one of these=0A= protocol statistics is the max-prefix limit.=0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 5]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= o REQ15: The I2RS client via the I2RS agent MUST have the ability to=0A= read the loc-RIB-In BGP table that gets all the routes that the CE=0A= has provided to a PE router.=0A= =0A= o REQ16: The I2RS client via the I2RS agent MUST have the ability to=0A= install destination based routes in the local RIB of the PE=0A= devices. This must include the ability to supply the destination=0A= prefix (NLRI), a table identifier, a route preference, a route=0A= metric, a next-hop tunnel through which traffic would be carried=0A= =0A= o REQ17: The I2RS client via the I2RS agent SHOULD have the the=0A= ability to read the loc-RIB-in BGP table to discover overlapping=0A= routes, and determine which may be safely marked for removal.=0A= =0A= o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability=0A= to modify filtering rules and initiate a re-computation of the=0A= local BGP table through those policies to cause specific routes to=0A= be marked for removal at the outbound eBGP edge.=0A= =0A= 3. BGP Protocol Operation=0A= =0A= It is increasingly common for services facilitated via BGP to be=0A= subject to severe, widespread disruptions (outages), primarily due to=0A= the destructive teardown of BGP sessions as a result of receiving=0A= malformed BGP attributes. Unfortunately, more fine-grained BGP error=0A= handling solutions, which would result in little to no impact on the=0A= operation of BGP protocol, remain elusive.=0A= =0A= A planned Graceful must also carefully be handled to limit the amount=0A= of traffic loss during a the shutdown. While operational=0A= requirements for the BGP mechanism for graceful shutdown of a (set=0A= of) BGP sessions is describe din [RFC6198], and the operational=0A= procedures are described in [I-D.ietf-grow-bgp-gshut], additional=0A= fine-grained BGP error handling could improve graceful shutdown of=0A= BGP sessions.=0A= =0A= This section discussed how I2RS information could improve both the=0A= destructive teardown and the graceful teardown of sessions.=0A= =0A= 3.1. BGP Error Handling for Internal BGP Sessions=0A= =0A= It is possible that I2RS could enable enhanced error handling=0A= techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP=0A= routers could signal an event such as "Malformed Attribute Received"=0A= via an I2RS agent toward an I2RS client(s). I2RS client(s) may=0A= already have a real-time view of BGP routes, and corresponding BGP=0A= attributes, or may dynamically interrogate BGP routers in the network=0A= to identify the present propagation scope of the BGP route(s) that=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 6]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= are affected. Finally, the I2RS client(s) could then signal back to=0A= I2RS agents on BGP routers to apply a filter that would block=0A= propagation of the BGP attribute or BGP route, as necessary, in order=0A= to temporarily aid in consistency of BGP routing information across=0A= the entire network until a permanent fix can be developed and=0A= deployed within BGP routers.=0A= =0A= I2RS would enable the global visibility and global control over the=0A= operational state of BGP, within a given Autonomous System, that is=0A= necessary to facilitate the learning of, rapid response to and more=0A= fine-grained isolation/scoping of BGP protocol events that currently=0A= cause a destructive tear-down of BGP sessions that lead to widespread=0A= disruptions of services.=0A= =0A= 3.2. Summary of I2RS Capabilities and Interactions=0A= =0A= o REQ01: I2RS client/agent exchange SHOULD support the read, write=0A= and quick notification of status of the BGP peer operational state=0A= on each router within a given Autonomous System (AS). This=0A= operational status includes the quick notification of protocol=0A= events that proceed a destructive tear-down of BGP session=0A= =0A= 4. BGP Route Manipulation=0A= =0A= Multiprotocol BGP [RFC4760] provides support to carry routing=0A= information for different BGP address families. Route manipulation=0A= is heavily done across these different address families for different=0A= reasons. BGP IPv4 and IPv6 address families use BGP Communities=0A= [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes=0A= for Traffic Engineering purpose. BGP VPN address families use=0A= Extended Communities [RFC4360] to filter unwanted BGP routes. BGP=0A= Flowspec address family [RFC5575] is used to install Flow based=0A= filters to filter unwanted data traffic. The following sub-sections=0A= describe the use of IRS towards BGP Route Manipulation for different=0A= BGP address families.=0A= =0A= 4.1. Customized Best Path Selection Criteria=0A= =0A= The BGP customized Bestpath facilitates custom bestpath computations=0A= within a BGP speaking network. It is usually used within an IBGP=0A= network. Customized bestpaths use special extended communities known=0A= as cost communities. Cost communities carry enough information;=0A= Point of Insertion (POI) and the cost value to signal where in BGP=0A= bestpath the customize checks need to be done. Both, the traffic=0A= engineering as well as backdoor (SHAM) links use customized bestpath=0A= computation.=0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 7]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= With I2RS, it would be possible for an I2RS client to push routes=0A= with custom cost communities on the BGP routers for Traffic=0A= Engineering purpose. I2RS client now can act as a central entity=0A= keeping track of all Traffic engineering data that get applied to BGP=0A= routes within an IBGP network.=0A= =0A= 4.2. Flowspec Routes=0A= =0A= The BGP flowspec address family is used to disseminate the traffic=0A= flow specification to the BGP Autonomous System Border Routers=0A= (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the=0A= PEs would translate the received BGP traffic flow specification into=0A= an Access Control List (ACL) and install it in router's forwarding=0A= path. Using such ACLs routers can now classify, shape, rate limit,=0A= filter, or redirect traffic flows.=0A= =0A= With I2RS, it would be possible for an I2RS client to push traffic=0A= flow specifications to the BGP ASBRs and the PE routers. I2RS client=0A= can act as a central entity tracking all the traffic flow=0A= specifications that are installed within an IBGP network. I2RS=0A= client could also prioritize and control the announcement of traffic=0A= flow specifications according to various ASRBs and PE router's=0A= capacity. BGP ASBRs and PE routers MAY forward traffic flow=0A= specifications received from EBGP speakers to I2RS Agents. This=0A= would allow I2RS agents to centrally manage and track any externally=0A= received traffic flow specifications.=0A= =0A= 4.3. Route Filter Routes for Legacy Routers=0A= =0A= The BGP Route Filter address family is used to disseminate the Route=0A= Target filter information between VPN BGP speakers. This information=0A= is then used to build a route distribution graph that helps in=0A= limiting the propagation of VPN NLRI (network Layer Reachabilty=0A= Information) within a VPN network. However, it requires that all the=0A= BGP VPN routers are upgraded to support this functionality.=0A= Otherwise, the graph information is incomplete when a VPN network=0A= consists of legacy routers that participates in VPN but does not=0A= implement the BGP route filter address family.=0A= =0A= With I2RS, it would be possible for an I2RS client to push router=0A= filter information to BGP RR routers on behalf of all legacy routers=0A= that participates in VPN but does not support or implement the BGP=0A= route filter address family. I2RS client can act as a central entity=0A= tracking all the configured Route Filters for legacy routers and push=0A= them on appropriate RRs who in turn would push it to ASBRs and PE=0A= routers. In this way, I2RS agents help build an optimal route=0A= distribution graph that would assist in filtering of VPN NLRIs in a=0A= VPN network.=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 8]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= 4.4. Optimized Exit Control=0A= =0A= Optimized Exit Control is used to provide route optimization and load=0A= distribution for multiple network connections between networks.=0A= Network operators can monitor IP traffic flows and then could define=0A= policies and rules based on traffic class performance, link bandwidth=0A= monetary costs, link load distribution, traffic types, link failures,=0A= etc.=0A= =0A= With I2RS, it would be possible for an I2RS client to manipulate BGP=0A= routes and its parameters that influence BGP bestpath decisions.=0A= I2RS client could act as a central entity that would monitor and=0A= manipulate BGP routes based on central network based policies. Such=0A= routes would then be injected by a I2RS client into the network so as=0A= to get the load distribution for multiple network connections.=0A= =0A= 4.5. Summary of I2RS Capabilities and Interactions=0A= =0A= o REQ02: I2RS client SHOULD be able to push BGP routes with custom=0A= cost communities to specific I2RS agents on BGP routers for=0A= insertion in specific BGP Peer(s) to aid Traffic engineering of=0A= data paths. These routes SHOULD be tracked by the I2RS Agent as=0A= specific BGP routes with customer cost communities. These routes=0A= (will/will not) installed via the RIB-Info.=0A= =0A= o REQ03: I2RS client SHOULD be able to track via read/notifications=0A= all Traffic engineering changes applied via I2RS agents to BGP=0A= route processes in all routers in a network.=0A= =0A= o REQ04: I2RS Agents SHOULD support identification of routers as BGP=0A= ASBRs, PE routers, IBGP routers.=0A= =0A= o REQ05: I2RS client-agent SHOULD support writing traffic flow=0A= specifications to I2RS Agents that will install them in associated=0A= BGP ASBRs and the PE routers.=0A= =0A= o REQ06: I2RS Client SHOULD be able to track flow specifications=0A= installed within a IBGP Cloud within an AS via reads of BGP Flow=0A= Specification information in I2RS Agent, or via notifications from=0A= I2RS agent.=0A= =0A= o REQ07: I2RS client-agent exchange SHOULD support the I2RS client=0A= being able to prioritize and control BGP's announcement of flow=0A= specifications after status information reading BGP ASBR and PE=0A= router's capacity. BGP ASBRs and PE routers functions within a=0A= router MAY forward traffic flow specifications received from EBGP=0A= speakers to I2RS agents, so the I2RS Agent SHOULD be able to send=0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 9]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= these flow specifications from EBGP sources to a client in=0A= response to a read or notification.=0A= =0A= o REQ08: I2RS Client SHOULD be able to read BGP route filter=0A= information from I2RS Agents associated with legacy BGP routers,=0A= and write filter information via the I2RS agent to be installed in=0A= BGP RR. The I2RS Agent SHOULD be able to install these routes in=0A= the BGP RR, and engage a BGP protocol action to push these routers=0A= to ASBR and PE routers.=0A= =0A= o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to=0A= read BGP routes with all BGP parameters that influence BGP best=0A= path decision, and write appropriate changes to the BGP Routes to=0A= BGP and to the RIB-Info in order to manipulate BGP routes=0A= =0A= 5. BGP Events=0A= =0A= Given the extremely large number of BGP Routes in networks, it is=0A= critical to have scalable mechanisms that can be used to monitor for=0A= events affecting routing state and, consequently, reachability. In=0A= addition, similar tools are needed in order to monitor BGP protocol=0A= statistics, which help operators and developers better understand=0A= scalability of software and hardware that BGP utilizes.=0A= =0A= I2RS could provide a publish-subscribe capability to applications to:=0A= =0A= o request monitoring of BGP routes and related events; and,=0A= =0A= o subscribe to the I2RS client to receive events related to BGP=0A= routes or other protocol-related events of interest.=0A= =0A= 5.1. Notification of Routing Events=0A= =0A= There are certain IP prefixes, for example those that are arbitrarily=0A= classified by a given network operator as "high visibility" by its=0A= end-users, for which immediate notification of changes in their state=0A= are extremely useful to know about. Upon notification of such=0A= events, a Network Operations Center (NOC) could respond to customer=0A= inquiries in a more timely fashion; alternatively, the NOC may decide=0A= to perform Traffic Engineering to restore service, etc.=0A= =0A= Currently, the only way to learn of such events is for a BGP=0A= monitoring system to establish a BGP session with a multitude of BGP=0A= routers in an AS. Then, the BGP monitoring system needs to look=0A= through all BGP UPDATE's in order to identify those events that are=0A= of interest to it. Note, this doesn't account for the fact that=0A= there are several applications that might be simultaneously=0A= interested in learning of events to a given IP prefix nor the fact=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 10]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= that some applications may want to dynamically insert or remove "IP=0A= prefixes of interest", depending on the needs of their constituent=0A= applications.=0A= =0A= With I2RS, it is conceivable that applications could tell an I2RS=0A= client, through a North-Bound API, their "IP prefixes" (or,=0A= AS_PATH's, BGP communities, etc.) that are of interest. For example,=0A= a NOC application may be interested in changes to high visibility=0A= content or service-provider Web sites; alternatively, a security=0A= application may be interested in events associated with a different=0A= set of IP prefixes. The I2RS client would then consolidate the list=0A= of IP prefixes, and associated characteristics, to be monitored and=0A= program BGP routers in an AS to observe this subset of routes for=0A= changes. Some examples of changes in routing state might include:=0A= =0A= o an IP prefix being announced or withdrawn=0A= =0A= o an IP prefix being suppressed, due to route flap dampening=0A= =0A= o an alternative best-path being chosen for a given IP prefix=0A= =0A= When the requisite events for a BGP Route are observed by a BGP=0A= router, it would notify I2RS agents.=0A= =0A= The I2RS agents would have a publish/subscribe mechanism whereby=0A= various sets of applications may subscribe to events of interest.=0A= The I2RS client would then publish these events so applications would=0A= immediately receive them and take the appropriate domain-specific=0A= action necessary.=0A= =0A= 5.2. Tracing Dropped BGP Routes=0A= =0A= It is extremely useful to operators to be able to rapidly identify=0A= instances where a BGP route is not being propagated within an=0A= Autonomous System. At a minimum, this could result in sub-optimal=0A= performance when attempting to reach such destinations.=0A= =0A= There are two instances when this scenario will occur. First, when a=0A= Service Provider is using "Soft Reconfiguration Inbound", it allows=0A= their ASBR routers to receive a copy of a BGP route, but show that=0A= route was not permitted into the Adj-RIB-In most likely as a result=0A= of the inbound BGP policy not permitting that IP prefix. Thus, this=0A= BGP route is not even eligible for BGP Path Selection. The second=0A= instance is where the BGP route is permitted by the inbound BGP=0A= policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.:=0A= lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the=0A= best path and, subsequently, this particular BGP route is not=0A= forwarded on to other internal BGP speakers in the AS. In both=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 11]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= instances, the BGP route is only visible within the ASBR on which=0A= that BGP route was first learned. Needless to say, in large Service=0A= Provider networks with a numerous interconnects to a single customer=0A= it can be very time-consuming to discover where such a BGP route is=0A= learned before ultimately determining why the route was blocked or=0A= not preferred.=0A= =0A= With I2RS, it would be possible for an I2RS client to rapidly gather=0A= information from across a large set of BGP routers in the network to=0A= determine at what ASBR's the BGP route is being learned. Next, the=0A= I2RS client could interrogate those routers BGP policies to determine=0A= the root cause of why the route was either not learned or not=0A= preferred in BGP. Finally, if necessary, the I2RS client(s) could=0A= amend BGP policies and push them out to BGP routers to permit the BGP=0A= route or make it a preferred route according to the BGP path=0A= selection algorithm.=0A= =0A= 5.3. BGP Protocol Statistics=0A= =0A= There are a variety of statistics related to the operation of BGP=0A= that are invaluable to network operators. These statistics generally=0A= help operators, and developers, understand the present state and=0A= future scalability of BGP.=0A= =0A= One statistic that is invaluable to operators is the current number=0A= of BGP routes learned through an eBGP session. Operators then apply=0A= a command against each eBGP session to limit the maximum number of=0A= BGP routes that may be learned through that eBGP session before a=0A= warning message is triggered and/or the eBGP session is torn down=0A= completely. This configuration capability is often referred to as a=0A= "max-prefix limit". This command must be routinely audited and, if=0A= necessary, adjusted in order to not trigger a false warning or=0A= teardown due to the natural organic growth in BGP routes learned from=0A= a given BGP neighbor.=0A= =0A= I2RS agents could provide an invaluable capability to help audit and=0A= re-program the "max-prefix limit" on a periodic basis, which is=0A= generally once per day. Specifically, the first task would be for an=0A= I2RS client to validate that there is a "max-prefix limit" applied to=0A= every eBGP session. (If there is not, that should either trigger a=0A= red alarm to the NOC to manually fix this condition or for the I2RS=0A= client to automatically apply a "max-prefix limit" that would=0A= alleviate this hazardous condition). Assuming there is a "max-prefix=0A= limit" already in place, the I2RS client would simultaneously=0A= retrieve, from each BGP router, the current number of BGP routes=0A= learned through a BGP session and value used for the "max-prefix=0A= limit" on that same BGP session. These two values could then be=0A= handed off to an application that determines if adjustments in the=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 12]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= "max-prefix limit" value are required for each BGP session. The=0A= application would then notify the I2RS client of the subset of eBGP=0A= sessions and their associated change in "max-prefix limit" value,=0A= whereby the I2RS client would then adjust the BGP protocol=0A= configuration on each requisite BGP router in the network. Finally,=0A= it should be noted that the above is just one method whereby "max-=0A= prefix limit" values are adjusted. It's similarly possible that the=0A= BGP routers may, through the I2RS, pull the "max-prefix limit" values=0A= for each eBGP neighbor they have on-board on a periodic basis and=0A= validate their accuracy.=0A= =0A= The above is just one use case related to BGP protocol statistics.=0A= There are wealth of other BGP protocol statistics or state=0A= information that would be invaluable to have programmatic visibility=0A= into that operators do not have today.=0A= =0A= 5.4. Summary of I2RS Capabilities and Interactions for Event statistics=0A= =0A= I2RS SHOULD have the ability to:=0A= =0A= o REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) to=0A= notify the I2RS client when the BGP processes on an associated=0A= routing system observe a route change to a specific set of IP=0A= Prefixes and associated prefixes. Route changes include: 1)=0A= prefixes being announced or withdrawn, 2) prefixes being=0A= suppressed due to flap damping, or 3) prefixes using an alternate=0A= best-path for a given IP Prefix. The I2RS agent should be able to=0A= notify the client via publish or subscribe mechanism.=0A= =0A= o REQ11: I2RS client SHOULD be able to read BGP route information=0A= from BGP routers on routes in received but rejected from ADJ-RIB-=0A= IN due to policy, on routes installed in ADJ-RIB-IN, but not=0A= selected as best path, and on route not sent to IBGP peers (due to=0A= non-selection).=0A= =0A= o REQ12: I2RS client SHOULD be able to request the I2RS agent to=0A= read installed BGP Policies=0A= =0A= o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to=0A= write BGP Policies into the running BGP protocols and into the BGP=0A= configurations.=0A= =0A= o REQ14: I2RS client-agent SHOULD be able to read BGP statistics=0A= associated with Peer, and to receive notifications when certain=0A= statistics have exceeded limits. An example of one of these=0A= protocol statistics is the max-prefix limit.=0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 13]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= 6. Central membership computation for MPLS based VPNs=0A= =0A= MPLS based VPNs use route target extended communities to express=0A= membership information. Every PE router holds incoming BGP NLRI and=0A= processes them to determine membership and then import the NLRI into=0A= the appropriate MPLS/VPN routing tables. This consumes resources,=0A= both memory and compute on each of the PE devices.=0A= =0A= An alternative approach is to monitor routing updates on every PE=0A= from the attached CEs and then compute membership in a central=0A= manner. Once computed the routes are pushed to the VPN RIBs of the=0A= participating PEs.=0A= =0A= This centralization of membership control has a few advantages.=0A= =0A= o The membership mechanism (route-targets) need not be configured in=0A= each of the PEs and can be expressed once centrally.=0A= =0A= o No resources in the PEs need to be spent to categorize routes into=0A= the VRF tables that they belong and to filter out unwanted state.=0A= =0A= o Doing it centrally means the availability of almost unlimited=0A= compute capacity to compute membership and hence can be done in a=0A= scaleable manner.=0A= =0A= o More sophisticated routing policies and filters can be applied=0A= during the central import/export process than can be expressed and=0A= performed using the traditional route target mechanism.=0A= =0A= o Routes can be selectively pushed only to the participating PE's=0A= further reducing the memory load on the individual routers in the=0A= network. This further obviates for a distributed mechanisms such=0A= as rt constraints to reduce unnecessary path state in the routers.=0A= =0A= Note that centrally computation of membership can be applied to other=0A= scenarios as well such as VPLS, MVPNs, MAC VPNs and others.=0A= Depending on the scenario, what gets monitored from the CE might=0A= vary. Central computation will especially help VPLS where multi-=0A= homing and load balancing using distributed techniques has=0A= particularly been a challenge.=0A= =0A= Also note that one of the biggest promises of central route=0A= computation is simplification and reduction of computation and memory=0A= load on all devices in the network. This use case is just one=0A= example that illustrates these benefits of central computation very=0A= well.=0A= =0A= Summary of I2RS Capabilities and Interactions:=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 14]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= o REQ15:The I2RS client via the I2RS agent MUST have the ability to=0A= read the loc-RIB-In BGP table that gets all the routes that the CE=0A= has provided to a PE router.=0A= =0A= o REQ16:The I2RS client via the I2RS agent MUST have the ability to=0A= install destination based routes in the local RIB of the PE=0A= devices. This must include the ability to supply the destination=0A= prefix (NLRI), a table identifier, a route preference, a route=0A= metric, a next-hop tunnel through which traffic would be carried=0A= =0A= 7. Marking Overlapping Traffic Engineering Routes for Removal=0A= =0A= It is often the case that routes are advertised not to provide=0A= reachability (in the strict sense), but rather to provide optimal=0A= reachability, or to engineer the path traffic takes to a particular=0A= destination. While this can improve the efficiency of a network's=0A= operation, it can also increase the amount of state carried in the=0A= control plane beyond the point where the additional state has any=0A= real effect on traffic flow. Removing Overlapping Routes=0A= [I-D.white-grow-overlapping-routes] provides a mechanism designed to=0A= remove these traffic engineering routes once they are beyond the=0A= point of actually impacting traffic flows in the network.=0A= =0A= Summary of I2RS Capabilities and Interactions:=0A= =0A= o REQ17: The I2RS client via the I2RS agent SHOULD have the the=0A= ability to read the loc-RIB-in BGP table to discover overlapping=0A= routes, and determine which may be safely marked for removal.=0A= =0A= o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability=0A= to modify filtering rules and initiate a re-computation of the=0A= local BGP table through those policies to cause specific routes to=0A= be marked for removal at the outbound eBGP edge.=0A= =0A= 8. Security Considerations=0A= =0A= The BGP use cases described in this document assumes use of I2RS=0A= programmatic interfaces described in the I2RS framework mentioned in=0A= [I-D.ietf-i2rs-architecture]. This document does not change the=0A= underlying security issues inherent in the existing in=0A= [I-D.ietf-i2rs-architecture].=0A= =0A= 9. Acknowledgements=0A= =0A= The authors would like to thank Ed Crabbe, Joel Halpern, Wes George,=0A= Carlos Pignataro, Jon Mitchell and Bill Atwood for their comments and=0A= suggestions.=0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 15]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= 10. References=0A= =0A= 10.1. Normative References=0A= =0A= [I-D.ietf-i2rs-architecture]=0A= Atlas, A., Halpern, J., Hares, S., Ward, D., and T.=0A= Nadeau, "An Architecture for the Interface to the Routing=0A= System", draft-ietf-i2rs-architecture-03 (work in=0A= progress), May 2014.=0A= =0A= [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP=0A= Communities Attribute", RFC 1997, August 1996.=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,=0A= June 1999.=0A= =0A= [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement=0A= with BGP-4", RFC 3392, November 2002.=0A= =0A= [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC=0A= Text on Security Considerations", BCP 72, RFC 3552, July=0A= 2003.=0A= =0A= [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway=0A= Protocol 4 (BGP-4)", RFC 4271, January 2006.=0A= =0A= [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended=0A= Communities Attribute", RFC 4360, February 2006.=0A= =0A= [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,=0A= "Multiprotocol Extensions for BGP-4", RFC 4760, January=0A= 2007.=0A= =0A= 10.2. Informative References=0A= =0A= [I-D.ietf-grow-bgp-gshut]=0A= Francois, P., Decraene, B., Pelsser, C., Patel, K., and C.=0A= Filsfils, "Graceful BGP session shutdown", draft-ietf-=0A= grow-bgp-gshut-05 (work in progress), January 2014.=0A= =0A= [I-D.mcpherson-irr-routing-policy-considerations]=0A= McPherson, D., Amante, S., Osterweil, E., and L. Blunk,=0A= "IRR & Routing Policy Configuration Considerations",=0A= draft-mcpherson-irr-routing-policy-considerations-01 (work=0A= in progress), September 2012.=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 16]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= [I-D.white-grow-overlapping-routes]=0A= White, R., Retana, A., and S. Hares, "Filtering of=0A= Overlapping Routes", draft-white-grow-overlapping-=0A= routes-01 (work in progress), February 2013.=0A= =0A= [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,=0A= Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,=0A= "Routing Policy Specification Language (RPSL)", RFC 2622,=0A= June 1999.=0A= =0A= [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,=0A= "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.=0A= =0A= [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,=0A= April 2008.=0A= =0A= [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,=0A= and D. McPherson, "Dissemination of Flow Specification=0A= Rules", RFC 5575, August 2009.=0A= =0A= [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",=0A= RFC 5735, January 2010.=0A= =0A= [RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,=0A= Elizondo Armengol, A., and T. Takeda, "Requirements for=0A= the Graceful Shutdown of BGP Sessions", RFC 6198, April=0A= 2011.=0A= =0A= Appendix A. BGP Configuration=0A= =0A= The configuration of BGP is arduous to establish and maintain,=0A= particularly on networks whose services have a requirement for=0A= complex routing policies. This need is magnified by the need to=0A= routinely perform changes to large numbers of BGP routers to, for=0A= example: add or remove customer's BGP sessions, announce or withdraw=0A= (customer) IP prefixes in BGP, modify BGP policies to effect changes=0A= in Traffic Engineering, audit BGP routers to ensure they have=0A= consistent and appropriate BGP policies, and others.=0A= =0A= There are three categories of BGP configuration:=0A= =0A= 1. Local BGP routing protocol configuration: local Autonomous System=0A= Number (ASN), BGP path selection properties of the router,=0A= injection of (aggregate) routes into BGP, etc.=0A= =0A= 2. Local BGP policies: policies designed to filter and/or manipulate=0A= BGP attributes associated with BGP routes learned through BGP=0A= sessions. These policies typically live in the global=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 17]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= configuration of a BGP router, but are applied on a per-BGP=0A= neighbor basis (or, group of BGP neighbors); and,=0A= =0A= 3. BGP neighbor sessions: remote ASN, remote IP address, address=0A= families, BGP policies to applied to routes, max-prefix limits,=0A= etc.=0A= =0A= The sum total of BGP configuration on a BGP router is typically the=0A= largest quantify of configuration on Service Provider's BGP routers,=0A= by a fairly large margin. When that is combined with the large set=0A= of routine configuration changes, mentioned above, it should be=0A= fairly clear that systematic reading, configuration and control of=0A= BGP routers through a mechanism like I2RS would greatly benefit all=0A= operators of BGP routers.=0A= =0A= While it may not be possible to provide programmatic APIs for=0A= esoteric vendor-specific policy configuration, it is possible to=0A= provide such API's for BGP protocol specific configuration and the=0A= more commonly used BGP routing policies.=0A= =0A= A.1. BGP Protocol Configuration=0A= =0A= Ability to enable and disable new address families within a BGP=0A= protocol for a network of BGP speaking routers is a challenge. The=0A= challenge is mainly in keeping track of BGP speaker's feature=0A= capabilities and then configuration of new address families on a=0A= multiple BGP speakers within a given network. With the necessary=0A= information, I2RS agents allow a network operator to push=0A= configuration information for enabling and disabling of new address=0A= families on a partial or entire set of BGP speakers within a given=0A= network. This would assist in building BGP overlay networks as=0A= needed.=0A= =0A= For VPN address families, the main challenge lies in the complex VPN=0A= configuration required to setup the control plane for Customer VPNs.=0A= The configuration involves creating a Virtual Routing and Forwarding=0A= instance (VRF), a Route Distinguisher (RD) that ensures each customer=0A= prefixes remains unique across VPNs, and Route Targets (RT) that help=0A= ensure that the Customer prefixes are segregated appropriately so=0A= that they do not cross the VPN boundaries. I2RS would allow a=0A= network operator to push such configuration from a central location=0A= where a global VPN provisioning information could be stored. This=0A= helps avoid manual configuration of a VPN on multiple routers.=0A= Instead the configuration is controlled and pushed though a central=0A= I2RS client using a programmatic set of APIs on targeted set of BGP=0A= speakers.=0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 18]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= Use of I2RS agents to announce protocol configuration information=0A= would simplify and automate configuration of BGP protocol in IBGP=0A= deployments where the protocol based policies are seldom used. To=0A= facilitate such a centralized configuration model, BGP speakers could=0A= be extended to use programmatic APIs to announce their feature=0A= capabilities as part of protocol initialization to the centralize=0A= I2RS agents. This would assist I2RS agents to auto-discover BGP=0A= protocol capabilities of various BGP speakers in a given network.=0A= I2RS agents in turn would use the information towards enabling/=0A= disabling of BGP specific features on BGP speakers.=0A= =0A= A.2. BGP Policy Configuration=0A= =0A= Filtering of BGP routes is strongly recommended to control the=0A= announcements of BGP prefixes across the internet. Most providers=0A= make extensive use of BGP prefix filtering policies at the edge of=0A= their networks. The reasons for filtering BGP prefixes are:=0A= =0A= o Avoid Unwanted Route Announcements. Filter prefixes that MUST not=0A= be routed [RFC5735], [RFC5156]. Filter prefixes that are not=0A= allocated by Internet Routing Registries.=0A= =0A= o Facilitate Route Summarization. Filter prefixes beyond certain=0A= agreed prefix mask length between providers. Route Summarization=0A= helps control BGP RIB and FIB table size.=0A= =0A= o Defensive Security. Filter prefixes from Stub customer ASes that=0A= are not owned by the customers. Filter customer prefixes=0A= announced by other providers. This helps avoid prefix hijacking.=0A= =0A= A set of standards-based schemas to enable configuration of Local BGP=0A= policies and BGP neighbor sessions was realized through the Routing=0A= Policy Specification Language (RSPL) [RFC2622]. The RPSL defined a=0A= standards-based schemas, or 'objects' as it called them, that=0A= defined:=0A= =0A= o binding of IP prefixes to (one or more) Origin AS, (route=0A= objects);=0A= =0A= o collections of routes (route-set objects);=0A= =0A= o collections of Autonomous Systems (as-set objects); and,=0A= =0A= o routing policy of an Autonomous System to/from its adjacent=0A= neighbor AS'es, (aut-num objects)=0A= =0A= Each ASN is responsible for creation, modification and deletion of=0A= its RPSL objects in an Internet Routing Registry (IRR). IRR's are=0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 19]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= typically operated by Regional Internet Registries (RIR's) and a few=0A= dozen larger ISP's and independent organizations. The IRR's provide=0A= a well-known location for all organizations attached to the Internet=0A= to retrieve or update RPSL objects.=0A= =0A= While still widely and actively used by Internet Service Providers,=0A= the prevailing belief is that the data contained in the IRR's is=0A= inaccurate, primarily due to a lack of deployed authorization method=0A= with respect to the creation of modification of RPSL objects. It=0A= should be noted that this criticism is not directed at the previously=0A= defined RPSL schemas, but rather at the data contained in RPSL=0A= schemas by end-users of the IRR system. Please refer to the IRR And=0A= Routing Policy Configuration Considerations=0A= [I-D.mcpherson-irr-routing-policy-considerations] document for a more=0A= thorough discussion of the history and present state of the IRR's.=0A= =0A= Currently, RPSL schemas are exchanged between non-routing systems=0A= (servers) used within the IRR system. In addition, open-source and=0A= proprietary applications create or modify RPSL schemas, as necessary,=0A= to signal the announcement (or, withdrawal) of an IP prefix from an=0A= ASN or the creation (or, teardown) of a neighbor relationship between=0A= two adjacent ASN's. Most importantly, these RPSL schemas are=0A= consumed by similar applications to automatically build routing=0A= policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's=0A= and/or AS_PATH's), that then get translated to device-specific syntax=0A= (i.e.: CLI) before being pushed into individual BGP routers to effect=0A= routing policy on the network. It is common for Internet Service=0A= Providers to perform updates to these routing policies across their=0A= entire network on a daily basis.=0A= =0A= With I2RS it would be desirable to change the last step in the above=0A= process so that BGP policies derived from RPSL schemas, and other=0A= information sources, are translated into standards-based schemas that=0A= are then pushed, or pulled, into individual BGP routers. More=0A= generally, I2RS agents could use API's to gather information required=0A= to build various types of BGP routing policies plus the corresponding=0A= set of Autonomous System Border Routers (ASBR's) where such policies=0A= need to be applied in the network and, finally, making those changes=0A= to individual network elements so those BGP policies take effect in=0A= the network. In doing so, a network operator now has a centralized=0A= way of building and making these policies take effect across the=0A= network in a coordinated manner.=0A= =0A= Authors' Addresses=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 20]=0A= =0C=0A= Internet-Draft Use Cases for an Interface to BGP June 2014=0A= =0A= =0A= Keyur Patel=0A= Cisco Systems=0A= 170 W. Tasman Drive=0A= San Jose, CA 95134=0A= USA=0A= =0A= Email: keyupate@cisco.com=0A= =0A= =0A= Rex Fernando=0A= Cisco Systems=0A= 170 W. Tasman Drive=0A= San Jose, CA 95134=0A= USA=0A= =0A= Email: rex@cisco.com=0A= =0A= =0A= Hannes Gredler=0A= Juniper Networks=0A= 1194 N. Mathilda Ave=0A= Sunnyvale, CA 94089=0A= USA=0A= =0A= Email: hannes@juniper.net=0A= =0A= =0A= Shane Amante=0A= Apple=0A= =0A= =0A= Russ White=0A= Ericsson=0A= =0A= Email: russw@riw.us=0A= =0A= =0A= Susan Hares=0A= Huawei=0A= =0A= Email: shares@ndzh.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Patel, et al. Expires December 13, 2014 [Page 21]=0A= ------=_NextPart_000_00CF_01CF85B9.47813DD0 Content-Type: application/pdf; name="draft-keyupate-i2rs-bgp-usecases-03.txt.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-keyupate-i2rs-bgp-usecases-03.txt.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1WwXLbNhC96yt2ckk8Y0mW3NZJbrYix25c17XVyaHuAQJXFGqSYAAwtvr1 fQtClCV3mnpi6iCJXDy8fft2wS90MBjRgXzSty57w+sjyn3vgPLel94oPqT0pUs6mSHgLY3GNFv0 2jUjGh/S0eE7mpW9N+fj6xv6bN2dqXL66GxT07OuTwO6UoGLvdlfvdEhzS4AWQV2FYf+B6cW4Xlw dD2gU6xWVWb3XrdYVcYZ+aBC49/TebWwrlTB2EoV/4k0MV5buln5wKUXrOlDbRwD4wNrLufsaHS4 T+OD0Q//h9jZAPJwVrATrGdm1V0/N5WpsfMlh3uI7r8HK103AzouFXR6ASy5juu6eBEslPLz0rwM r6kz2ntbvQQWBDtTMMLL6HXWqHs234kFWzCNRq0bgSXNefEE8XfPNFGePaEHSFUUO22hNFOwdPLx iq6cDVbbAhCpGXd3yqQn+3e8amq0bd+Mne/P87rfeNYC3T84HISHAIDxTxHgeO6DUzqkDI+paq1L mBVBhkad9qTC3HFkYTyFVW20KooVaVstTN6gdcA42yKm0MKrv/EgLAGWL8nbkiW3kuyCJraErTO6 MNBmk+ntm8nF+e0e2XUfXk5nk18vTwdEsyVDISOhIIwJ4UUXEAgO9ISZ4GVG5ZWVwLC2gEVLxpFC XGlb1spjSqyJtw9AqEu0Vk6VjF38PtB8XagVniesLipTQe2T5xBVwnrNLihTbSJkpnHLiedNnqe4 sOQdrMGmHLi7VXUE03WqRDvrXntoJGMdIsEPObjKvNStMLLOb1UBm3w1GUwFQ6lCRrewukdOj8Tb Ek723EjWZS63ReSONajK6VICas4Eh2XRuBK3Je5+AkC5Td0U7b3kjqiJQ3xRsI5ZyvItkWPlzbqW mdVNyVWApl47M0diqIHoCgKku/a5Xxq9bAlqZP6IYALaTSWIr836PII2SThSNAdql5q3RSMZrPnE QzCREf5qzWdTj3Uht7bc1Pwmnn2yRPKkX7i0CTz+3zlvccc389KEAJqw26Ipiqi3nJsVXHNvwjKZ bMcFPvYM9jmZXNHR21j1+PPdvziw2xHOcUBN7xBr/X2ychdM0woOZ3aI2tp6pvwdnVoXm/t8Oju9 3YPelzaI0xSkAoqjXN5NfDSTKryVxgtQtOnOl6cE1K42vh0SmFQ+VkA3zolVuqgEldKCkth+GUL9 fjgUp8kgvGM3MBwWA+vyYSyuHyac4bdVSm7oKH5VhWm7QiG1B1M2cfZ580AlWm/pdwZm1nVTDUKc 7ZNjzB8tvwBi53AfS+Hnq6TbIzkCAFbrZjUlP3K1qmGA2hlpfZhRWuUJfY+9FoxENXcNixCD9zCx PoaFiSXjMm2N6lWy7FU8L9rJl+Pg9YNXAPhxHNOKb4/7BH8oabPuSm9r33xZ++NK5Tg7/wTidNb7 DZ9/AKoyCuZlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMTA4MAplbmRvYmoKMTIgMCBvYmoKPDwv TGVuZ3RoIDEzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVbBVuM2FN3nK95u 4BwmxAkMTHclQEsP06FJerooXSi2nGgqWx5JDqRf3/tkOXEydAinyQIiW1f33nefpK806Cc04G/8 mxa908kFLVxvQIve114SHlL8kxZ0NcMLl5QMaZb3mjkJDUd0cXFJs6J3dFd6aUvp319bkXsKn9+d pLFw0lFuLImSwku5SCV5Q1c/PdDm80tdShoOkrPj2Zfe6CPN7ntHGJ4tlaM96CelNcnnSllJpqRr mcpiLi0lo5OA0D9+1xt+CAhjU62tWiw9/Wq8SiWeMOp2+PEofTwOs+juZnZLM1s7D6YZ+aWkSlpn Skcqk6VXuZIZCcdPgJOMWo6ZSesCL5Co/dJY1yf6EQzDAo6sdNKuZNZh1eraTMT/rp5/kakPvowf CKa2JLa83jm6lwuhd1Z/sGalnGKaE6mFV+WCQcKs67iAi7ofj5beVz+cnnqGk7KvpM/7xi5ONcwp nXyvytzAEFWSzHPmA4OZRCY8zM4jTlXPMQFr4anJ8UJHDNQ/aImiQ/lKySeejh/ZHpVUWJnXWq9P oqVryqRLrZpLWpvatvaxC7DQW5X6IPJJ+SWPVGAXsSB3n8LYZIieKSpT8qKIi7ci9Shgbk2x+zoV MCNCqTLVNaZOVVHppuJX02u6b+whDxzm21LN2KmpDNTorN+xiE1rwhRK1i0TS4J6qngoAwZLMjWC LawVpV9jhYiysw5Dvszre9kqxJpSU3oBhAJVtApsggm7ESF0KI/shGuMiVi/bqwPZXdLrI13CwGb miBoMF4JpcVcS5pL9LpEv61CV0YhyYB7c3DZZ3ptYz0eOWSNyVmjdQgunqWb5gRjZwrZRixCbUSw stJ4WoqVpAU7J/c7JvxswBASobV5alFMBhubDDtewdXpcouNcjjUZgs39SibsJnjSqbSuX4E+iMW z8zZYhaBfQ7efK25ZWJftan7T+Wd1Ozq77JyJ/vBjQ6gZxo9MotAr/M/CTnMALyCCXDwydi/gxMq AEegCJ9aKdjeQ3DlcyqrYDiSAO5ta/lwCnT3DsHNQJPbMQeKuxhFdJp9U6weI1qUi1oscIIYLGk3 NmHaTbngNHayPwsBhAKObWevSZC6O7Y6q5tOpf4bv0Sjnb5gTEadoMw4hpoGuo9cD0Q8i+wYa7iP xU7dDaeHMd1iMc60Lgph1+zDC5CTVzC3WCP84CMadfUmNZo+I7viLf4RfdhoHAW/GO/GWjD5GbEJ LR9ohQMebcfPpwhRaMrvYO3pDLLGohJzpZVXstljA6qIx8Yu1kXEOoucJsi1pE+iVFWt36jxYsPr LGgcY98xhfqHt2gcXPQgcGBNpY6nxNiq0M2vYrHGW2xYfNI1BN2BnBqsyw4W17LReKs0lm/x2Hw+ n9J1M2LdS7p3sdizz5VXjcSbZ7TquNnIDvGM6GMH6/x/1rHFOm+ztQpRf4NPG6xksOF1HurIN8a8 c8thgziwr6+xi8V1nIE/z722pqo4GG3mXuVKSdLB+qYnsf165XC1PSQbuLwD63wYdjHEUmps1rjP 6P72Ho6C8sXafXutpt3Pnw+81Q3/AuLNrPcbvv8CV318pWVuZHN0cmVhbQplbmRvYmoKMTMgMCBv YmoKMTE4OAplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnicnVbBUttIEL37K/oGVBkvMgmQ3Ahht9gihAXvXkIO41FbnkWaUWZGBufr 82Y0kmWnqAqRDrak0evXr1+35hsdTTI6Cmf6ldXoj7tTKtzoiIrRt1EWH1L6kRV9mGHBGWVTmi1G 7TsZTY/p9PSMZtVo/0p7tpr94UcrFp7i8a9juhCOHS2MJaEpLloIyeQNffjrlvrj70YzTY+yNwez /0fH72h2PdqPD95O3kyI7puqEnZNZkFX07t7oNZirkrlFcCFzltkIb0yuo12uWLtD/ZG2fEGqz2c F145r6QjmrzqpOwYiAHrBBcXCGBFSRVXc7ZuqWqSpqqbAG90JPHp9vqe5lAgp/9ub7biEVJtsU5x 8UnYR6UL+rxiW4q6Dv9nEHKhJF3qQmlmG+7dmcYnOe+4MiuEj1hvE9ZZ0IplY5Vf0wW0UDlkaVX5 1Rw7rHe4OJeP2jyVnBdcId1XKrbByo4mILxgy1ryq3VvsU4SVkTLcOfG2Aq5rXgI/RtYU9y50ovf Q9tgndc161w90znuBnND/4Uqmlb/X8mZstOe13lMMcDcWuONNOXr8Cg7G2BNOyxTKrl+LTPK3nU5 Nn5prNuj8zy37Nzra4kmB9b0JHZlFpX31uRNbN0UZbaulRRluR6TIMyUJ2MfycL6oQXqTo5SPXJM Sjk0XpsQGg3TYKvtQbMp4VyMDhV+6tQQJCxjsSjX3/GWXwK/WJIzFYf2qsL6C4OpE+EC0DW6cDDB HvYvrq8eDgiteHM5u/h88yeSmS0ZM08NhxEmHdghxzKQTVhhZOVKFNqE5Vu0YDxMEeHc+z6r9gEI dbknlFpYUTFiuTHQXF2K9XAV5cKLMTn2UTg8kWy9UHoXJ0xEbjnxvCmKtNovuV852RSNYprtHBZW LpVn6SE95UY2YUrQl6vDjxPFfnGoptYdDhd9RQgnrZqz26qSwBiVS6GVq4aKdcXvaLhN1RsXaIqQ Hsh2ilhTQJPQyLItQ6iV6yvzwnOC2cwTGR0+TAmqoxBUCPF6VefrZJsQf6t2mMa9lAnlJ9e2NanL xhG8peqmFHEBQuy5nYr3XAQEZEymlbDK4M3CiDIl1dYBLaCNjxnpPNjZwPfwgwxc1gmFn8NnD7G2 o/TCw0UP+2rCk/ed83c9b2yCSo5/OIgN7DyLfNwzGbIQTREtgbEB+TsGCWUTOYia80LpVFOP4MLm KrRmW+CXSpegEIq1mJeIIZxiu53juH0BCKn1dd7W0CnXOX3TnC95Hmt7i/cu7ug1SE/2e52npZLL KMjets9fMqDE7mjOASUf+r8n+p0DyURwMywQGLyTEzYUOnY5QuC9IXFpsMUYYC1MsH6U3dXoUZcw 328s24+ZXVF3xkjwOg9cnYTGJkk+ppHSY3LYnnUWDnYOxun9ruLXOJYFw7BqNLYz6I4GrrLRGwnu aYkPdVwWvRfalJ9hPhcmb5eg8vSkIIKOC0P66Pafx1dwst+1L/iusIXq2jDs5VRb4YDlTNm0Qz6P m94keyAXH7fOuNpUuU9wd6gEq2VHb6JLbjFByjHhZVFOBvvWy+da4WNGH1nGHSd2o+O4Zabt48ut KJiOvwLycjb6B+cPBDiJmWVuZHN0cmVhbQplbmRvYmoKMTggMCBvYmoKMTIwMAplbmRvYmoKMjIg MCBvYmoKPDwvTGVuZ3RoIDIzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnichVZN c+I4EL3zK7py2aSKkJhkJjNzI4TZZQsCwc5WbU1yELIAbWzJkWSY/Pvtlm38MdSuqcICtbv7vX7d 8jtcDwK4pk9552nvanUHW9u7hm3vvRf4TShvPIX7CA2+QDCEaNMrnglgeAN3d18gSnvnU+WEUcJd Phi2ceCvZytgzKywsNEGmAJvtGFcgNNw//sSjtefuRIwvA5uL6J/ejdfIZr1zoNBMABYifdcGpEK 5SzMmNrmbCsufusNP3sjfDbaCXgTH3DQJrZwNn8Oo7N+cYfHhV+vJk/P09XkgdbhH6PZ7LgoLNBf cFP5w43F86y0pVXtZbyYzyePD4Wj+ehvvDEVw9liGU0Xj6PZGUgFbictOiRXseY5ZQ7MeMxrgQbI QWaEEzEwC7Gw3Mg1/sAnV9/HMAyCr/ADV7R4HdRIg8GwSwfROh2GZbAJ4zvQG4wvwArupFYWIyb6 AC/nxHZmtNNcJ6AzYRjt930VVjp3okXBnCmZ5UnDZrKniH0Y482wBOYiXQtjdzLzWcyXsxDWWOsY /lo+Wk9LmdacmTeptrDYC5OwLKP1Map9uYAd22PCmeByI4kUyFE3HH1VJHqKsgLPRicICM3WH2hp 8zRl5oNQT4erEEyDnUHBSOmksQOJtK4gHKmyDbKkha1EoKRVlRNArMTkSalXOOyEqRJSiiyJ5lzJ 91wUcOoA3TLFeZZIzijmxui09IIa2Eud2zo8icSITHjLg3Q7H0MbuZUKKW+CK9NryIPEEdZ0nNDJ qhJKhAIlBC3+KFQrQpMlNK6kPCidaAQ5eboOvhXM80Ti5hX2JhIsfvIddqqAsn9snmXauDIGi/tw MLIjObyolTAB/gZKOxQD9/qj5KxjDpkq0/RaFlico46RHTKpCkTpKRDUD4ZUZjybiISV9R3lTiud EvvhB8JMsUNG4cvFoCCn4aYTAR+Qiic5atKncjrdqtFqP8K3Dz7CHO1y4YWOXpzJsfrYAE4wcxnr g3dACHFuWvTXGnUl6cMW6RXLOFzYOvFzJsvtzjvx8G0hJp5b59XXIp1r6/ArTVHLThIsXTUjL6L4 mlpi9OjReE3V8KSywnj0SPLxaTJfYp1ezqnN0S+TMUR4PtCmUKhq3KRxoDe1q5g5BhlzO+uLQf1Z gqhh4gTib8UMoCL4LEdeeaxRu1YevxKBquhi70SsXb2cH2SSXNEXFRvRIGLHkgST2Evms1hN7y+n aqMHpyp2838V85C8L2qQq6ai7C99glmcorFoOuzrDOdNmVmzgsWhW6PyKAs5WjqlqUHQdVVh3y94 pOO5+nYS1O23BvW22+wyxn9bbVE5xmOvyKOFahTer/DgWE4qu+JsnTZEdzKLTy1qL4sJ1MmFxg0x 5ErWNniGdONXcik4J7Ka4Hzn+vqXlaeap54jazWXNLNrZilnj8dDIHXUsE6C+FyCGP+3PijvTqJd GLUwjzPPUzhOdF7/hyMwPKrNViPne0FL6SlsxkG/2PFptW5w08cTyrtqabZ50uFVyxD/+zT0+S6R s6QPArs2GdSvgjD5meEhZOFBcP+SAcFN378bQvv6sUSHcPuKHidR7wk//wLaOlfWZW5kc3RyZWFt CmVuZG9iagoyMyAwIG9iagoxMTkzCmVuZG9iagoyNyAwIG9iago8PC9MZW5ndGggMjggMCBSL0Zp bHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyVVsFy2zYQvesr9hZ7RnJFKYmd3OTY0yqTJoqs HDp1DxAISkhJgAFAy+7X9wGgRFBW4yk9E01I4O3u27cP+EHji4zG/q/95dXgl+UlbexgTJvBj0EW PlL7wyu6XmHBFWUTWhWDuCejyZQuL69oVQ3O5soJo4Qb3RhWOArPNyvoA7PCUqENMUVhUcG4IKfp +tcFHZ6PjRI0GWevz1ffB9N3tPo0OMNrTbS8/Tq+fE/zyfKOeCmFciO2wb8kHvmWqY2gu9++fPt0 Q7apa20cua1IV5+/GmTTPR6etZBqQ2xdhiRqI7WRTv4jkF9OXCtndOlze2XxRulGcVH5cLqgotQ7 wLVAthZcFpIzJ7XC4gK1kXXMNZakQsVV+EJGsNyH9PXO7q6XIdDitgMyusFWxOOsZly6pws6LLbt 6nYRmERCMeBOuq1UxI6B6PfZH57wHTM5OXQDOYbUjzM2ggv5IHIqjK7oFiF7xbG/fTxwFMgMnNsh Wd0RPAt9aOlfiwOpVqi8g8Jy6OBUAoe4QG0MFyEaa/sGDpPKhK2xQ8QFnlGCopR2B7QLLJ68PdLN VaubDxHxeaYByScQqKNCliDwWDFpM0PKXfFoj7WaS+ZAo28IlWLD+FOHaeywK8P3cge57SP1oB8k 66iNEkeGSFYqqKosESGlxEdYLiGV1UvtaPe3jQhZ2R6UjxrhhiFFoTaID6L9y9popzlmggXdhaFp 7DZFMzbB0qnI999Pduddb6rvz+z9+ckW/WiEdc+pOW5Tv5dxPsjXHapghlUiTJDbMi+uomwEZjt8 XSNAV0LNsDGHUi3qHSZNYzXIgGOg2xS9Jyj2QF+MGzJLmuT3t6uW8+vRHC1HeOg3hwDwoWJK1k3p QbvsT/CVjXt8HVPlu2wafkxUpPU5W2F2no7NknZboQ4FoVoMpfdv9B323Wm97zne3eyTdaIivbbC PHjtxIlqLTqM7X764Q/BTueJ3yyMKOSjiHaXzFTdvofOlwmg1y8vm1y8p+z+PGndHqZ1+dbAg1t4 PeSG7dDSCSjpL02cD8eI8VXnlDch86JkNeWsqrFu6JGm6fbGxkiQmj8BkXWH5XU1CnIKByBtYLc4 BRdtuenwRlXbrW7KPJF/h5U0rO2VN4y6WZcS0wh426wtNxJ7K+FZkrY6NXZZ9lMZPTfFxKOORRTc MLE6r5ODv3Tny7px+M93wd3+sJndfBz5YejKm3/e013rUvKnYQ+rM8DD1vnnYQAGL0nzRBmjMBvI D7McR3gP5zf4Eyq46zzIXPjU789i/JRxNYqAKP3+/CSZk5fJ/D/21VXqE1t4JqQ46Z7Z9KXIzw1h 9h+ho7ulEbG5tSzTKLW/veyPgjilhyW9iwNuUIXcNCYe8Sczf33qNvcTGfo7lbROcnuc+PHhu0An h3vDbeXXuyXYaHBcGMfSE7ALQVuGPbhbCpEDtpSVdN59Zgov4QHIDdalVfgJZ2DqPu1RmcBJGziq 2OMoWkaE9MS8fRNKWSD/ckjwRFZeUPfcPtYSRkQ3qKNa46zIpsNwRab+8+fCH9Zv/gLi7WrwFX// Al8SpiplbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjExNzUKZW5kb2JqCjMyIDAgb2JqCjw8L0xl bmd0aCAzMyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1WTXPbNhC961fs5FJ7 RnItu7Gd3pLYTdRJGkeWpwc7B4hcUkhAgAZAKfr3fQuS+rA10x4qj60xCC72vX37Fk90ejKmU/np vrNq8Ov0ksowOKVy8DQYp4fUfWUVvZthwxWNz2hWDNp3xnR2TpeXVzSrBkcTG9lbjqNrr4pI6XMf mN6rwIEK50lZSpsKlTFFR+8+3NLm82djmc5Ox78dz74Pzt/Q7NPgCMuOaHrzdfz6d5otmCZn0zvK jGYbaakVxX5NlbL0+f5uRgu15PRAzbXRcY2Tjn8ZjM/7iPh4VnnaYlw2mk7ejSY2JRPV3Mi7KlLJ MZAyJm3zronAkB7I/+9vELGLtVCBau+WOudcQCm6vWlf8CfYdXbxDMnF/4pE2xAly5xD1FZF7SzN QXje56xtD1QZAlRyRVq43YGQ81JnHE4ImelAVRMi3stMkz8/nkJT12adVneO3IaqPRf6Jz0e/fVp Onk8HoKOllTQY6MuNHtZS8mlzezZZrxZ20aqOHqdyQPLP+No4WqKjbUsFcHWckGrhc4WFKG2Qme0 co3Jac6UKe8154e4v/xP3N99/HL/6XrLPn6f077DyAst6T0tOcp1yNySPckfo+pa23ILsy0TYNoc jEI0lUYftNAqtRZAQRUMzivlf6Cu0kieK7dU5qC+rv4F49uDGDtAz3Ei/crlulhToQ2SQ+rkGwNd Sb7a6qgVConi8ShzVd3EVoKtyLYoW/nttlhbwrhwcIjaGZ1paTCH6jVYCTVnWqrad57bxgIjL6mg rjOxfe4a5MZyGOcl75B0DoXL8q130WXO0Jea/a6AJ9C9tEyGogZgBetAVQGQHBXYpz4h+JewBeR5 4jbhckhsj77QzL9zFlPXMEoPka/QBaFOioEqfFPL2QHdgrShvSANU3sNeBpH5w1vgfcd55ssaika K5+7VaJazofHhhQMdiTlCI2J8sxzxnq5lVylDLBUyFzeUhFNNheKQc29xRP0GHCZ9RCF94yyWx6V XuGrfYO9d76LtYAIjEgiONMkKMNOuW0zdlmgIcBWbLvBOtJVrcCLszsacX0lejx1V6OhVBjHE5sm APi+5t9SbZSV3D54DJWiMa17KRNESl5WTGqilGvr0EZXulWLqqCVuFc1UW7nKMaFgCIk0bcNFBZN FNJB1t8LDUCbtJXpgHh+ajRSRpO1Q0/eE0AVZ8hBhyqtln26fUg5WEEJgWNPSfF4vF9aaBMSyFAx aAGUPEz/eH8xfnP1rbWPpP8XCYHIjIFCetbzJoB0Lz1MRtcnmmOBErvVaF7Wo1ISkoB5rvfiHFbC VgNZKjlqi1nIB/F1gXYh7VczTZ+AnhEdiG02QSbZwq1a69Ii0KqVyf5xcxcXL3z6YLv0RG0S3G2k A2mdn4w717hJeD/2eKWK7ZWnc7a77uU9L6mhIb25VLSmnDJnm4yQLQhEfZ6xuYcjQjlWPzXdLWrv 0E3G6AXInjA9dNVUw3TUKFN1OgU7e3mmi0nokgi6lEC4l8GgMBVCg96Fgbz6vHGJt71D0DQ5Ceev ulDifHKj2w7O6FbgcrPYTh9I+vEY6T1fkunWRVJGLHHdTiMxL2VGUVeMI3jVG8LuoMych55rZ3Op xBbd1s6GBKZkfuZrqyqN6QMb0MKcd6WMrE1Iv7kj4e66cv5Hb7iuv7O01x3YdhCQEFytylaEGOw1 9zeqTcQWnhQcoV6fpTLeiqkOicWaTraXXrr5WWtpzWuQW81xSRifD9MtmPY/D7egmC6+IeLNbPAV P/8ABL/ACWVuZHN0cmVhbQplbmRvYmoKMzMgMCBvYmoKMTMzNAplbmRvYmoKMzcgMCBvYmoKPDwv TGVuZ3RoIDM4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVbLchs3ELzzK+YW qYqSRUk2reRky3KslB+0SOdi6QBiQRIhFljjQZr5+vRgsXxISiXkgcVdoGemu2eAH3R2OqAz/pZf Wfde3A1pHnpnNO/96A3ySyo/sqa3Eyx4TYNzmsx67Z4BnV/QcPiaJnXv6NZG5a2KJ++8mEXKn29B 0bUIKtDMeRKW8qKZkIqio7e/j2j7+SNZRedng8vjyV+9iyuafOwd4bHwisRspmRU1SnRe22FMZs+ xYWi2/O7MUmjlY33R+H+mKRLpuJXloKeYyVNhVwi1PEvvcFFB5m3iTl2BXI2Z+FdQl6BkxJNYzYk aKYNHgFMRFpn3Klxcgkkxmi8a8RcRA0AN8vZMI6I0espsAjlboH7JAJZJVUIwiN3jT2+Ur5gIWhU deO88JpD64pXSGeDDlFZueEIHZi2c7wFm3UbXEjvQuiQkAbK0uAMQqydX1LCX4NyGoUdFi9R2E+S kGKqqFIrZVyjKkhTFYxKNcZt8Git40If0HOKJeevDmhsmVFWTI3K4efGTcH7Sgc91UbHDUN3T1FT 9M6QW2Vm1YEsyMPnmrAwRMEc5rL7XSaC5noFad+k6KyrXQo03oChut+qpDsatlQztTAb58F4nJ9R wlsm0c365EUDsr0KDcjOluRka+dVQZppq07mXuAHogRncoIvgnRNi5HpgRmik6gLdLKpcjYyeY9/ ZlOgpEgIIcBviD7JiFIgu/AnlVvbDgmdEhCgQCDXipNaa2xqPP51GungUxPzSuwMyq80St7T5+L0 HN0yTnXNNGBNVutaNCKrotGRXGpuRyEzUsF2RHc3X88Gv+6314vcLqR+yoWwc0XjD1++fXxHITWw bczEcnqQyut4KCv3MCL9SBqdaF3UMy23fcM6p7DfQY2CNZ5YoeTG6VlSQi6KJf/TGnR/9GZ8fwwu JoutP54xGzZoK00C0TmV59PthN7h7CuOt1JxL/0vjXdaXSI7fnHHJdEnYXWTWqOVOJ+SiXprMl76 /e799eXw1dkDB12xPXZaOFjNQ/QyLQ7E2J8cPJErjdHKNm2nV1WhFzCrRQ2TwE9Ucqqf5qQDLZRY 8cCqHCZ3O4eYO7h8B/sY8jBqwYJ1AgxYaLgdrS5bc45Wr54CcBfxsmtX18lmKxcYJmVwdTV8yLsd UvF0m+vC35uD8Zwn/bYqtRtyHRanOcE5BvXpxs7R/8pzxzfJNy6okuqfo8/PJlhAbn5ifFdwxF6u rXQXLB0Pp/aQSXYt0InVXh5thAL03rh1aJQ8DLbJWC9fDl8+sByIm6eFtjC0MXkTzj883Q4z0x1y j+NWIgqKbb25VxQYMADgmkOangR1MCRgOAkm25HKivCEwbSIbi18Ff7Fzs+K/6zx9ptjgISuU4iu 1n8zRegtGom4oLEybVZ0zVPHa1EgJ2WWyMNdDW/aHQehvMdBWN5JVzcpiq7QXdtsp0zu30aJJfNS jlikdxtbARLfTVohui02W3B7MHU79grqwrfWZpk1hpLqvCP3vLO0mCMFC1cK6UDF3nvGffSozAJl XZov9tv/twIzchptyvLhBPSZzfuj0Zdb3Ka4bVjfHGYlTMonZLlYrdFditr7QYHa8pg3dQWSXCi5 5PtPa0++dmBgsL/Rou1Frjiv4Ki9fkOVawUz45evcpWDg+6Pxh/efEKCRttly5p8Smd37O40ZVfx XRWawj/K9ElhQJnT3R0UHdvg8hToHW4Q9RQdMrjo50spHX6+j3Ag0vABiDeT3ld8/wF0G7BlZW5k c3RyZWFtCmVuZG9iagozOCAwIG9iagoxMzIyCmVuZG9iago0MiAwIG9iago8PC9MZW5ndGggNDMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJytVtFyGzUUffdX3Le2MybETiHhMUld CBOKcQwMQ3mQtVqvyK60kbRxzddzrqS1d9sGMgPOTD31SkfnnnvuWT3Q6cmMTvkvf8tm8uXqnLZ+ ckrbycNkFh9S/pINXa2x4IJmc1qXk7RnRvMzOj+/oHUzeXljgnJGhS/eOFEGip+fvaJr4ZWn0joS huKiUkhFwdLVt0s6fL7vjKL56ez1q/Wfk7NvaH07eYmff9Whopv56m5KOtDOdnVBG0Wt9V5vanXA xQqStVYmMHLb+Yqc7YLyr15MZmc92o7RZOeDbUhaH/BP03RGBw2K1lCoVGQVt7rEeo1ySi2BwwgL s9VGKafNFqc48FAnNDre2B1JUBIykPAkSOJXJ2rClw77jHOvVMsYeCLvyZYk6ro/CiuPhxQiCPAS gbYKgG2LU4qsXsZKhcbitIlqcA1oxc66+xMsmn8dBXh9MgfXt7Xd+VZJWvX6MMY6V172T0VROOUh gWh0vSftqfPp4EJ7rxptRFBRsHAQ6Cg0wxDjaDwRQbO29iDvZRessY3tPN3tfVAwl3WFcomS6zm9 f3l5d7Xy71+hpoKWzj5qXrQotgrPlgs8yI1CWVc2VNPjCbwxbsMvGW658NlAYGx83fN3Sir9iNp4 Yy7mcwVoE2yGgsaXUrI81xbNtTXdargJhK9vM11tfOCewrVoSuL5IjpqJ1yBzmaoVoTqhCeFm+07 WREw/MGB7KToqFrA8eV+Sr4SrZqSY/q1bnSYZqRS19gyJXjWqUKjrDAqxw+s8N8m63kd96OWDxuC Vgw6NzghV/IP45MGhrVicQf2iwTy/o9p8PQIp/qeoNVPzEoi07NIRcuojKg9infaOoTFXypWInPv mYUwxnZGqoa3YJzDKDU+J46Q0kYjsEyPAtAYh8u71VWS6SDRC39QpRUSErDZR4oe1aQfLn/rLfYM YQ7OLx0CccGoWCHuGQmkYmMut6iI27SudM9klyXhquIiERfxntwtJEYjDH5OLY8hJ8ye1Ad+SfDz Prt6Ck8Pnh9F2BmoxJigt9HvOcaiXW/VVsj9RynSJ9to0/PTLW4bOX0tHEdxGjd4Cic3KSE2sJFS hn5ZvqOhmFm94dpMTrM7saM/fdNpVjb1k7kEpzddBN860VbJy5WqW0bLIDEFopHAt3W2FdvEBz5k Ku9uVzfIpmxyuhV7lk0JWYkNiuhbcXNkhwzrJyQiHOfjO7tTj5wyyAynHjrETD9gaR4zGJfPO3tj 8vh1LWooUqG+a1vrECmsS4nJ4WNFzfbOCD8CzO20VynVU/lDtaOgeIG3tYJWO5ZxxLYfGzgIOnpW o04G6UlF3q1wQUuNHFYMGBEgORUW/ze2zyTN58TpHl0SehuMDfW/JW1iOg7aT32X71Kr1aGyaMZK 1GV/tRhXnmt6Vv2HVoHlJyIMbyBPSDG+Hf37zeiTgEcDS73t8E4bzXAa+Y86ymnDwh0KxN0CWuDa hLFwmod6hdTcVZZLDZ0zuR9RbR2FHwbrsL70sjLJsjuBV/Ew+3gm+/HF5LVBN6jM5fRgkKemOaep Z5cyqyQjKzCY39gakZGGI4mfvppHbyxRXT0lviXWJ8eLNS0+tHFK3yBqmw0aNDubxps2jT+/Lzmv L/4A4mI9+Ql/fwNBE/RGZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iagoxMjM2CmVuZG9iago0NyAw IG9iago8PC9MZW5ndGggNDggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFVtty 2zYQfddX7JvtGUW25FuSN1/U1p2kUWxlOp26DxAJSohJgAFAK87X9yxIiBerDTVjWeRy9+w5Bwt8 o5PJlE7403wnxej4/pLWbnRC69G30TQ8pOYrKeh6iYC3NJ3RMhvV70xpdkqXl29pWYwO77SXVkv/ 5taKzFO4vjhJN8JJR5mxJDSFoEwkkryh618XtLt+r7Sk2cn07Gj5dXT6jpYfRodnk7MJ0afSq0L9 kCnNvytPN0Z7a/Kjg9HsIkTRf4WQclQ53ESt0ppnlUqypvKSTB0vvDIasFLKjUiRcXoaM6bKeatW VYhg8EWVe1XmktDi1tgnSozWMuHnjla4J6WOz9wEuTjLH02sKaUV3lhHCUgojFb4QXcL8uAqUwll udm6gMRvkCcxVZ5SKjOlZZOqNLlKlKyDbJXjv5Xg5oAvZkly4RyhFgAXQidyTLnSTwjU6ValftPk AgDphX1BHeddE8QU9Noe7/L6l1LGsEyovLL42eSSPpn0tPhT+Q3dze4fxgQptqGTlQR+59QK/EUn IAKAldSe9QFcVVa5gDiwRU+KIFndt/JoT1hRSNjIgSvhSeksrySaDX5aSedLAQSpTJRjcaIW3YI1 vyLxJJCYEtyzIid8Kf9Sp62BR6lQPHLXAxrB7aSIqaJL6gdRPLj5oUqiDM27daWgO3hS+itchXdW L0DWBa00eELYLrczgN/kwqO19OHxKyF/6t+OgGeT8wCyKNgfJqsR3IhSrFSufDRgWMeifrtBYIju 559PZu97oB9++/Tlwy03Jlh8XomV23Sp27Jfksp5U/Rkx8X2xJ+iqHRdGq+7EsKyKUMVsUYRx8Tv MtowbBpQuJR20gYalG7f5vCFlPbx0D0ecV6hUlo2fpd6jYUnrdJrUNCmSoUXxO5iIZcb6WRsom0T 6idPtXwsRkB5xShbrXD1cLwmQtpXvQ8qtqkeD7cqz4/5D2nj0Q069iLPAeJZiYDi/u76zZ3OTH+l Noqd/kyx0FLIZaVIj1GEoYsofk8y1N1LY7IRes3mKUuUqZF1Fay3g7arek5jaifS8f4B7Th1VJh/ RifvbersfYf6nT6uKktjsZRSXuqxCbZ5TIx5MJw/uK4eru8xABfzGDemu47h9iI479H6JvQ5xLG1 0BbsdLeBYe1olZpvJqrbWD2rWPtGdda7CPw4ZxKFOZW2rDLm0Evcajot7W3iomni5v+9wbgHQIdt tKZknwf9AoU3uanaexrwdk5zLAzH/FLT0mR66Nbh8c+bXVzgLTdjwtTjVD2/UmbDnGlytRbc2/7l Pg3l99rMQzF3y72OHhKwkqz0bgpaZVj8HzJIkTQnFnR7wOJoU2FHK7gcOMh6/Q8MgcMWxgXI9ZXr scEUcskoeii0mA/WmD3gQ0kpEux8k6FDWndQBkB1wajVMBF9vPqLR+9W2LTn6CFiKxOpnuEE1oLm vXWPUPEU9nbTnQ9j3uwG8/S1GZ0M2/TFeaB9Ae/nYxxQMDkm7UETR8RS4QBDt4BRrIB7ejoOJ0/q X38vUJve/YOM8+XoMz7/Ag1qhy5lbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjExNjYKZW5kb2Jq CjUyIDAgb2JqCjw8L0xlbmd0aCA1MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nG1WTXPbNhC961fs5BJnRnYtu2k+eoptTepOxnEU+dT0AIGgiAYEaAC0rfz6vgVAioojjUcji3j7 dve9XdzT6cmCTvldPmU7+231hrZhdkrb2f1skX6k8iFbuljjgbe0OKN1PctnFnR2Tm/evKV1Ozu6 tlF5q+LxlRd1pPS6C4ouRVCBaudJWEoP1UIqio4uPt7S+Pq7t4rOThe/v1r/Nzt/R+tPs6P8S2wU YGrjHil0SupaSxG1swD1rqUlwwTXe4kwQBUkjVY2kravXs4W5xMkr0KHcyo/5pWoCLSsiyPmCY6c /TEccUSr5ZfTt+/p+mz1lS4z7te/Pt99uqKNIrExCSshMQ3v+giq2iDLn4Nrixq0KUomnjA/bAEZ SITgpBZRVfSoY0NGbYXc7TF9mAOvIAmLp7weIx1AP2jBFcvogtGZIchqG6IwBhFSYQoWR1itTojW w5nE6BdJlvOlHYlVOIDiqBlunigqu0V8FJr/2XkXnXSGhEw0Adj1oZmi+TDBcvTh68Uq4dwuh99/ 2Z13pTu569+OwrdXv2zRfa9CfF6a5xqZ9jLkdnDeKQvhRauYCoAES6w2vbIyJ75BgH0KncDBCnoN yHc+aZroUIzOc7dJNsJus27H8uW4idmkSXy+PLW6vji+RssRHvqtIAD80Aqru94w6J79vl6vTzLM 8oH1VqA/anxLkOopetUqsyMjPJpm+3YDXFdPKSEc/P3o/PcwJ43sw0HxJLKDjQyzacSDooAvqf6t 4jx1aEvZJCYBetMHlXJqndURRoSICzH1kF1R1wpysduUDn9CglxBW81JspPRVBvNbs5tQ4yNNjru kOr1oEtRVTqmBgTdaiSHgM4A2iNJpapkh0kVC5WpZAsSh9YBGSL5x0bLhhplOnKd8gJHQupQBeaG /xWQYGRv9hbQOGurASdVJRHl+gZXx0dmw8cb4av0JZWJSSBto3+on6SfBe96UzHLB12xzbp+Y3Ro jkO/CegFCixFN0Tiidd1Zhyd0b0vfByN5ijZc6FL54sJmJtXJs2n3Js/UxP2EPugRaQTT2b/SQW1 DZ0dwPIWeObBHBV9cIDyYyeODzkwSc0LBdxPplJfQAE3k6nOD66Kgg4MgKHHlcefVD4KKOGa+65q /aTQZl5a6km0Hc+QxoXSl9Qtv9HRC6/N7tAEBqMcgUFys0NTtslixTajWDDv6UWjtw3GddC5RS/4 gB6pKVsdwyC+0MiK022rqjQ47E/pDYNEJz9rn50ymMBPHQ7Uuk8u/W6xU8UGlUHB7rAan8GGXjYH nsQgo5uSzeeUTZLTpeI+0Lejm8+XmL9ZmnndpibLPkTXqsHf2t732uvMV0B3LHmd2NUiNICEvni1 WeDDUTA4awrgmHO7NFWrITneJLhTYAHSGjcPsKel3WqYOwk5aQ/BEQHVfNBSzUlFeeiny977Mkg4 jrMg8iiSa4wSfizFIDxdLjTPxDtxUNiFqFqGQHiRrFl2Ie5DvBPKaqG2N1HHHh7Opit5lZ2XKmSx DfOOtvNxUTyPxQMt7RLj3PehPA2AtvsVdnd79WG9fBkOxh6qadH4XVF5yXIQ++DyvdvSmZhdppgR ClI5FexLHJDoPkzPBWKquO3FBDUSGjwXEMdjXxwOJg7awhqRVwSGNqojrHJ9SE7L6sks8uxODSoj ayDuRueNfoa093wA9Pos9ewWLjGsCBToZH8bpeVTpxGDrjC30ipcnM/T9ZQOXv/c8hVncfovEJfr 2Re8/weBGaTsZW5kc3RyZWFtCmVuZG9iago1MyAwIG9iagoxMzIxCmVuZG9iago1NyAwIG9iago8 PC9MZW5ndGggNTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJyFVl2TGjcQfOdX TN2L7SrABxfHjvPE+SMh5YoJkPJDnHKJ3QFk70p7khaOf58eScuxOVfCle/MrtSame7p0R1djyd0 LT/5b1EPni9f0s4Prmk3uBtM4kvKf4qabtdY8IomU1pvB2nPhKY39PLlK1rXg6dzE9gZDqO3Tm0D xc+fnumN8uxpax0pQ3HRVhVMwdLtLws6f35rDdP0evLDs/XXwc1PtP4weIrHYa8CeVszqaapdKGC tsZTrU50VCYITHkyqsabqjqRNp5dIBzmuLYHpqv54tmTweSmw2scb/U9ArJbLEYw7MPVkEpu2JTa 7MganMlkmMu4CF+0owKHBh1aNgFwAnQZzhjPpj92R3zSYU/z6XI1JB1Ie9lcsD6oTcUpn14qhW2r kgJXVSwQ9vUCLiqNQ4fY6Gy725Oi360L+9GtbU1Js8V8mENEpufsrujzU+uGOdTZ6stitv71iR/G khe2rlujg2Y84FCMPz/LYTm+LMuY6D0KyfeqbiruwHD+xzeXGUQuNnzexiX+S8VemR3KDH72GmEf tNcbXelwyjgoSkBiQhUoO+iCR42zB12yo0+8Ia8D+59JVaIqHHTg6jTE6Z6L1j3A/G8gfMApnpT3 ttBKHh6FH0Wl3m6x7kyo5yDZX1QRBVhDCkJJpoGOiaw9mygJW+kSmFExlfYdVB8GUYOpiwBQG6cK BIkdusB7FAlx1xakWIcFWJ+RUJKdU3XkDfxjj5ekIJTZSrbZjRRPAoDOfLvJScSlsem6aic6kNFK eilzGgXeMQVY2SY94IMkVYM36NcUVVvy657ELUWtdjkietmmjIEoCyQAUqXKpVNH09Xku1t82+C7 91yiB9voCjF22laqoRJRssG6HsaFJIDiw6hRIDThFXvrwU10G9phxcWRGeSTkCeEOb5rtcis00ja JaVexhhiP6QCl7Q5pXe95kyUxD5PyjA26O0pSUbtBLXvDWc9pZd5114hFUVNu4GI9s+Fx8JpkQQL O9rXdNxDq5tT7/SDctq2XpQbmXzkkA9AqGtO8rLBc0X+Q+Q5JPniz3Xytn9UXJ+xdF1zKTKHGTsW 24vdUcceCOpb6hVsd7Zxso5KWyttRr7hQm910fV1EVvaAMJ75U4XZXwxnkpnooWE8bcAasDPmTaf EebRe/k+YBJINK3nbVvFpmnYKXSaz42XjBnKU40uZYiUSBM09oqNyRIUxO0TFVkoSaw4B8RnCUpm and2mtitnRG3wRpbC2erEwyqRh4z+C5azei6rYepj9NEAENtJf0nNI5sE3Stqs4WMEStqyUeCQdH BKA1sXklEVbFHtvwqwTP2nxvTK1TGvgXjrafnsl+UrARiSEPDCdbwHhlJmjnMY/Ssb0SrZKP06Lz cWC0XmK6WllcCZYMz9zqXeuSX8/NRobYVewfjG977LhLE222ul2eXS+mlfSkUKHmFBX/QMKQNi1u Cnt7jMMsAyV+jioRhLLVOqTBADxR4qz8OlrOb0dzjA/rA1z8m4gFG1Rm4MHTZb1OMcdzG9h/cbpE jvWXUXo2nThDWp+YzVCPhCN9RVzpnRYlig3JkoXY2oorjq2Qh5GXGp6bLZMmOEmVEmIP/iFlGNi/ EujElNL4TklSTbMvPw4Jlww95vHrjAP+wPmHj29mH74slu/eD/EEk8V19w+q2OzC/nzn6FjJno1v OD1jia9T9HX4xjBNtju5fcklIIqzUQ7Ds62Ue1TPjIE6HpUrZRyZ2PaAd8n8jKriLpgOLCnN1Jj6 CmWGFDZYC5QX0yjthdiZhA2Rjh9urPTuvtHQCL2FLusNsCc3w3iFpd7nrwXMniaTv4H4bj34Az// AA57u2FlbmRzdHJlYW0KZW5kb2JqCjU4IDAgb2JqCjEzODUKZW5kb2JqCjYyIDAgb2JqCjw8L0xl bmd0aCA2MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVWTXPbNhC961fs5BJ7 RnEsuWnSY77aSaeTuLE6PdQ9QOSSRAwSDABKVn593wIgRdmuPB5bJLB4+/btW3yny4sVXcpP/lu0 i5dfX1PtF5dUL74vVvEl5T9FS+82WPCGVmvaVIu0Z0XrK3r9+g1t2sXZpy6w6zi8+OBUFSh+/vJM 75VnT5V1pDqKiypVMAVL7367punz+9AxrS9XP51vvi2ufqHNH4szPNadD6or2C8pNBy3ODsEJu3J duZAO+311jDtdWh0Fxe9vXn3FS9p3+iiOX++WF2N0UKjwizGXgGYdj6QYQXs5QXRZ+bSsPcC0KvD EgjIKFcz3bDb6YIRUEJdO7vTJTtCynvr7nxEQIq6oWWE99iIXAvbdVyEGE6R110NrMXgg8WqHEoH KsDNlmnH7kBBt/wC+/zQYrlsLLUvLN4hI3ZMfijkoDkXOVJOA6HAN9NgEEsFBk0lAwziScR9c4g8 HUnYGlvcYZ8dIXU2UO+4YufACh6ufx45/FvS/LT+erMU4Hs7GDmPeutTIcZKYwUVRnMXJAWnel0C R61wsjspiu6wBTA1SlY525IqHIIhw8S750C2OqbrhNqYQKYe8TPsMUsm1HkvxRYtPPePtbNlYWJe 9vsQJZYjzeEXMcdYTmeRAMTbWM8TGgncW6MLzbHOE4ocK3FtpcoDtiGXxxVgLbxE3sci2vg1x5iK IbnjQED+VXfKGFFoBSbQIl65Q2qTGfrbM397nlLIoVTLXXkKWuFBP/hGNrcEUGN7jiniay85hZHJ HCslAKStumPRg5ohTS9VUVhXZiWPdeghgxzCs0GDSPGVqa0DD+1McK8urpCqbEHDBVtYQzcBWvFB F6PqN7ErlPzSTjnN4SAk+2kdOTYoWzkisMgl6S3p6rFHSDDd7ZQZlGga+0atpb3W+Yt4MOo5O6fm Dm9RlIysYdMfdywjzyXv2MgzfB86OIgYXBlxgTovgpOILItzmGoIg/R9oYzaaqNTfqKCk8780s3A pDy0f5DGBEZeyZnFgFrhTNjW9kFjzpvOT7IMDR7UjfQ4y2u4uweVoOPLFBuBUc6+n4hQUGDbSp6q VuLpxAomNg8g6IweJdaqe90ObYYFKDnQDFBMsFUHcZ+H4OK7k+jZElWOs8d60WQrbVNHSwhO1zWL cIHzJTQtOE5iyCLrOirtvstxkFZvWCw26gEr4NyVrocssEL1Y8lkYlUBxEwNIjPBT5CeIecX0j36 PhHx7Bgycddibki2QgDsBXaqhlKHhFh8YHTvoxuo8hs2JdtAG4JK0TJcJmeLylTKeJ4ImUZAAKWS KJUDj43TKQhRGSyqVQeN1c7uMQ2SJT0Uinj5VP5a7zit6ljXzda6U+1Gx0IhuuCz3/ZpwIrOZhKe 8QlMsb8iB7lbjuJ1DC5t7VQbkT8mV24ISlxN2xKpbJXX6Mh4ZzgO1KmhsRqXFqymUkmpb3oudKWL 5MByQrpIBOXvjkMxzcInRgqwIyVdpmGiouZdVKF6Cqq0ko6CybE43hQe9N/t2afqGAhFXqbYvol4 8oiZCj9auMgHk7Ydi/z5y3v5F4obYuaCI2Rlg+lomy6mNo6asRem3NSA+w0aINKTjODpxCK+/Xw4 GcM7nWjBkY36ISocZoffniPVt368HT3J23gdyuwZx6o8iEx7g7vnoxmZC+bhOAZmzDhvci7HIAx0 L9PdJNrWcTIun/DQU998cDOb3JPmxiLNLRLHlc1L52Ru/zcjcctYWcxyOhVBmkmYVSng2E3Rkbfj jaTBgXLDqKpYreTVqFYsbow83WG8XC+Si7SxO9PdC4FerWOvXcsFc0m4pClzcbzP08f7XmOe0QeY UaRldbWMF3w6+fxzLfa7Wv+LiB83iz/x8x9tEyInZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iagox NDE0CmVuZG9iago2NyAwIG9iago8PC9MZW5ndGggNjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJyFVk1z2zYQvetX7OQSe0ZSLTmtU9/s2G2VyaSKrZzqHkAQEuGCAA2AlvXv+7Ak RcofCaUZiST27b63H8ADnUxndJI+7a8sR7/cnNEmjE5oM3oYzfgltT+ypMsVFnyk2ZxW61FjM6P5 KZ2dfaRVOTpa2Ki8VXFy5cU6El/fg6JPIqhAa+dJWOJFayEVRUeXfy5pf32uraL5yezD8ep+dPo7 rb6MjvD4XSmeJpVXa/1ERpc6vqNHYWpFwivy6qHWXuWMroQsGBLugnZ2SrQq1PH70ey0AxNVZbQU EW9p62qTUyyUJeuiXu/Sf1rMb25JGq1sJLfmR6HOguI7BXTgJaTWRwAnBtFgF4KTWkSEIwthN4q0 fTP8cYuzLZRX2Uvfg+hEfl+HyCsSu8q76KQzLYB0dq03tW9I4csysDBBx8bEuxqqp3ASCFK0df4/ yPOHtsKYXReLjhQK9puppIlKAYjGs8jcIwgF4lgcUlWqWLh8T4CJtkCv8A2cr4aKyuF7Ed8HClhh hDc7qhz0zIzae2yh+vADlWI3xivcboq9YGOqamP49i2tQ4u1L5KUR8igN0WGRzDdUSFAz9lJ5oTP k4yCKuW1y7WkTATNiW5xAKpz5LnLu5SQX+6meD3/rSu11aui1egHiX5AggxXStsFXVIpRCQyRC3D 9KByV0lm1nCrhIlFKkcH//4tcwKzdNcJqS3ol02VsMbbLtPaJpUEi+8aIYC38aJMyyU9opAybXTc 7aGwjjEcNBLRITe5SxXTWEeXi6Eav04/IOG3NfD8LgXOhf5JVIJhtWq6iEeDkJHbKuXq+jF1Qk+p dc/Wt3/9/f3LVeuPpeYI4fu8XeaIbq6/zU7OD/qqtcuShUncQ/S1jH3/iQ2W3R2Fu2NgHaQA1xuD YpvadNCfEsMBpFIV2cFYaAPDlSpa2w2FHbqhJIcB40FENKXejQ+oLChUSuo10tDOoMWyh1lyrbfy DcZP1T6H6jcDwAC60tS5OqfZ3XEP0y2HKikoYa2rrQQOcrDVsci92NoxzSHJ4dIeItQVXoF1TnnN ka+NqCgXZYV144R0OjSvQ+OJUMvYNPoyxZWpECeVQI3znkEbjToA75ZuM9YHyRoMrbaIe6xBwtpc PWp0dp0ZHQpuEQx36XWW5llSSYfysI/bMpr9sIzA1yuR99Nq2G7Pi2jtXXkw11An/DflBzhSgTDo 1BE390qmjLLNxdXnyc3ictLTW3zt5K4cNjaMxyEWOscYGAO1M118HTMwdBkkT5nGiwgsPiXxx1xU HRw3d0jM4WvBZa5S6HdHjf+h4nbSAIL63fGrYs5/LuZDrcLzrnylIVn1nmkKbJmU0Dz0Xzg+/Znj l/Pg4g3PW9/trp3Dbi5iuNfWpvoejuamSfdL+pPE8z08vCrZh4PIJ40eP6jCg6l5EPhgTqTmpiUS 2SSb7bn6mr5pT0qhmW9S+Si0HZRNv9fwGFZPUqkcsLz3puFzgdPIE0YAYkvblVXtkSqo4fB5uXVh x0waPd/OkzDprAkqS8RvxoSRKMy0P0PS9VOF82CgK/AoM+yOs9MxHyrp4PpnCQHx7l8gXq9G3/D5 H26feshlbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjExOTMKZW5kb2JqCjcyIDAgb2JqCjw8L0xl bmd0aCA3MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nGVWTXfbNhC861fsLfZ7 jm3ZaZz25g+1z322o8pqLk0PEAmJSEGABkDJzq/vLD4kUaYOkkhgdnZ2dsEXOj8d0zl/8nfVjs5m V7Tyo3NajV5G4/iQ8lfV0s0cC77Q+ILmy1HaM6aLS7q6+kLzdnR0b4J0RoaPd04sA8Xrby/pVnjp aWkdCUNx0VJUkoKlmz+mtL3+7I2ki/Pxp+P5j9HlrzR/GB19PiW6lSY4oamV7UI636iOKtt2fRBB WRNxH6cPz7RAmJq+TZ/88YfRxee4H7AHz6gHI2f7AALCrWQg+RqkqfEYqG1vVFBgC3LytXPSM9j4 soDtcVAGkdvIASQna+neaDpJ0I4aq2uPNcBUZhUTfXqY3UOBGoAM1TlbAZ5jNbLlgLXETiyX+2Gw gRcYUm1nXeDfCUmZYDMU3xMdADunBBLjlM+QbCTD4YNYaOlBc94ojzyN71sERnq2d2BxkoEWNjQc 3CIXDpx0lgSZpagasssYC2nWcq2w8XQg9bUhodkDUGWdKfE2FfVsLbRFsQqpvqtB1kfwrN5A66Wz bUotBKCgQLcTv9OjcBuUhARVyS45o1YYIx0y/2pgubwnIqRKAdBJ6nrP+CDJD1i52f2Nz+mWegkX VKU6EclPJwe5J2VTbPUzWRP7B6bFQ6upEQhKS7khUa+FCWKVdGQUy0CDnFpZNcIo39L3o8j4Y7Kt /35MRoK0sYEWnJpZqlXvcEeZgY64hsVLIlZoRuzLLsc2GxVKGei3YXbg9WR3fmGlC1YkAeWA5Tvs 5t8VCruyTv3cqpzdOmAVtZ79nt2JvyLa+w1Q2kLjWGpLS8WeIuBQbzYQDPE8ml++o3hnuTQq7LKA fML45KK1UFoslFbhjbUQurWeIbVqFTAP2RV/VaITFe/hvN57jknCjixdErS2aGB2Yi4pLl8JLTnJ YsdD4o8WJvS2g4fgMcEZli7prIbrZKpZksKXUGgwrd4zr3sXm77ZljMPjzMUm2dIHj2suHnvg92I YtdjWGPM4XbvCygQa8UGB/Bgkm69+i7BWXJBjuWllhWPCBQot541+q3032GnffCHGS57h4UYJbLu q0Irzy1tBcPFW8rUaq3qvhB1xbm7BHFebaz7r8zGgmwXaxWnUzy2qEZhnFrE2bHN0pPvq2YHhb6G uDxdoRAMH6depChhMyNZcwGGSKxJDi59lMkNZXuyrCw3xc7O+wffwXQZWIIjW05koJwHkHDKeqa6 kVrHBPjPN5wYJ/TIByS+rm/TUcmWiyjb+XQn0eI1K54VLpAntGGmPJjKoAeL7Qi/nVCrVk3IMGvI sHey72e1UaAlMUkqFTNupO4iPQSQ6JK210F9zDhNOl2ZZyz7QmhhoiGSW/fLFlA2o1561BQTeDDU ey2c5rEj4wHSILA0q4P5cq295WGba8JdnifqQq0wwmNbtYoPdNwvjRcrOyjCfrIwnEdrarXkruc7 nEq0TCnx/nJ+mFye6Revg3A5kYulDnzNbz0VXoI45I/eR/4ZRL4KUMhpQf2e7RvSewk2LKSRSxUG We2T4qM7I7GlhqI9923Llsfe+4vZM14FuzSCy0SLr4MiZut/w9ZfLuLWKQjoE8JMEfp094pIk9dO YUzBh1W0Po0vT+I7Iw2uf6Y4VGn86V8gTuajv/D5Hx1ZjMJlbmRzdHJlYW0KZW5kb2JqCjczIDAg b2JqCjEyNDgKZW5kb2JqCjc3IDAgb2JqCjw8L0xlbmd0aCA3OCAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nK1WTXPbOAy9+1fg1mTGzsbO5qO55cPTupO0ruNMD00ONAXJXFOkSlJx /O8XoChbTjqzPax8iEICIPDw8KhfcHw0hGP+pb+y7P01O4fC946h6P3qDeMmpD+yhOs5GVzAcATz vNf4DGF0AufnFzAvewcTE9AZDINbJ/IA8Xn0CDfCo4fcOhAGolEuJEKwcP1pCtvnS20QRsfDvw/n //ROPsL8rndAyxZgNv4+PL2cLxEmo9kDSK3QBHhRAkK7Jgpeun98mMNSvGDcEAulVdjQQYcfesOT NiA9DkUWTbSVg9nkejAxMZcgFpp9RYACgwehdTRztg5UQtzg/2/GFDHFWgoPlbMvKsOMaxIwHTcO 7oisRmdvCjn7PwtRxgdOMkMflBFBWQMLgjtrU1amrVNooErB5nFh2qkgwxcl0R8BzJfKQ1n7QH5S 19nb48HXVaU3cbVz5C5U5TBXr/B08PVuNnk67BMaDaaEjgkqV+h4LSYXjdGhkbhd20UqMTglecPg axgsbQWhNga5IWRaLGG9VHIJgbiWKwlrW+sMFghSOKcw20F/ToXdC7dSpoBvL+i0qCp+nyfPsSmU QXS8NmtQY67OsLQvQqeMJgSJJ/ACNoBKArnhQwJaOAIqo/BBMfzGBsYrEWOvbUQ+uWwxfTpIHfJc bgCPxiMDt6gptKAd14kDtgqq3CbVjdQHGy0xVRODVhRgi1AQK+YwM7QSlKastXApUqeZhNaPpYpj QBVLGllV8vENF5BDEWvlhpnEzQlr61YffApkK3QxTB9UiN5Ce8t0omR94lNpa+I4+RN5w7Zjiasp kLQmOKuh0oJkYYEba5qRrawi5zUBk6JlmeIDid9NOB5IYTY7jDRnjQQuDUcLRq7tmiqNTX5LjIYE yf/nZHB7RFQLOCicXQ/sznDQtP657Q4dS7SljhjlS4ZUFSZqwjaVMsHIQKREsMO+RCVrZLTaRFLt Sk9hGgAYfRlqGv4NN4jeOUK3vO3wpx7tq9FDXZbCxS5G3bkRVcMkxXXQgVGoOaw1/rLtbiNh55fw Bxr28Pnb493tTsWaCvbkq6Ms7yRZ7UmyhUx5yeBDpwM7uWig68fMM6TMS0I1SUQpNiwMXuRIYFHV K+oKj7hrRvy3Mn3xHzVe/bbGVNDbOin90mYq30CudEjNrnVCWhlCnZlLIogDacuqDo2UN2K9q7KR 8e5N1UhhWFrPk6F5NuOMS1HTiq9QKuZDe4HZXSxC5D0UkC44Ml/QkGaAfBhmBXZAuqDBeUBZO27d DdGDuN8MfTs0jBw7cg4y3v40DdKpRTvlpCyZlXXJGArv6cVH48TGPfxougoniK0kWeSdPh/ehUx9 yckUme7AwSmnuN8dZoUhH6iR8wPhJA82jZHD5/b62+aVWTqEdZwnusBOJwgYouCGu+hbHBRVEe9b FiYT2pzwVfk4mX+Www7kj5TPlVwZu9YMP2fURVfU1HPn07Wn1SrOCF1IZgXjDG6cWCzoWv1i6cL8 LDSpMinyD0rwE1pXYH8P4RvhtPUwJb0SQTjLfgbuVZBLpI8L5ui1opcr0hHb8IVqU45EuoyJsUlK ztdFwZcJkYGrOTuNh0yJ3roPSN3WR7tPPhi/VspRVrcosVzQcA9P+vEbEPaen1OSFBiePlPE8bz3 nX7/Akk6b8NlbmRzdHJlYW0KZW5kb2JqCjc4IDAgb2JqCjEyNDgKZW5kb2JqCjgyIDAgb2JqCjw8 L0xlbmd0aCA4MyAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nJ1V23LiRhB95yu6 eEjsKkmRBDbLI+BL8GVDQKnN1nofBqkRE0sjeWZkTL4+PSNhQwSpJKIo3Ubdp0+fPvMCvheAb37N Oc47P80HkKqOD2nnpRPYl9Cc4hzGES34BEEI0apTfxNA2IPB4BNEeedsKjRKgdq9kmylwR6/KYQJ U6hgVUhgAuyiFYsRdAHj2xm8H3eVQAj9oH8e/dHpDSF66JwFvgcwxxVKFDGq8x874eXuRUCvPhcy Z5q/4uGiMwr3bepeeRz1yuWhVC6T8ZprjHUl8TstCXo2DhwcI50x5cDIc+BnlpVUjQN39kYiPV/Q 5RcmEweu6IqJBCKvybZ3fGYJssqB7kjAaC+rZUCv8ZAC82BeVJqLtB1qsVUa864DiWHUPV6N6/fg 6WxTyGfgoh2jlEVK6NXTuQOPbGsZ9j6INEzNbybBcDj4DjBZU1WS+vWMklHxc6ozkowL5sDsvWZ4 4FQeNe8Uj5MizyvBNae+j7SWfFlppDIoEZhMRHGVVkqbm8s2mDAIhgRmLFkiUNa8d+9xC1RkUiup Il1xYQIqw+JUJDxmGk8BmuNLxSXmKDQ84CtmitCMJzMI+jUqk9LwQ7xahEdAXYYG1LxQSAsNoi+S m7YBCU1ZZiyaSplnvz8+NPWa75xTuKzmKd+wna/XG4YfHTGtsDnuPFjEVZIYXroTVrIlzxqik1eU mitb5amEG67XZuzcfgPPpHFojl4xX6IkdfjhESwXFwbLHFVcyIzAXNdgxh7cF/LVYrmteIIZF82o 78ihr09hifBNQyFggXFFq7ckG6EoiKSJpqumQ4OwAUoYaBqrbNvWOKHutVH3w0FgUT+vtYH4lZpm lBs1Ql54u8HujmBM0qL6b0lEG7Y9BXkmC13ERQZ9GjlL49N5Q6TJRviYqJg0U+YfEXa/d+kTogUT acZrXUesLM2k7Rzlq/cB2IwYXL9pFAkm/2fWTD4HbnAp/wnUwIIaU+WqJmdPcw7cM/3nUXinAHUf q0zzcseUxa9MQ60u9rVnMr9TdrSr+3NIlh+S5U/F6t+YfiqLjbtMSzdV60qfdPwbsrm44Kq2tyuM JUNBAz6muxnZhDJ9mJgboicjNhoeJkeM/4ZnakV/MwyS7H1VZXaHo93P1A8GSFJsxKGft+McQnf9 iw97P3DzD621HN3QkMflGqUqhMuldGW9x7hlkfF468YHo3aSnsd4VseoFTDKGe1dtXB/oa1JbpBn xg1qUh48GGeVeHbaNXWn8zn8sNvpYGZRmIFf8bSqUbTGvx2lpu0/FOb6QUNeO9jf2FxgqXceGFgP vAgtI03nUQPLvL3vr99K2lKUEU39XdBzbC8O03ybsZQ8/tJwfB11fqXfX/jOhlFlbmRzdHJlYW0K ZW5kb2JqCjgzIDAgb2JqCjEwMjkKZW5kb2JqCjg3IDAgb2JqCjw8L0xlbmd0aCA4OCAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nHVWXXfaOBB951fMyUuTcwyNSclH38hXt23SZYHt nt2mD4ot22pkyZHlEPLr944wAUqAw8FgaebeO3dGfqTDXkyH/G6/k7LzfnxCed05pLzz2InDTWq/ kpLOp1hwSnGfpllnsSem/hGdnJzStOzsfzZeOiN999KJzFN4/V1LuhC1rCmzjoShsCgTiSRv6fzT iF5fXxojqX8YfziY/uocndH0prOPv3987l72ZoXysps7O+vaJ+m0qCpl8q6zjZf1z4N3nfhouX7t 9Q/vimjcw0d6YUREQ1wLk9KkR38IJ+uI9q6VBiSEI5sh0m8x/lylo3FItxdRygS7O0Btx1jA7B7G dLc/s+6BlKHK2Rz567uDiK7lvWuEmzP7ox72949f2Y+vL/rH/f5PoqEW0ntlbK6biC5A5LvSWpTq RbjF70+gkRQRXeH6K2JLA36XvWiXPrdyLl1YQefCsxhT3imck+Zeunxxi+W67dFUuqr2TkTb/PZY GBZoZLVK5jSpZKIylQivrKEbYfJG5BLkx6PJzd0BBAQrYlpvBAs2iM/Ozt4Q4nRwCiHWsI7lQ+GZ w7/4cVEAKgCGgjPqyx7I+Jed/PduG+0VKuFtYjVdPXsoBsgLs8Kc3Q9LrMgcLR16eLgNbRAPjhma FiYppI+gGKwVhBC6y13wefR0TMM05aIHE3Fc3rYT3rBySnO+0zfyDU4GyHcr3GPDYoyQboLEqP43 1kXUL83DQolPTkqDNjjH9a1o2CBfdnui1e02GRXS1daAxaUC4lKZRTltRtfazjaLvF3GcaNXLAEW rdfkTe2ZzxulHZwcMZ8L6z3nhN8YyE2PvsvcpmKlJbVafljXcheZkByRwViYZYe9Ub3j+IyNdSkT J161unaopVWtuCOpkatttGFRijSi/3bLeKXVizWppaErpcmtXo2eKXpJPMhAaiwfG+Uklvhgum0d fSFRQczLrNGocONTOwtF4Nk5AX/2a6sz04gWttkOBObxGvNhVUmTqmfAohDrwppM5Y1br+cUyZP1 /5eJVU3CpY1tah7jsvbiXqu6CPxKoYzHZ1ObSjivkkYLp+eEQDgneBTWNCssKgppn1SCY6IQT5IE uZUwa7oktqy0fA4DledNxfNGybrHUIHJSJkytlLkBt7Ej/t5UDDc8LYNs9guAaTCWWRdSQlGRy4D GSDErDJNiQlYL/mGCe74frQGRz4LxvORRJoSJgbw4iCgBDa3pXTv6rC3bovE1Te2MTj6sHamfIFh NWtD3e0vd90dwN44HmSmnoEIRwWCRFTaVGXzEHDJOkifZTLxS/xtMOyZ4oRCc9KVycE0HG/I36TK /8aHMPIaJ1mleRD/VWqMwtqz/lxUnG3OwlgYvRsYFpa2nofFZl/BOwgrQmhMIMKgQCs7xt2KuuGs j23eGLW8sQkafYkzFHo5ozf3kA4rhw2Ghi3ZjZM5MJdbXfktlBMqDyff+MQNFIQvUBwN/djZzE/C owt8bJqFSOtHlDK/2tVYcrcvchzhOXihZoszHisWjzURSZ9sCtLfYLYU8OOqnKmsVW6CUSkLDyUs 7nuYpRRGVegdL7eYcSzhvVP3Ib+oa5twldLgsFWxa9JSuBC9wB95uLVGbenS0EoSHbly2bzClNfo Fq3gbpiLxcm1vRc8Zgb9AGeEnJpZk9C99UH4XKGPa56tMtQgPorCU97mdPox4ieE+ISf5a6mnb/w /h/WHBJYZW5kc3RyZWFtCmVuZG9iago4OCAwIG9iagoxMjkxCmVuZG9iago5MiAwIG9iago8PC9M ZW5ndGggOTMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxtVsFS5DYQvc9X9A2o GggDqUCSEwu7KVKprdlhwh5CDrIt2wq2ZCR5hvn7vJYlY8MOBzxj+XX36/e6/ULnZys657/4P28X P22uqHKLc6oWL4tVuEnxX97Spy0OXNPqgrblYnhmRReXdHV1Tdt2cXyvvbRa+tM7K0pP4fO3k3Qr nHRUGktCUzhUilySN/TpjzWNnz97LenifPXzyfa/xeWvtP1rcRxv5UaXquqt8MpoMiWJ8Kg1PcCW lPWehJUkuq5RsiCcEdRJe4pDJ0eL1eUUS0tV1RmSyYRTjp6ODRAqQHUMzLDphHs6+R0pF0tgXPyS MC7PaHaKUJxDWu43srI1XtLNw9dlur5fkygKiyPLdPEho1K0CnnjBON2plE5vjE/qSBchlpxpBWv p52VpXqlRrXKO84uIUmfn82S3daSXN8CwIsm1feOTT1jk8CJP3QqF01zIF/LWbqNsJV0nl56ob0q Dwz5Ae5B2p1Cg9fW7FQh7ZGb4I/5ZgfELYWyCBNgUZqtlAa932upEVp4TiY3baY0SNgrX3NC8bST PiIhB8bGoXe55LXQVSBNav4BICIzO7kk5cnVpm8KymREiankjRR2CO4OzssWUDm6KQqlq+W7ABAH /+KtYXIj0KRW4OCqqlFpKzkb5Vq07Rm6uNg80D5kUAHcI3ImNdoKJTdNKgwaFh5CTJ2LsPMef69V I7miVhxIGw8giAiazJpgsm5oA/+vrGiHgm7W98GSs+5KB8la3N1JXRh76jqZqxLfgyYP8+IDiejP JFRMOwV0fV5zoKPB/EHc1niTg60R+iOhg+YYqDWWW9q2RoOf3qF/iQU0Y3TKhI6bs1W05zpFup0G iMA3GQznD8yO1IKT58CFcuFay33y6ujNoD4VrTIjbSwpDDg87PfGPqeOoU7xzMkmRYAxwcJsGglt ngWLxqzGX/lQKxQXjZDPUnaM4K3I57jBWiXU09sRQ3QiFMc5Rzb1x/n5wxKZ/8R833jVgYtJrAkH lYJCUqls2GRNLXNACnuIOEqDlTbqJWheVPCiY5Gb/ZSuKPUg2N7VqZxZ4hO0wHboHVPz1j3+Nq9v tPekSuqE9YonIoN4ZcM4ecft+3oj0FvV2xp9Gjws4AGMRRzOetXwqAhImDW2YVcOz6BsN6LIQhZz I39BNo/rrx8aswzUsiAmEgm1KB1uwSLo1Ss/PJPmnD0rX3pUGrYJqsW+G54dxlfXCMxPZvW2d960 MuQSvJUWyftm7EyzQxI5z6/QBXpU1vegdRMdyn1BVXthmZJRE84Ljf3wdPy4+fJ0gsUYHpB0Bw5x rleuRvin483d08kwiqV20LgjKTBS8pjgOG54G+ImVi44ctRr9dLD0rnFaApVLEMmQ5Atbw/Pi3+z TfC1bLqINkQafmZ+RjbGMCKoBVO7Ep43SocJ0FmFL/CrS0MwARyoMGEqD9kwJPc4M70uhOXpRdNl EH0x19oHdwyjdd6P0pqWRwv0bNGCxuTTibcHo5KV3JgMdzmFMKb5zYU7NbVWHhcjoXLoJSo9AjFV 4GBnVAFJau72D97OGB/X4xiZLC4GuYcEsFGTAKeqckmRDXOLrnG9LNo6LtJYYEJi6nKYQXssiEGF s0UXfR32HfB96D7w3vwekZLrOUd+oYWF1tzTJd6q0JaztxdV+vzaKVbjHaZdm0Ebq8tleHOl2eef NYYdra7/BeLn7eIb/v4Hg5O9V2VuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoKMTI4OAplbmRvYmoK OTcgMCBvYmoKPDwvTGVuZ3RoIDk4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic dVZNV+M4ELznV/QNeC8EEhaY2T2Fr33Zx+xm43AaOMi2bAtsKSPJhOyv35KsxHYCycF5kVVdXV3d 0i86H43p3H3DM6kGZ4trys3gnPLBr8HYL1J4JBXdLPHCNxpPaJkNmj1jmlzQ9fU3WlaD45m0XEtu T+80yyz5z5PhdMsMN5QpTUySfyljCSer6ObPOe0+f9WS0+R8/NvJ8nVw8Z2Wj4PjgKAymk0WEbGc S2vcTialqiVQVlpZlaiSEiUzkdeaWaEkCYl4lf99cjQYX2zR1qouUzKiWpUi2wAmJVZbhTf5HgJi Ono7fAHu+ANoDiflq1JtKk9nXXCNdIoOmRgpp7RSpUgEcmdYN7xMVUU1FkZESxWAIIUohXXxTZ0U xCgBqGal+A8IfUqVSnk59LTMirM3rg3eQEIBK+bEPyyXKXZCI4RyjHLNKqdEQtP5rC8eOAtNGWe2 1jyAJGzFYkfJEze0Yto6MTpCYM3xa0gBz6Xesg44nYK5fAthgvjMGGHsQUFRhdNUmES9c02t0G19 u7zA551poWrTVwNFYpSLdy4JRlwr/TY6pOPeQsIy8HEyuQw6lgGhNdOpIS5ZXAqZn23LLkzzx9Ye iJyIDNoGEUFN9ii5+JMrb7/paAIl3OLcGWNDt93qhggPokSDdCJoVVvAQj5jtZJ5uSHNE1VVuzrD JFgpXRI9r2/L3Lh052eeiQ9X2kQrY0LmTeOC3Q+F0kDzd5GCfOBUIZPGWQbSesF6aJTtSLeWtx6a p7l7OQA1fguVaWzBkQ0zSjYDogXqc9X891ZHACmi6bsSKT3JNQP7lBZOJpp2Ux5t1WyBbAFeP56i JUlle2I17ePFTunn4uH28vri8mXY/BxfXr18heZ6uwELMKwsVcIcTLyh7Uz0/FxeC57D/RoSjfYz emhHQZNNVKNxdWi0T+LHfKMwwBKuLRNyPx2Wa+6GUFOiipk3KrnMbYF9ds3RIrs6A/uTiG1KBS9X ZuczV5rF7MYPzwc8LVoC0wutf5DSHc+CaSKe1FrYzSdpZBpzMbJ1TEltMIuxNo2CvAdJNWqTWstG YD97wrZOxXdI2yid+gSP+O0K+3VPCD+pmoSZt1gQsBCvLHlDCftJTjHY/Xw0Fnq4oXHaDH+TFByi uwb1U+ST8+URPinDrGuzbFsI+jqtJRd5EaM7cIwa4VplDVy0TXNG2AKuzQuvRHBZSDaMmSjMqCbu I5N5jUFIz8eLaP74fOItPrmaTF5CQy7m0SMOuEw4iVnA+iK9IYHXkYpfeWLNkTsvhMWoLktPjFfD bRWbQ9NjHrRyLGQaJt6s0/VQ7vlY4VKAEJXSHFT/0SLH9J5GQyz5Zt03SKDyfPLHfhQcIiWWvICI FOZqgDn1Vezu/XzXFMeUVJU7eKKNsbxyCMzsbXelG7YYOvT+qqkHYHAROkBCvme+FQSmNUvhNgyx /fR2XphGR9w4FXBwnsq6aqP38r5nuFNMo7/d+YHTaYU0hPOiG7YJLOQSG7qLRWsQZzvcM3hwaY+B o+btEaL5A1d+OeU24DdbLJ5P4Cw8j/wkB+DlxAPOMepwn8E+Vo7aiyDdf6yEO0rvOCZ5jP4cXwz9 zZB6n59zZ+Px9xcg3i8H/+L7P+CAePplbmRzdHJlYW0KZW5kb2JqCjk4IDAgb2JqCjEyMjIKZW5k b2JqCjEwMiAwIG9iago8PC9MZW5ndGggMTAzIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCnicfVZdc9s2EHzXr7g3OzOSY9mZJu2b7GRaddJWldTpQ5zpQOSJQgwCDABKVn599wCSstwP acYySeBwt7e7x690fTWla/l2v0U9er18S1UYXVM1+jqapofU/RQ13a2x4B1Nb2i9HeU9U7q5pbdv 39G6Hl3ObWRvOU7ee7WNlD5/BKZ7FTjQ1nlSltKirSqYoqO7Hxc0fH5uLdPN9fTNq/WX0e33tP44 usTteGx0oYw5kmvYq8glbY605Eo7qwz1h6Y7IXqNox4ul/PlRXh4hQNLUrTlw6uL0fS2D1m6b2zJ KF+xp/lqcRHSQm1Lbhh/bCTnK2X1NxVxSrgiWu+Y5ksEpca7vS4ZASWUogMbM3m07oCIrkgbcq3G nEchFaMqdsgflUeJ16XehcJdz1LAnrGR2qZEsbRcrD6S23zhIoYrrLz5rq/iz502TCFqHHRARkAo lVtEvZeLNmSoBoRW7PcawC9yBT6Mz1CRlBrPe6WNthVt2Gjekg54oGJ6ioQUFc5GpS0LXrmMBIsO XRnaqqJopVFjhNO18hrJlG1quALqxSO5LQFq446Iotq4c74DiWrGVdmFOui4AyahQfE9aIXnvBIx alfqrS6G6zOsiOY9smHnWgMsmKwT/nQFobTC66gLHWqpEw+p1B67Ja04AKJdG8yxi1XyNhWfzgpo Z63CmDZtJJS8A5/+EyvZ0SeU90l3wLcJOuWDFNDBSeEYItcoYWEY4gEGW0TuaYMFM9tjtHRtlHYt nNHFke6d3epK4BdMcBWk05mA3Y5P88n7q7pokGxwdqK9n/gcZNKkIJPibNtn6KVoa1FF4jVg9z39 pXWurXbALRRtCF0jJE3AG53PnASKQfaHKJQ+FXrxgtL3rfdYZ47jM3xJeSZ+KnbKVsJpjgeGgC2y 7zLvEAtnhH64BK57VAkjSGIQPp1Ie0J5bkmVpZZqx+IydhJc66EUNcAM1YPMHJVU1DSmY13IfEyC TWw8viAGkrdccAjYOD4JPehKzEsyUda61hacAH64dH6c8iy9OiiDzIGW2OZCQNzqJ9p6V+NOF2u2 +lXOPlNGDhJZ+RKu1IVAGrrabbDWs8m573TTY9lndoBEyy9wZ+SC0Bcio19ciKTrxvmocm9wWuB/ dKiLIeQBW5L1BF1r2Ow5YmIDbXQ1LrOvb1oNdXad7PEWJsLLx6hGX/HVD2TApySSAQp5WjgvBuFs KSz4zesKDU6Z9wZty9coerb6azFb/yRDYTwYmqUKthi9ssGkwYLUShaPnIjniLeAJJDwUxesz+X+ 4xywbhh6YPzI0U0bdknniIFBouGwLTosE04qE4HjCW+3sJcuWs/drDpymZlw6oPzj8m/xJUKV9fd SHnp5F2cwc/lBMxILK278RE60xAPeX6aTElVeBfE3Vn7LhLaDv/rU5CMFIxM/Hujgn45f8Sd5zfL FelIh95hSw7aq41Jdp8Vm8oyKoj+uenHhtq4PZ/pFRoTpVBwuUOC3ZAt6sNYKzP9X2gMDuPEe4cJ JAhkLWQhyyLU9azTqU+wI1tCJWGC8nCzJ7Oc3tPHc2ZK7u9YxNa0xsi//9PrJJtBEhVbmKkR6SS8 FG5E6axgBmei2WJ+kVpV5RnyvALPX1s0pTyZR9bLHoMVg0nejzjpoj/+rMmNaUN2h+dC6ccQqISN M6jRulqCrZIl0p3zwDvNFqHVw+VsdZdfqA5IDy8dbbEbzuiCWc4CAgeS3E8vCD2dAPaYMD0zErV6 lEwxQQBAJko41fgM1n47m+SRHT9k1xlBonrkTl/YPcynM0FZjLI0Ldw4OWJH8/ReicbiJY52YmYk BoiO6W8D7gd1FKwS9hJCSDeUIPr610ROGhtQymdqkVbhgDPwEELWmAPsnylslt6LwgXNyhKdCwmd 6fWb9HCBPWZM6J8yV6dXaPrw1IArgd5j5tQbtHB6O07v1HT2+bQABXH/M0J+WI9+x/dvBfD8M2Vu ZHN0cmVhbQplbmRvYmoKMTAzIDAgb2JqCjE0NzYKZW5kb2JqCjEwNyAwIG9iago8PC9MZW5ndGgg MTA4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicvVLBctowEL37K96tyQx1LewW 6AkHaGjSZmhwJodOD6pZsBJbJpIcoF/fxZgw7qQ9dnWQvft239ObfULgCwT709xp4b277WFlvQAr 78kTdRHNlRa4SBjQh+giWXqHHoFuiF6vj6Twzj5rR0aTezs2culQx50ljKQli2VpIDVq0FKmBFfi 4nKGl7iqNKEbiOg8efDCAZIv3hmnr2lXGcyko/z8jSfCY36kbFpivrOOCsuVfU70Atz7SKQtmGps 1DM1lTn/X5WWOhjFwOC9CKOmcjeP+av74Th3UkiVf8Qj066ZdJjuefy0LBh1UnVLW3zi10q9KP+n LEPbvyiaSq3Z5ktDi5xMSxM7q9ZkcENuU5rHF1liEOHGx1fpMpUvJOKTrkrr3bPMj8KioD/4t7Cs ph8+HKh8XoOWujnXCTG/31FLW7xe59S2trIW95n6AzgxKrW21K+6wi2boVEbv7Jt2sqyw1NpyLaG TSu5IfXaKJvtwUO9+JU1Fovo0FavYAfkIHP/tLaYbNeKWzCmlIqfbLMIO/UeoxXfZ3LF+y1+8MhJ 4n3j8xuMyeaOZW5kc3RyZWFtCmVuZG9iagoxMDggMCBvYmoKNDI4CmVuZG9iago0IDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSA5IDAgUgovRm9udCAx MCAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagoxMSAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQgMCBSCi9Gb250IDE1IDAgUgo+Pgov Q29udGVudHMgMTIgMCBSCj4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9Gb250IDIwIDAgUgo+PgovQ29udGVudHMg MTcgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUg ODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250IDI1IDAgUgo+PgovQ29udGVudHMgMjIgMCBSCj4+ CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRH U3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUgo+PgovQ29udGVudHMgMjcgMCBSCj4+CmVuZG9iagoz MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMzQg MCBSCi9Gb250IDM1IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozNiAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBS Ci9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMzkgMCBSCi9Gb250 IDQwIDAgUgo+PgovQ29udGVudHMgMzcgMCBSCj4+CmVuZG9iago0MSAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDQgMCBSCi9Gb250IDQ1IDAgUgo+ PgovQ29udGVudHMgNDIgMCBSCj4+CmVuZG9iago0NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDkgMCBSCi9Gb250IDUwIDAgUgo+PgovQ29udGVu dHMgNDcgMCBSCj4+CmVuZG9iago1MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgNTQgMCBSCi9Gb250IDU1IDAgUgo+PgovQ29udGVudHMgNTIgMCBS Cj4+CmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9F eHRHU3RhdGUgNTkgMCBSCi9Gb250IDYwIDAgUgo+PgovQ29udGVudHMgNTcgMCBSCj4+CmVuZG9i ago2MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg NjQgMCBSCi9Gb250IDY1IDAgUgo+PgovQ29udGVudHMgNjIgMCBSCj4+CmVuZG9iago2NiAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNjkgMCBSCi9G b250IDcwIDAgUgo+PgovQ29udGVudHMgNjcgMCBSCj4+CmVuZG9iago3MSAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzQgMCBSCi9Gb250IDc1IDAg Ugo+PgovQ29udGVudHMgNzIgMCBSCj4+CmVuZG9iago3NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNzkgMCBSCi9Gb250IDgwIDAgUgo+PgovQ29u dGVudHMgNzcgMCBSCj4+CmVuZG9iago4MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgODQgMCBSCi9Gb250IDg1IDAgUgo+PgovQ29udGVudHMgODIg MCBSCj4+CmVuZG9iago4NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgODkgMCBSCi9Gb250IDkwIDAgUgo+PgovQ29udGVudHMgODcgMCBSCj4+CmVu ZG9iago5MSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgOTQgMCBSCi9Gb250IDk1IDAgUgo+PgovQ29udGVudHMgOTIgMCBSCj4+CmVuZG9iago5NiAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgOTkgMCBS Ci9Gb250IDEwMCAwIFIKPj4KL0NvbnRlbnRzIDk3IDAgUgo+PgplbmRvYmoKMTAxIDAgb2JqCjw8 L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMDQgMCBSCi9Gb250 IDEwNSAwIFIKPj4KL0NvbnRlbnRzIDEwMiAwIFIKPj4KZW5kb2JqCjEwNiAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTA5IDAgUgovRm9udCAxMTAg MCBSCj4+Ci9Db250ZW50cyAxMDcgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdl cyAvS2lkcyBbCjQgMCBSCjExIDAgUgoxNiAwIFIKMjEgMCBSCjI2IDAgUgozMSAwIFIKMzYgMCBS CjQxIDAgUgo0NiAwIFIKNTEgMCBSCjU2IDAgUgo2MSAwIFIKNjYgMCBSCjcxIDAgUgo3NiAwIFIK ODEgMCBSCjg2IDAgUgo5MSAwIFIKOTYgMCBSCjEwMSAwIFIKMTA2IDAgUgpdIC9Db3VudCAyMQo+ PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgovTWV0YWRhdGEg MTExIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVuZG9i ago5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5k b2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjE1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjE5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjIwIDAgb2JqCjw8L1I4CjggMCBS Pj4KZW5kb2JqCjI0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1I4Cjgg MCBSPj4KZW5kb2JqCjI5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjMwIDAgb2JqCjw8L1I4 CjggMCBSPj4KZW5kb2JqCjM0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjM1IDAgb2JqCjw8 L1I4CjggMCBSPj4KZW5kb2JqCjM5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjQwIDAgb2Jq Cjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjQ1IDAg b2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjQ5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjUw IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2Jq CjU1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjU5IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5k b2JqCjYwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjY0IDAgb2JqCjw8L1I3CjcgMCBSPj4K ZW5kb2JqCjY1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjY5IDAgb2JqCjw8L1I3CjcgMCBS Pj4KZW5kb2JqCjcwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjc0IDAgb2JqCjw8L1I3Cjcg MCBSPj4KZW5kb2JqCjc1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjc5IDAgb2JqCjw8L1I3 CjcgMCBSPj4KZW5kb2JqCjgwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjg0IDAgb2JqCjw8 L1I3CjcgMCBSPj4KZW5kb2JqCjg1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjg5IDAgb2Jq Cjw8L1I3CjcgMCBSPj4KZW5kb2JqCjkwIDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjk0IDAg b2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjk1IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjk5 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEwMCAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9i agoxMDQgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTA1IDAgb2JqCjw8L1I4CjggMCBSPj4K ZW5kb2JqCjEwOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxMTAgMCBvYmoKPDwvUjgKOCAw IFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9Db3VyaWVyL1R5cGUvRm9udAovU3VidHlw ZS9UeXBlMT4+CmVuZG9iagoxMTEgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwv TGVuZ3RoIDEzNTQ+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlI enJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBt ZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0x MywgZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20v aVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOmRjMWMzYTVmLTI5ZTAt MTFlZi0wMDAwLWUwZWNmZmU5MDg2MScgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3Bk Zi8xLjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjA1Jy8+CjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSd1dWlkOmRjMWMzYTVmLTI5ZTAtMTFlZi0wMDAwLWUwZWNmZmU5MDg2 MScgeG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1vZGlmeURh dGU+MjAxNC0wNi0xMVQxNjo1ODo0MC0wNzowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6Q3JlYXRl RGF0ZT4yMDE0LTA2LTExVDE2OjU4OjQwLTA3OjAwPC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVh dG9yVG9vbD5HTlUgRW5zY3JpcHQgMS42LjUuOTA8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNj cmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ZGMxYzNhNWYtMjllMC0x MWVmLTAwMDAtZTBlY2ZmZTkwODYxJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDpkYzFjM2E1Zi0yOWUwLTExZWYtMDAw MC1lMGVjZmZlOTA4NjEnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ZGMxYzNh NWYtMjllMC0xMWVmLTAwMDAtZTBlY2ZmZTkwODYxJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+ PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5FbnNjcmlwdCBPdXRwdXQ8L3Jk ZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8 L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5k PSd3Jz8+CmVuZHN0cmVhbQplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3Jp cHQgOS4wNSkKL0NyZWF0aW9uRGF0ZShEOjIwMTQwNjExMTY1ODQwLTA3JzAwJykKL01vZERhdGUo RDoyMDE0MDYxMTE2NTg0MC0wNycwMCcpCi9UaXRsZShFbnNjcmlwdCBPdXRwdXQpCi9DcmVhdG9y KEdOVSBFbnNjcmlwdCAxLjYuNS45MCk+PmVuZG9iagp4cmVmCjAgMTEyCjAwMDAwMDAwMDAgNjU1 MzUgZiAKMDAwMDAzMTAxNyAwMDAwMCBuIAowMDAwMDMzODgyIDAwMDAwIG4gCjAwMDAwMzA4MTUg MDAwMDAgbiAKMDAwMDAyNzQwNyAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDEx NjUgMDAwMDAgbiAKMDAwMDAzMTA4MyAwMDAwMCBuIAowMDAwMDMyMzg4IDAwMDAwIG4gCjAwMDAw MzExMjQgMDAwMDAgbiAKMDAwMDAzMTE1MyAwMDAwMCBuIAowMDAwMDI3NTY2IDAwMDAwIG4gCjAw MDAwMDExODUgMDAwMDAgbiAKMDAwMDAwMjQ0NSAwMDAwMCBuIAowMDAwMDMxMTgzIDAwMDAwIG4g CjAwMDAwMzEyMTMgMDAwMDAgbiAKMDAwMDAyNzcyOCAwMDAwMCBuIAowMDAwMDAyNDY2IDAwMDAw IG4gCjAwMDAwMDM3MzggMDAwMDAgbiAKMDAwMDAzMTI0MyAwMDAwMCBuIAowMDAwMDMxMjczIDAw MDAwIG4gCjAwMDAwMjc4OTAgMDAwMDAgbiAKMDAwMDAwMzc1OSAwMDAwMCBuIAowMDAwMDA1MDI0 IDAwMDAwIG4gCjAwMDAwMzEzMDMgMDAwMDAgbiAKMDAwMDAzMTMzMyAwMDAwMCBuIAowMDAwMDI4 MDUyIDAwMDAwIG4gCjAwMDAwMDUwNDUgMDAwMDAgbiAKMDAwMDAwNjI5MiAwMDAwMCBuIAowMDAw MDMxMzYzIDAwMDAwIG4gCjAwMDAwMzEzOTMgMDAwMDAgbiAKMDAwMDAyODIxNCAwMDAwMCBuIAow MDAwMDA2MzEzIDAwMDAwIG4gCjAwMDAwMDc3MTkgMDAwMDAgbiAKMDAwMDAzMTQyMyAwMDAwMCBu IAowMDAwMDMxNDUzIDAwMDAwIG4gCjAwMDAwMjgzNzYgMDAwMDAgbiAKMDAwMDAwNzc0MCAwMDAw MCBuIAowMDAwMDA5MTM0IDAwMDAwIG4gCjAwMDAwMzE0ODMgMDAwMDAgbiAKMDAwMDAzMTUxMyAw MDAwMCBuIAowMDAwMDI4NTM4IDAwMDAwIG4gCjAwMDAwMDkxNTUgMDAwMDAgbiAKMDAwMDAxMDQ2 MyAwMDAwMCBuIAowMDAwMDMxNTQzIDAwMDAwIG4gCjAwMDAwMzE1NzMgMDAwMDAgbiAKMDAwMDAy ODcwMCAwMDAwMCBuIAowMDAwMDEwNDg0IDAwMDAwIG4gCjAwMDAwMTE3MjIgMDAwMDAgbiAKMDAw MDAzMTYwMyAwMDAwMCBuIAowMDAwMDMxNjMzIDAwMDAwIG4gCjAwMDAwMjg4NjIgMDAwMDAgbiAK MDAwMDAxMTc0MyAwMDAwMCBuIAowMDAwMDEzMTM2IDAwMDAwIG4gCjAwMDAwMzE2NjMgMDAwMDAg biAKMDAwMDAzMTY5MyAwMDAwMCBuIAowMDAwMDI5MDI0IDAwMDAwIG4gCjAwMDAwMTMxNTcgMDAw MDAgbiAKMDAwMDAxNDYxNCAwMDAwMCBuIAowMDAwMDMxNzIzIDAwMDAwIG4gCjAwMDAwMzE3NTMg MDAwMDAgbiAKMDAwMDAyOTE4NiAwMDAwMCBuIAowMDAwMDE0NjM1IDAwMDAwIG4gCjAwMDAwMTYx MjEgMDAwMDAgbiAKMDAwMDAzMTc4MyAwMDAwMCBuIAowMDAwMDMxODEzIDAwMDAwIG4gCjAwMDAw MjkzNDggMDAwMDAgbiAKMDAwMDAxNjE0MiAwMDAwMCBuIAowMDAwMDE3NDA3IDAwMDAwIG4gCjAw MDAwMzE4NDMgMDAwMDAgbiAKMDAwMDAzMTg3MyAwMDAwMCBuIAowMDAwMDI5NTEwIDAwMDAwIG4g CjAwMDAwMTc0MjggMDAwMDAgbiAKMDAwMDAxODc0OCAwMDAwMCBuIAowMDAwMDMxOTAzIDAwMDAw IG4gCjAwMDAwMzE5MzMgMDAwMDAgbiAKMDAwMDAyOTY3MiAwMDAwMCBuIAowMDAwMDE4NzY5IDAw MDAwIG4gCjAwMDAwMjAwODkgMDAwMDAgbiAKMDAwMDAzMTk2MyAwMDAwMCBuIAowMDAwMDMxOTkz IDAwMDAwIG4gCjAwMDAwMjk4MzQgMDAwMDAgbiAKMDAwMDAyMDExMCAwMDAwMCBuIAowMDAwMDIx MjExIDAwMDAwIG4gCjAwMDAwMzIwMjMgMDAwMDAgbiAKMDAwMDAzMjA1MyAwMDAwMCBuIAowMDAw MDI5OTk2IDAwMDAwIG4gCjAwMDAwMjEyMzIgMDAwMDAgbiAKMDAwMDAyMjU5NSAwMDAwMCBuIAow MDAwMDMyMDgzIDAwMDAwIG4gCjAwMDAwMzIxMTMgMDAwMDAgbiAKMDAwMDAzMDE1OCAwMDAwMCBu IAowMDAwMDIyNjE2IDAwMDAwIG4gCjAwMDAwMjM5NzYgMDAwMDAgbiAKMDAwMDAzMjE0MyAwMDAw MCBuIAowMDAwMDMyMTczIDAwMDAwIG4gCjAwMDAwMzAzMjAgMDAwMDAgbiAKMDAwMDAyMzk5NyAw MDAwMCBuIAowMDAwMDI1MjkxIDAwMDAwIG4gCjAwMDAwMzIyMDMgMDAwMDAgbiAKMDAwMDAzMjIz MyAwMDAwMCBuIAowMDAwMDMwNDgzIDAwMDAwIG4gCjAwMDAwMjUzMTIgMDAwMDAgbiAKMDAwMDAy Njg2MiAwMDAwMCBuIAowMDAwMDMyMjY0IDAwMDAwIG4gCjAwMDAwMzIyOTUgMDAwMDAgbiAKMDAw MDAzMDY0OSAwMDAwMCBuIAowMDAwMDI2ODg0IDAwMDAwIG4gCjAwMDAwMjczODYgMDAwMDAgbiAK MDAwMDAzMjMyNiAwMDAwMCBuIAowMDAwMDMyMzU3IDAwMDAwIG4gCjAwMDAwMzI0NTAgMDAwMDAg biAKdHJhaWxlcgo8PCAvU2l6ZSAxMTIgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFs8QzA2 RjMwMDU0NTA2MUY3N0EyREI3OTdBRjQ2ODU4REQ+PEMwNkYzMDA1NDUwNjFGNzdBMkRCNzk3QUY0 Njg1OEREPl0KPj4Kc3RhcnR4cmVmCjM0MDYxCiUlRU9GCg== ------=_NextPart_000_00CF_01CF85B9.47813DD0-- From nobody Thu Jun 12 02:15:50 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D46F1B27B0 for ; Thu, 12 Jun 2014 02:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMaUgLAwZepJ for ; Thu, 12 Jun 2014 02:15:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 188AD1A020A for ; Thu, 12 Jun 2014 02:15:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 00E255408D4; Thu, 12 Jun 2014 11:15:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbFbyZERHGw8; Thu, 12 Jun 2014 11:15:38 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DAF9E540647; Thu, 12 Jun 2014 11:15:33 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , Jeffrey Haas In-Reply-To: <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 12 Jun 2014 11:15:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/9C1UO51EGxu17Rs6OK9AIvlXaQc Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:15:48 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: "Jeffrey Haas" ; > Sent: Tuesday, June 10, 2014 7:07 PM >> Tom, >> >> [retaining lots of content for context] > > now elided as it is not so much about references to extracts of the > architecture I-D > >> On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: >> > ---- Original Message ----- >> > From: "Jeffrey Haas" >> > To: "t.petch" >> > Cc: "Jeffrey Haas" ; >> > Sent: Tuesday, June 10, 2014 2:41 PM >> > >> > > Tom, >> > > > >> >> This is much of what I had suggested about the semantics of > introducing >> ephemeral config into netconf. Our requirement is that these things > are >> ephemeral. (Although Tom Nadeau presents some nice cases as to why we > may >> want the equivalent of "write running-config" to permit persistence.) >> >> At this point, overlapping ephemeral configuration isn't something > that >> netconf supports. If you scan mail from the last month or so, you'll > also >> see some back and forth between Juergen and Andy and I about how we go > about >> representing such a thing in the yang model/modules. (And we never > fully >> converged.) >> >> From the config perspective, this ephemeral state wasn't something > that I >> believe was part of the config semantics of netconf/yang; it's an I2RS >> requirement. Admittedly, once we have such a think then clearly >> applications other than I2RS can make use of it. :-) >> >> Choosing a solution space will be the next challenge we have: >> - Overlapping modules with i2rs context? >> - Parallel modules? >> - How to ensure maximum re-use of the yang modules for config in an > i2rs >> context if they are determined to have heavy overlap? > > Jeff > > Yes, I saw the thread - I think I started it and ended it! > > Leaving aside the question of just what objects I2RS wants to edit that > NETCONF cannot (perhaps none:-), the rest of that thread seems clear to > me. > > The architecture I-D talks of data store which I think unclear; I think > that it should be datastore, as used in Ops Area (e.g. by NETCONF). > > The view that has evolved, and is reflected in the thread, is that > NETCONF 'config true' is not really the configuration. The real > configuration is the operational state, part learnt from protocols and > hardware and part derived from 'config true'; but 'config true' is only > what the operator would like to happen, the operational state is the > reality. Yes, although platforms that control all channels through which the operator can interact with the box often try to pretend that config and operational state are the same. It is reflected somewhat in the design of YANG where operational state data (config false) may be embedded within the configuration tree. > > Currently we only have 'config true' written by NETCONF in a > configuration datastore (with operational state not being part of any > datastore, just part of state, using that term in the Ops Area sense). > What I2RS then adds is an I2RS datastore, may be one, may be several, > which is another expression of hope as to what the box will do; > operational state, as ever, tells us what actually happens. The rules > of persistence for I2RS are whatever I2RS wants them to be with no > impact on NETCONF. Agreed. > > So I suggest that it is wrong, as I and others have said in the past, to > talk of editing operational state; the writing of the basic NETMOD > models have shown that that does not work. The model that has evolved > is what I call twin trees, one of 'config true' - an aspiration of the > operator - and the other of 'config false' - operational state, the > reality. You can see signs of this in the NETMOD models of > interfaces-cfg, routing-cfg, system-cfg and so on. Yes, and I plan to propose that the relationship of such twin trees be formally stated in YANG models - currently it is only explained in descriptions. > > I2RS then adds a third tree to the model, of what it would like the box > to do. I2RS would also need to specify how to resolve conflicts between > NETCONF and I2RS should they specify different values for the same > object. This is already an issue, IMO not fully resolved, when the user > and the system have different views of what should happen - look for > user-controlled and system-controlled in interfaces-cfg. It is necessary to think about some arbitration rules that prevent NETCONF and I2RS (or other means for changing operational state) to stomp on each other's toes. I don't think though this has anything to do with user/system-controlled interfaces. > > So one module, three trees, an additional YANG substatement for a leaf > that is writable by I2RS. Rather than inventing new annotations, I'd rather like to see making YANG less NETCONF-specific so that it could directly define schema and constraints for other datastores such as the one for I2RS. Lada > > Tom Petch > > >> > 6.4.2" o writing policy information such as interface attributes > that >> > are >> > specific to the routing protocol or BGP policy that may > indirectly >> > manipulate attributes of routes carried in BGP. >> > >> > o writing routes or prefixes to be advertised via the protocol" >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but > the >> > I-D goes on to say >> > " direct modification of the link-state database MUST NOT be > allowed" >> > (which I have seen on the list w.r.t. the BGP RIB). >> > >> > or >> > >> > 8" The interaction of state installed via the I2RS and via a > router's >> > configuration needs to be clearly defined." >> > which again implies that I2RS and C/N/S are writing to the same > data. >> >> *Maybe.* >> >> In some cases, the overlap with config state will be quite obvious and > your >> observation will strongly hold. >> >> In other cases, I think a better perspective is that I2RS injected > state is >> effectively like that of another routing protocol. >> >> If you'd like to argue that BGP is effectively the same as C/N/S... > well, if >> we're talking Flowspec I might agree. :-) >> >> > The examples of data that can be changed are few, such as >> > "For example, the interaction with OSPF might include modifying the >> > local routing element's link metrics, announcing a > locally-attached >> > prefix, .." >> > which leaves me wondering, do you expect an OSPF YANG model to be > unable >> > to change a link metric:-) >> >> Sure. In a highly dynamic fashion? With a fallback to a default > config when >> the application is done? >> >> By comparison to some vendor specific features, it's somewhat the > difference >> between a policy database (config) and the dynamic policy API that > doesn't >> require a system reconfiguration event. If you want to point out that > the >> relationship is strong and that the defining differences are shallow - > you >> could very well be right in those contexts. >> >> Again, we don't expect I2RS work to supplant netconf/yang. We expect > to >> leverage the work. >> >> > If I2RS were aiming at a higher level, say specifying policy and > have >> > the system translate that into actual config changes I would > understand >> > that, but I do not see I2RS going that far, rather when I2RS says >> > policy, I think it means changing a community (config again) or some >> > such ie more of an implementation detail than a high level strategy. >> >> I hesitate to frame it this way, but one example application is a form > of >> SDN. The front end says "provision this VPN" to a data model for that >> purpose. The fact that it may go behind the covers via client->agent > and >> eventually install ephemeral netconf state is an implementation > detail. >> >> If you want to argue that such a higher level model is simply netconf, > then >> perhaps we should de-charter and do all of the work in that group. I > was, >> however, under the impression that work for various models was being > pushed >> to be done in appropriate working groups. :-) >> >> -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 12 06:26:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DA41B2A19 for ; Thu, 12 Jun 2014 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afWjqMFRwWQF for ; Thu, 12 Jun 2014 06:26:50 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7996A1B2A18 for ; Thu, 12 Jun 2014 06:26:50 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,465,1400040000"; d="scan'208";a="350480156" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Jun 2014 09:26:20 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 12 Jun 2014 09:26:49 -0400 From: "George, Wes" To: Jeffrey Haas Date: Thu, 12 Jun 2014 09:26:47 -0400 Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: Ac+GQfayDxIbWxLjQTGU+IMxd3K2Hw== Message-ID: References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> <20140610201427.GF32305@pfrc> In-Reply-To: <20140610201427.GF32305@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/JRCQG9WLRm3gj3_DtV4YStTy10E Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 13:26:51 -0000 DQpPbiA2LzEwLzE0LCA0OjE0IFBNLCAiSmVmZnJleSBIYWFzIiA8amhhYXNAcGZyYy5vcmc+IHdy b3RlOg0KDQo+VGhlIHRyYWNlYWJpbGl0eSBkcmFmdCBzaG91bGQgaG9wZWZ1bGx5IGdpdmUgeW91 IHRoZSAid2hhdCB3YXMgcmVxdWVzdGVkIg0KPmVuZCBvZiB0aGUgYXVkaXRpbmcgc3BlY3RydW0u ICAoUGxlYXNlIGNvbW1lbnQgaW4gdGhhdCB0aHJlYWQsIGlmDQo+b3RoZXJ3aXNlLikNCg0KSeKA mWxsIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQsIGF0IHRoZSBsYXRlc3Qgd2hlbiB0aGUgYWRvcHRp b24gY2FsbCBoaXRzLA0KYW5kIG1ha2UgY29tbWVudHMgd2l0aCB0aGlzIGluIG1pbmQuDQoNCj4N Cj5XaGF0IEkgYmVsaWV2ZSB5b3UncmUgYXNraW5nIGlzIHJvdWdobHkgc29tZXRoaW5nIGxpa2Ug dGhlIGZvbGxvd2luZyB0ZXh0DQo+aW4NCj50aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Og0KPg0KPlgu IE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zDQo+DQo+SW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0 cm91Ymxlc2hvb3Rpbmcgb2Ygcm91dGluZyBlbGVtZW50cyBpbXBsZW1lbnRpbmcNCj5JMlJTDQo+ YWdlbnRzLCB0aG9zZSByb3V0aW5nIGVsZW1lbnRzIHNob3VsZCBwcm92aWRlIGZvciBhIG1lY2hh bmlzbSB0byBzaG93DQo+YWN0aXZlbHkgcHJvdmlzaW9uZWQgSTJSUyBzdGF0ZS4gIE5vdGUgdGhh dCB0aGlzIGluZm9ybWF0aW9uIG1heSBjb250YWluDQo+aGlnaGx5IHNlbnNpdGl2ZSBtYXRlcmlh bCBzdWJqZWN0IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiBhbnkNCj5kYXRhDQo+ bW9kZWxzIGltcGxlbWVudGVkIGJ5IHRoYXQgQWdlbnQgYW5kIHRodXMgbXVzdCBiZSBwcm90ZWN0 ZWQgYWNjb3JkaW5nIHRvDQo+dGhvc2UgY29uc2lkZXJhdGlvbnMuDQoNClllcywgSSB0aGluayB0 aGUgb25seSB0aGluZyB0aGF0IG1pc3NlcyBpcyB0aGUgbmVlZCBmb3IgaXQgdG8gYmUNCmluZGVw ZW5kZW50IG9mIHRoZSBhZ2VudCBpdHNlbGYuDQoNCldlcw0KDQoNClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Thu Jun 12 15:26:08 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E41A028A for ; Thu, 12 Jun 2014 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.645 X-Spam-Level: *** X-Spam-Status: No, score=3.645 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPFXqLdIRf5W for ; Thu, 12 Jun 2014 15:26:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C46AF1A0271 for ; Thu, 12 Jun 2014 15:26:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: Date: Thu, 12 Jun 2014 18:26:01 -0400 Message-ID: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+GjQkiVWQpH0dxQVWc/MElqtTQqg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/m4l1gr41_0hAHeIwLw9jTzNZ1Oc Cc: 'Jeffrey Haas' , Edward Crabbe Subject: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:26:06 -0000 I've posted a version of white-i2rs-use-case-05 with the recommendations = at the front of the document. I look forward to additional comments. I = appreciate Tom Petch and Dean B.'s comments on these drafts.=20 URL: = http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt Sue Hares From nobody Thu Jun 12 16:37:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6474E1A018F for ; Thu, 12 Jun 2014 16:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh5Wsjv0frMp for ; Thu, 12 Jun 2014 16:37:13 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87091A02EC for ; Thu, 12 Jun 2014 16:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1402616233; x=1403825833; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=uMOUwJ+y3SVzgpEz8thnKZMC4smOwOIkOU5G0GU0Bfs=; b=C7YkvG5EJpDNLLmy3IaL8mqjDBMrJhaE1uGV8z6hIkEOykLgN/NetaEr 1TQoRqUkFrBqiOcTNLayaduYLpPd46aMiW1GKd3Gxwyx8x+FAKNq7pmtQ xlmtbf7ALaYCdfaWXmSMoTQlkNteChjCBAfuD5A+ZF8NBiZAD0LzbG6JJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUGACs5mlOtJV2Z/2dsb2JhbABagw2qfwYFAZkeAYEHFnWEAwEBAQMBOEABEAsOBAYJFg8JAwIBAgE3DgYNAQcBAYg2CNJJF4VciH8HhEEBA5oyk1OBfIFcIQ X-IronPort-AV: E=Sophos;i="5.01,468,1400025600"; d="scan'208";a="52663787" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 12 Jun 2014 23:37:11 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (rtp-jclarke-8915.cisco.com [10.117.46.166]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5CNbAQg002310; Thu, 12 Jun 2014 23:37:11 GMT Message-ID: <539A39A6.2090701@cisco.com> Date: Thu, 12 Jun 2014 19:37:10 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20140605202938.GP13606@pfrc> <539233C5.2070700@cisco.com> <20140610174157.GG20397@pfrc> In-Reply-To: <20140610174157.GG20397@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/t6PHwNw045l3jJddzLZh04Pyoxc Cc: i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:37:14 -0000 On 6/10/14, 1:41 PM, Jeffrey Haas wrote: > Joe, > > Thanks for re-sending the comments. A few clarifying points: > > On Fri, Jun 06, 2014 at 05:33:57PM -0400, Joe Marcus Clarke wrote: > [...] >> Section 7.1. This is mainly an editorial, but in looking back at >> things like NETCONF over BEEP, one goal might be to make sure the >> transport chosen is both operator and implementor friendly in terms >> of ease of adoption. > > I think we're leaving this broadly open because "easy to implement" will > vary depending on your environment. PHP webserver based environments may > prefer BEEP environments if you have the right tool chain, as an example. > I'd probably prefer to just do it in SSH if I were writing it. > > But I think we're all generally aware that the client environment and > ecosystem and the agent environment and ecosystems may be wildly different. > Clients will be highly variable since they're user applications. Agents in > many cases will have to co-exist with routing applications that have > (near) real-time constraints. This disparity of environments will likely > lead to some constraints on what a given vendor may care to deploy. > > Given the above, do you still think 7.1 needs additional clarification? Yeah, this makes sense. > >> Section 7.5. Would a supervisory application work in this case? > > This seems like an implementation detail - and potentially a common one. > However, I'm not sure if it's one we'd want to mandate in the architecture. Maybe, but I worry about Client A and Client B not being able to write to each others state. If Client B is a supervisory app, wouldn't it need to act as Client A? > >> I >> suppose it could if it shared the same ID, but that wouldn't work >> for multiple applications. Likely a better approach would be to >> allow the Client to accept some meta-instructions at the beginning >> of a session as to what to do if the app goes away (as you state in >> paragraph 4). > > I believe such details will hopefully fall-out very early on in the gap > analysis work that is ahead of us. Perhaps even something like "Graceful > restart" type semantics, if appropriate. That could be. Joe > > -- Jeff > From nobody Thu Jun 12 17:07:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286DB1A0328 for ; Thu, 12 Jun 2014 17:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agmNr5OpxT9D for ; Thu, 12 Jun 2014 17:07:03 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEFC1A030C for ; Thu, 12 Jun 2014 17:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C51FE480EC7; Thu, 12 Jun 2014 17:07:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-230.clppva.east.verizon.net [70.106.134.230]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 5CBF2480EC6; Thu, 12 Jun 2014 17:06:54 -0700 (PDT) Message-ID: <539A4098.40507@joelhalpern.com> Date: Thu, 12 Jun 2014 20:06:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joe Marcus Clarke , Jeffrey Haas References: <20140605202938.GP13606@pfrc> <539233C5.2070700@cisco.com> <20140610174157.GG20397@pfrc> <539A39A6.2090701@cisco.com> In-Reply-To: <539A39A6.2090701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/UQcQn_lrQEoC3v4UrpkKZDaftoc Cc: i2rs@ietf.org Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 00:07:04 -0000 With regard to the question below, I think that there are some corner cases regarding authorization sharing that we will probably need to discuss. I am concerned that trying to solve the corner cases for non-transparent failover (either to a replacement or to a parent) are going to be tricky to get right. I think that the basic architecture we have is probably a good starting point. For example, it asserts that in normal operation there is no such thing as a supervising client (B) with rights to over-write state created by regular client. I think that introducing such a notion explicitly would create a lot of complexity. Note that by using the priority mechanism, such over-riding can be done, but it will be considered an indication of an exceptional error condition. Which it seems it is. I think generally having one client guess what another client was trying to accomplish with a change (supervision) is simply ripe for trouble. Yours, Joel On 6/12/14, 7:37 PM, Joe Marcus Clarke wrote: >> >>> Section 7.5. Would a supervisory application work in this case? >> >> This seems like an implementation detail - and potentially a common one. >> However, I'm not sure if it's one we'd want to mandate in the >> architecture. > > Maybe, but I worry about Client A and Client B not being able to write > to each others state. If Client B is a supervisory app, wouldn't it > need to act as Client A? From nobody Fri Jun 13 04:16:33 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3F61B28ED for ; Fri, 13 Jun 2014 04:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtsEQtNHjyLN for ; Fri, 13 Jun 2014 04:16:30 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED351A0463 for ; Fri, 13 Jun 2014 04:16:30 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:50616 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WvPT8-0005HP-1C; Fri, 13 Jun 2014 11:16:26 +0000 From: "Russ White" To: "'Jeffrey Haas'" , "'Sriganesh Kini'" References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> <20140610183506.GK20397@pfrc> In-Reply-To: <20140610183506.GK20397@pfrc> Date: Fri, 13 Jun 2014 07:16:14 -0400 Message-ID: <022e01cf86f8$e4b2fae0$ae18f0a0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG4HiDPtHApGS/RkuDb2q9DCu0dLQI79+IyAmU5lsgCG/Jf4wHkY+iwAhp/wdECAtcsggI99xW/Aamb1lECCaUpwQDpXLz5mwDpDtA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uCyc6tSgT295N1LqTF75R-60YJc Cc: i2rs@ietf.org, edc@google.com, 'Dean Bogdanovic' , "'t.petch'" Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:16:31 -0000 > As mentioned elsewhere, I tend to perceive I2RS's impact on the network as > being similar to that of a routing protocol. If I want something I do to a given > device to propagate, the state that is injected must either be suitable for > injection into another routing protocol (redistribute into BGP, or IGP, e.g.) or > must be fully local. > > We will have cases for both. > > For Sri's point, if I inject state in to router A and it overlaps with state in > router B, it better be because that state had arrived via a routing protocol. In > such a case, the interaction between I2RS and the protocol would already be > defined. This is the correct way to see this problem -- we don't want to inject complex and fancy "stuff" into I2RS to handle every conceivable overlap/conflict/etc. We are injecting routing information into a local RIB which is then distributed through normal routing -- there are already rules in place to handle overlapping information coming from two different routing protocols on every platform that runs more than one routing protocol. Devices from different vendors running multiple routing processes already interoperate on today's networks. Let's not invent new solutions to a problem that has already been solved with real deployed code. :-) Russ From nobody Fri Jun 13 04:54:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6FA1B2901 for ; Fri, 13 Jun 2014 04:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqReHAqMxyEK for ; Fri, 13 Jun 2014 04:54:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBB71B2902 for ; Fri, 13 Jun 2014 04:54:08 -0700 (PDT) Received: from DBXPRD0210HT002.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 13 Jun 2014 11:54:05 +0000 Message-ID: <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> Date: Fri, 13 Jun 2014 12:49:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AMSPR07CA001.eurprd07.prod.outlook.com (10.242.77.169) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0241D5F98C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(54094003)(51404002)(13464003)(51414003)(189002)(199002)(377454003)(51704005)(23756003)(15202345003)(86362001)(105586001)(93916002)(92566001)(89996001)(62966002)(76482001)(4396001)(14496001)(64706001)(50226001)(44716002)(62236002)(74662001)(20776003)(42186004)(74502001)(47776003)(99396002)(83322001)(19580405001)(101416001)(61296002)(19580395003)(77982001)(80022001)(92726001)(66066001)(76176999)(79102001)(50466002)(15975445006)(104166001)(81686999)(88136002)(81816999)(31966008)(44736004)(87976001)(46102001)(77156001)(87286001)(83072002)(21056001)(84392001)(50986999)(81342001)(81542001)(102836001)(85852003)(33646001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0210HT002.eurprd02.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/F0Ys-_C-Qy0pJxwLCsqe3XJEbPw Cc: 'Jeffrey Haas' , Edward Crabbe Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:54:11 -0000 ---- Original Message ----- From: "Susan Hares" To: Cc: "'Jeffrey Haas'" ; "Edward Crabbe" Sent: Thursday, June 12, 2014 11:26 PM > I've posted a version of white-i2rs-use-case-05 with the recommendations at the front of the document. I look forward to additional comments. I appreciate Tom Petch and Dean B.'s comments on these drafts. Sue I am flattered; I am not sure that I deserve such mention. I am more interested in the use cases part of the I-D, seeing requirements and info-model as the next stage when use cases are agreed, and they look fine (perhaps /may Data Centers/many Data Centers/). I note the reference to ISIS which I find significant. My experience is more of OSPF but appreciate that that is rare with Operators. However, both are Link State and so very different to BGP which makes me think about the use of RIB. The NETMOD routing-cfg started with RIBs, dropped them and then reinstated them (after consulting with I2RS), whereas for me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is very different in detail (as much research as Lada has done across three differing platforms, I am not certain that the NETMOD has sufficient routing expertise to get this perfect:-(. I think you need a definition of RIB, perhaps by a Normative reference to rib-info-model, but for me that leaves unclear the relationship between routing instance, routing protocol and RIB, at least when you get into requirements. Likewise, this I-D is cast in terms of a table identifier and a route process identifier, whereas routing-cfg has routing-instance [name] with router-id, ribs, interfaces, routing-protocols etc I have a sense of two divergent models of what a router is for all the discussions. REQ1 last sentence should probably include removing process REQ2 I think is about source-based routing but it does not quite say that, rather reading as if source or destination routing were equally valid options REQ3 again the wording seems odd - I think you mean that traffic with a given destination (or source?) prefix should be discarded, but that is not what it says REQ4 I find vague, as I do anything with the word policy in it:-( Something concrete (communities, MED, ...) would help REQ6 makes me wonder what is a RIB when it is not local REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something more concrete. Again, I wonder if it is technically possible to present information in a consistent manner given the difference in underlying concepts of protocols. REQ9 - again all embracing and as such, probably impossible, at least as written. Limiting it just to BGP and a link-state protocol, again that seems challenging. REQ10 - policies again, and it is unclear who is doing the time management. Some configuration protocols do have timer-based facilities, but not NETCONF; do you mean here that I2RS must have functionality based on timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and Japan?) Tom Petch > > URL: http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > > Sue Hares > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 13 05:11:52 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754571B2908 for ; Fri, 13 Jun 2014 05:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvCLaCL-0BRJ for ; Fri, 13 Jun 2014 05:11:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFC211B2900 for ; Fri, 13 Jun 2014 05:11:39 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id DB2CC1403D3; Fri, 13 Jun 2014 14:11:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1402661496; bh=yWvWTrzk4eioQUFQ7qi6OcL3udhfKN1mStWmymxCF+M=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qmrxLpvTHzKdPAbuhGluXXwozTOBx4wpuqlESF5dqKZFMqGH5++NgEXP6+G9Rs8w0 O17gxMBITdmVHPrWfAx/YXRxLnKkbnsgZPlKIea7aDaO7TO9hU86pSYVVwZpBvxBJA FjuLd/AdvhZrbsiVDs3x8bTm4Xp0yctJJQmF7Z0M= Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> Date: Fri, 13 Jun 2014 14:11:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/b2A7fsBKtaSQqerwEVebpVxa33Q Cc: Jeffrey Haas , i2rs@ietf.org, Edward Crabbe , Susan Hares Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 12:11:47 -0000 On 13 Jun 2014, at 13:49, t.petch wrote: > ---- Original Message ----- > From: "Susan Hares" > To: > Cc: "'Jeffrey Haas'" ; "Edward Crabbe" > Sent: Thursday, June 12, 2014 11:26 PM > >> I've posted a version of white-i2rs-use-case-05 with the > recommendations at the front of the document. I look forward to > additional comments. I appreciate Tom Petch and Dean B.'s comments on > these drafts. > > Sue > > I am flattered; I am not sure that I deserve such mention. > > I am more interested in the use cases part of the I-D, seeing > requirements and info-model as the next stage when use cases are agreed, > and they look fine (perhaps /may Data Centers/many Data Centers/). > > I note the reference to ISIS which I find significant. My experience is > more of OSPF but appreciate that that is rare with Operators. However, > both are Link State and so very different to BGP which makes me think > about the use of RIB. The NETMOD routing-cfg started with RIBs, dropped > them and then reinstated them (after consulting with I2RS), whereas for > me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in > LSDB, which is very different in detail (as much research as Lada has > done across three differing platforms, I am not certain that the NETMOD > has sufficient routing expertise to get this perfect:-(. > > I think you need a definition of RIB, perhaps by a Normative reference > to rib-info-model, but for me that leaves unclear the relationship > between routing instance, routing protocol and RIB, at least when you > get into requirements. Sounds like recurring deja vu: - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html Lada > > Likewise, this I-D is cast in terms of a table identifier and a route > process identifier, whereas routing-cfg has routing-instance [name] > with router-id, ribs, interfaces, routing-protocols etc I have a sense > of two divergent models of what a router is for all the discussions. > > REQ1 last sentence should probably include removing process > > REQ2 I think is about source-based routing but it does not quite say > that, rather reading as if source or destination routing were equally > valid options > > REQ3 again the wording seems odd - I think you mean that traffic with a > given destination (or source?) prefix should be discarded, but that is > not what it says > > REQ4 I find vague, as I do anything with the word policy in it:-( > Something concrete (communities, MED, ...) would help > > REQ6 makes me wonder what is a RIB when it is not local > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > something more concrete. Again, I wonder if it is technically possible > to present information in a consistent manner given the difference in > underlying concepts of protocols. > > REQ9 - again all embracing and as such, probably impossible, at least as > written. Limiting it just to BGP and a link-state protocol, again that > seems challenging. > > REQ10 - policies again, and it is unclear who is doing the time > management. Some configuration protocols do have timer-based > facilities, but not NETCONF; do you mean here that I2RS must have > functionality based on timers (e.g. between 08:00 and 17:00 EDT, route > this via Europe and Japan?) > > Tom Petch > >> >> URL: > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt >> >> Sue Hares >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 13 06:06:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48D61B285D for ; Fri, 13 Jun 2014 06:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRw_vRd8waR2 for ; Fri, 13 Jun 2014 06:06:43 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD221B284E for ; Fri, 13 Jun 2014 06:06:43 -0700 (PDT) Received: from 108-78-210-25.lightspeed.chrlnc.sbcglobal.net ([108.78.210.25]:51889 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WvRBl-00067N-O3; Fri, 13 Jun 2014 13:06:38 +0000 From: "Russ White" To: "'t.petch'" , "'Susan Hares'" , References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> In-Reply-To: <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> Date: Fri, 13 Jun 2014 09:06:25 -0400 Message-ID: <055f01cf8708$49597000$dc0c5000$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqmYqFrLA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/pu3NBUtx91jNovyoWgqjxqwBo4s Cc: 'Jeffrey Haas' , 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:06:47 -0000 > I note the reference to ISIS which I find significant. My experience is more of > OSPF but appreciate that that is rare with Operators. However, both are Link > State and so very different to BGP which makes me think about the use of > RIB. The NETMOD routing-cfg started with RIBs, dropped them and then > reinstated them (after consulting with I2RS), whereas for me, RIBs are BGP > (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is very > different in detail (as much research as Lada has done across three differing > platforms, I am not certain that the NETMOD has sufficient routing expertise > to get this perfect:-(. There are two different "RIBs," at least in theory -- vendor implementations may vary. To try and separate things out, let's describe a few tables, see if that's a complete description, and then try to name these things. - There is the set of all the reachability information received by any given process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or IS-IS. - There is the set of best paths determined by the particular process. I would correlate this to the SPT in OSPF or IS-IS, and the BGP best path table. - There is the set of paths actually installed in the local device memory, and off of which the local forwarding tables are built. Each process running on the device installs reachability information into this table, and there is some arbitration method within each implementation designed to determine which process "wins," when there are multiple installs for the same destination, as well as "callbacks" for when routes are removed, and even perhaps "backup routes," and the like. - There is the set of forwarding table entries actually used for forwarding traffic. Note there may be two layers of these, but they typically include mac header rewrites, tunnel headers, and the like -- none of which any of the "ribs" described above would contain (they would only contain a next hop, not the actual rewrite information). If there are any I've missed, please feel free to add them in. This draft is supposed to be addressing use cases that are centered on the third one above in a "generic" way (not specific to some routing protocol, etc.). > REQ1 last sentence should probably include removing process I'm fine with including this, but I can't think of a use case off the top of my head... > REQ2 I think is about source-based routing but it does not quite say that, > rather reading as if source or destination routing were equally valid options It intends to say that both source and destination routing are equally valid options from the perspective of installed stuff into the RIB (#3 above). > REQ3 again the wording seems odd - I think you mean that traffic with a given > destination (or source?) prefix should be discarded, but that is not what it > says This is akin to remote triggered black holes -- a route to interface null0, which can be targeted either through the source (source routing) or the destination. > REQ4 I find vague, as I do anything with the word policy in it:-( Something > concrete (communities, MED, ...) would help This isn't really MED (that would fall into the BGP use cases draft), but rather mostly focused on setting the next hop, backup routes, source routes, and other places where you might forward based on things like port numbers, etc. > REQ6 makes me wonder what is a RIB when it is not local I suppose it could be remote in some way. Think of the RIB of a virtual router that then installs routes using OpenFlow into a remote switch -- is the RIB remote, or the FIB? I don't really know... I guess it might make more sense just to take the word "local" out here. > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something > more concrete. Again, I wonder if it is technically possible to present > information in a consistent manner given the difference in underlying > concepts of protocols. This is actually restricted to the RIB (#3 above) by the context of the draft, but it might be useful to add some restrictive language here. > REQ9 - again all embracing and as such, probably impossible, at least as > written. Limiting it just to BGP and a link-state protocol, again that seems > challenging. Again, this is implied to be restricted to the RIB (#3 above) by the context of the draft. Adding some restrictive language here might be useful, or it might be overkill (your choice :-) ). > REQ10 - policies again, and it is unclear who is doing the time management. > Some configuration protocols do have timer-based facilities, but not > NETCONF; do you mean here that I2RS must have functionality based on > timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and Japan?) Time based processing here generally means, "last route installed wins, given all equal preferences otherwise," or perhaps, "time is the tiebreaker." This area might need work, as this makes the final state non-atomic (order dependent). The problem is there's no way to ensure everyone is using different preference levels, etc. Any thoughts here welcome. :-) Russ From nobody Fri Jun 13 11:44:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335731B29E3 for ; Fri, 13 Jun 2014 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWhkYpzC6UUa for ; Fri, 13 Jun 2014 11:44:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F6C1B29E1 for ; Fri, 13 Jun 2014 11:44:17 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 18:44:03 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 18:44:03 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Thread-Index: AQHPgcJPUJvejJP5KkGEiMWG5tf2EJtsshcAgAK5SAA= Date: Fri, 13 Jun 2014 18:44:03 +0000 Message-ID: <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> In-Reply-To: <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377424004)(377454003)(24454002)(51704005)(199002)(189002)(13464003)(50226001)(21056001)(82746002)(31966008)(74662001)(15202345003)(19580405001)(76482001)(15975445006)(83716003)(80022001)(16236675004)(93886003)(74502001)(19580395003)(66066001)(46102001)(62966002)(79102001)(105586001)(83322001)(20776003)(57306001)(81542001)(36756003)(76176999)(77982001)(50986999)(101416001)(64706001)(87936001)(89996001)(99396002)(86362001)(99286001)(93916002)(85852003)(104166001)(33656002)(83072002)(81342001)(4396001)(16601075003)(77156001)(87286001)(2656002)(92726001)(92566001)(88136002)(104396001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB438; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_41EEF4CB46944617B2BF71F89237AB1Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/XW7Fae96ujLBPdwfcKgRoaO4vrg Cc: "" , Susan Hares , "" , "t.petch" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 18:44:27 -0000 --_000_41EEF4CB46944617B2BF71F89237AB1Djunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Susan, Sorry for late reply, but yesterday started a very significant quadrennial = event (FIFA World Cup) and Croatia played (and lost with help of the refere= e). WRT REQ04, I agree with the posts and here are few thoughts on this We should try to divide policies into few categories. 1. persistent There is a set of policies that have to be available from very start on the= device. Those policies should be persistent on the device and I see them c= hanging infrequently. IMO, there is no need for I2RS to manage those polici= es, readonly access is sufficient. 2. transient Policies that are temporary defining some fwd behavior of device. I can see= lot of cases where different applications based on some network conditions= want to change forwarding behavior. Those should not be available after re= boot. 3. locally defined by this I mean policies that defined by admin, applications through local I= 2RS agent. These can be transient and persistent, where I would classify th= at I2RS agent policies are only transient. Actually after rereading this, I= would even consider policies defined by I2RS as remotely defined and there= fore transient. 4. remotely defined by this I mean policies pushed from a different device (policy server, rout= er) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always = ephemeral. Dean On Jun 11, 2014, at 9:08 PM, Susan Hares > wrote: Dean: I combined REQ01/02 and REQ08/09. I've put the requirements in the front o= f the text. Please let know if have any suggestions on these approved chan= ges. I wait 24 hours, and then spin the draft. On the agreement on REQ04, I cannot find a firm consensus. I would ask Jef= f Haas or Ed Crabbe to indicate if they think there is a consensus on the W= G. I highlight a few messages below. The document is proposed for WG consen= sus so I will change it if the WG has consensus. Sue Hares Search for Consensus =3D=3D=3D=3D=3D Based on your comment, I sent looking for WG Direction regarding BGP or I2R= S putting state. I cannot find it. BGP has a Flow specification (RFC5575= ). Where do you think those flow specifications end up? Writing into runt= ime configuration state? Writing into something like I2RS running data stor= e? BGP ORFs might be kept in the BGP state or in associated features (Add/= delete) in BGP, but Flow specifications are targeted toward data flow. On the list I could find the following: 1. I2RS BGP state to configuration - Wes George (operator) makes a comment = that I2RS configuration should not replace current configuration related to= BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. perma= nent) - is the debate for the architecture document regarding keeping state= in the I2RS Begin: http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Joel's: no state across a reboot: http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html 3. Wes George (operator) makes a comment that I2RS configuration should not= replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html There is the Architecture Discussion 2: Persistence (ephemeral vs. permanen= t) http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Multiple clients writing to agents (raised by Himanshu Shah) http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html Jeff (chair hat off) states he does not want to have I2rs changing state ta= bles come from routing protocols (BGP--> I2RS state). He also feel dynamic= state tables should be read-only, and not writable as suggested by the use= case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html In the same thread, Sri states the I2RS agent should not provide an interfa= ce to change a table if there is no use-case to support it. Dynamic protoc= ols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri states " I am yet to = see a use-case that requires direct manipulation of a single dynamic routin= g-protocol-instance specific route table by something other than that proto= col. I don't believe there should be any such case." However, here it ha= s been in the BGP use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html Jeff responds to Sri in tends to agree and does not mention the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html Sue Hares -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; >; Keyur Patel (keyupate);= Hannes Gredler; Russ White; Susan Hares; > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Rea= chability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you= get to the very and where all requirements are listed and then it makes se= nse. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should = impose persistent policies? It says it should be recorded in the configurat= ion of the local device. I agree that those policies should be visible to operators and other applic= ations, but not sure if dynamic protocols should be allowed to implement pe= rsistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such = as NETCONF, and should be recorded in the running or ephemeral configuratio= n of the local device so operators are aware of the full policy implemented= in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a= good idea. If you plan to change only what is configured on the local devi= ce, then that is OK, but if you start changing entries that are pushed from= other devices in the network, the system would get unstable. And it looks = to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares > wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this = was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourse= lves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" > > To: > > Cc: "'Keyur Patel (keyupate)'" >; "Hannes Gredler" > >; "Russ White" >; "'Susan Hares'" > >; = > > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Be= half Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --_000_41EEF4CB46944617B2BF71F89237AB1Djunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <739CB1876143064E91A1139460540EEC@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Susan,

Sorry for late reply, but yesterday started a very significant quadren= nial event (FIFA World Cup) and Croatia played (and lost with help of the r= eferee).

WRT REQ04, I agree with the posts and here are few thoughts on this

We should try to divide policies into few categories.

1. persistent
There is a set of policies that have to be available from very start o= n the device. Those policies should be persistent on the device and I see t= hem changing infrequently. IMO, there is no need for I2RS to manage those p= olicies, readonly access is sufficient.
2. transient
Policies that are temporary defining some fwd behavior of device. I ca= n see lot of cases where different applications based on some network condi= tions want to change forwarding behavior. Those should not be available aft= er reboot. 
3. locally defined
by this I mean policies that defined by admin, applications through lo= cal I2RS agent. These can be transient and persistent, where I would classi= fy that I2RS agent policies are only transient. Actually after rereading th= is, I would even consider policies defined by I2RS as remotely defined and therefore transient.
4. remotely defined
by this I mean policies pushed from a different device (policy server,= router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be al= ways ephemeral.

Dean

On Jun 11, 2014, at 9:08 PM, Susan Hares <shares@ndzh.com> wrote:

Dean:
 =
I combined RE= Q01/02 and REQ08/09.  I've put the requirements in the front of the te= xt.  Please let know if have any suggestions on these approved changes= .  I wait 24 hours, and then spin the draft.
 =
On the agreem= ent on REQ04, I cannot find a firm consensus.  I would ask Jeff Haas o= r Ed Crabbe to indicate if they think there is a consensus on the WG. I hig= hlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus.<= o:p>
 =
 =
Sue Hares
 =
 =
Search for Co= nsensus
=3D=3D=3D=3D= =3D
Based on your= comment, I sent looking for WG Direction regarding BGP or I2RS putting sta= te.   I cannot find it.  BGP has a Flow specification (RFC55= 75).  Where do you think those flow specifications end up?  Writing into runtime configuration state? Writing into somet= hing like I2RS running data store?  BGP ORFs might be kept in the BGP = state or in associated features (Add/delete) in BGP, but Flow specification= s are targeted toward data flow.
 =
On the list I= could find the following:
 =
1. I2RS BGP s= tate to configuration - Wes George (operator) makes a comment that I2RS con= figuration should not replace current configuration related to BGP. 
 =
 =
 =
 =
2. There is t= he Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is th= e debate for the architecture document regarding keeping state in the I2RS<= o:p>
Begin: <= o:p>
 =
Joel's: no st= ate across a reboot: 
 =
 =
3. Wes George= (operator) makes a comment that I2RS configuration should not replace curr= ent configuration related to BGP. 
 =
 =
There is the = Architecture Discussion 2: Persistence (ephemeral vs. permanent)=
 =
 =
Multiple clie= nts writing to agents (raised by Himanshu Shah)
 =
 =
Jeff (chair h= at off) states he does not want to have I2rs changing state tables come fro= m routing protocols (BGP--> I2RS state).  He also feel dynamic stat= e tables should be read-only, and not writable as suggested by the use case.
 =
 =
In the same t= hread, Sri states the I2RS agent should not provide an interface to change = a table if there is no use-case to support it.  Dynamic protocols --&g= t; I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri states " I am yet to see a use-case that requires direct manipula= tion of a single dynamic routing-protocol-instance specific route table by = something other than that protocol. I don't believe there should be any suc= h case."    However, here it has been in the BGP use case.
 =
 =
Jeff responds= to Sri in tends to agree and does not mention the use case.
 =
 
Sue Hares
 
-----Original Message-----
From: Dean Bogdanovic [mailto:deanb@juniper.net]
Sent: Friday, June 06, 2014 4:03 PM
To: Susan Hares
Cc: t.petch; <i2rs@ietf.org>; Ke= yur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; <rex@cisco.com>
Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt
 
Susan,
 
Many people don't know what NLRI abbreviation stands for (Network Layer Rea= chability Information , so writing it out first time would be a good idea.<= o:p>
 
Throughout the text, the requirement number sequence is confusing until you= get to the very and where all requirements are listed and then it makes se= nse.
 
REQ04: The ability to interact with various policies configured on
      the forwarding devices, in order to inform t= he policies
      implemented by the dynamic routing processes= .  This interaction
      should be through existing configuration mec= hanisms, such as
      NETCONF, and should be recorded in the confi= guration of the local
      device so operators are aware of the full po= licy implemented in
      the network from the running configuration.<= o:p>
It is not clear to me if your requirement is that dynamic protocols should = impose persistent policies? It says it should be recorded in the configurat= ion of the local device.
 
I agree that those policies should be visible to operators and other applic= ations, but not sure if dynamic protocols should be allowed to implement pe= rsistent policies. IMO, those should be ephemeral policies.
So maybe text should look like this
This interaction should be through existing configuration mechanisms, such = as NETCONF, and should be recorded in the running or ephemeral configuratio= n of the local device so operators are aware of the full policy implemented= in the network from the running configuration.
 
I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09?
 
In general I'm not sure if changing entries by dynamic protocol in RIB is a= good idea. If you plan to change only what is configured on the local devi= ce, then that is OK, but if you start changing entries that are pushed from= other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that.=
 
Dean
 
 
On Jun 5, 2014, at 4:47 AM, Susan Hares <shares@ndzh.com> wrote:
 
> Tom:
>
> I'm glad to change the citation in the abstract.    On = the authors, this was
> merge of two drafts.
>
> Sue
>
> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com]<= /div>
> Sent: Thursday, June 05, 2014 4:35 AM
> To: Susan Hares; i2rs@ietf.org
> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan<= /o:p>
> Hares'; = rex@cisco.com
> Subject: Re: [i2rs] FW: I-D Action:
> draft-keyupate-i2rs-bgp-usecases-02.txt
>
> Sue
>
> Currently you have six authors which is too many for an RFC - someone'= s
> got to go!   For me, this is not just an admin point - when = commenting,
> I like to have one or two names, no more, as the clear pen holders
> whom I can expect to act.  Too often, with so many names, everyon= e
> thinks that someone else will do something and nothing happens, so, in=
> all seriousness, I oppose adoption until you sort this out amongst you= rselves.
>
> Note too that you have a citation in the Abstract, again not allowed -=
> this can be surprising difficult to get round but get round it you,
> one or more thereof, must.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Susan Hares" <shares@ndzh.com>= ;
> To: <i2rs@ietf.org>
> Cc: "'Keyur Patel (keyupate)'" <keyupate= @cisco.com>; "Hannes Gredler"
> <hannes@juniper.net>; "Russ White"= ; <russw@riw.us>; "'Susan Hares'"=
> Sent: Wednesday, June 04, 2014 7:49 PM
> Subject: [i2rs] FW: I-D Action:
> draft-keyupate-i2rs-bgp-usecases-02.txt
>
>
>> Jeff and Ed:
>>
>> This updated draft has all the changes that Keyur Patel promised a= nd
> updates
>> to the reference the current i2rs internet drafts.
>>
>> Would you please do a Working Group adoption call?
>>
>> Thank you,
>> Sue Hares
>>
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On B= ehalf Of
>> Sent: Wednesday, June 04, 2014 1:44 PM
>> Cc: i2rs@ietf.org<= /div>
>> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.tx= t
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories.
>> This draft is a work item of the Interface to the Routing System
> Working
>> Group of the IETF.
>>
>>        Title   &= nbsp;       : Use Cases for an Interface to B= GP Protocol
>>        Authors   = ;      : Keyur Patel
>>           &= nbsp;           &nbs= p;  Rex Fernando
>>           &= nbsp;           &nbs= p;  Hannes Gredler
>>           &= nbsp;           &nbs= p;  Shane Amante
>>           &= nbsp;           &nbs= p;  Russ White
>>           &= nbsp;           &nbs= p;  Susan Hares
>> Filename        : draft-keyupat= e-i2rs-bgp-usecases-02.txt
>> Pages           = : 17
>> Date          &n= bsp; : 2014-06-04
>>
>> Abstract:
>>   A network routing protocol like BGP is typically confi= gured and
>>   analyzed through some form of Command Line Interface (= CLI) or
>>   NETCONF.  These interactions to control BGP and d= iagnose its
>>   operation encompass: configuration of protocol paramet= ers, display
> of
>>   protocol data, setting of certain protocol state and d= ebugging of
> the
>>   protocol.
>>
>>   Interface to the Routing System's (I2RS) Programmatic = interfaces,
> as
>>   defined in draft-ietf-i2rs-architecture, provides an a= lternate way
> to
>>   control and diagnose the operation of the BGP protocol= .  I2RS may
> be
>>   used for the configuration, manipulation, analyzing or= collecting
> the
>>   protocol data.  This document describes set of us= e cases for which
>>   I2RS can be used for BGP protocol.  It is intende= d to provide a
> base
>>   for the solution draft describing a set of interfaces = to the BGP
>>   protocol.
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>> There's also a htmlized version available at:
>>
>> A diff from the previous version is available at:
>>
>>
>> Please note that it may take a couple of minutes from the time of<= o:p>
> submission
>> until the htmlized version and diff are available at tools.ietf.org.<= /o:p>
>>
>> Internet-Drafts are also available by anonymous FTP at:=
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>>
>
>
> _______________________________________________
> i2rs mailing list
<draft-keyupate-i2rs-bgp-usecases-03.txt><draft= -keyupate-i2rs-bgp-usecases-03.txt.pdf>

--_000_41EEF4CB46944617B2BF71F89237AB1Djunipernet_-- From nobody Fri Jun 13 14:50:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4487C1B2A78 for ; Fri, 13 Jun 2014 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUDyzj0Uf7r8 for ; Fri, 13 Jun 2014 14:50:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87A1B2A59 for ; Fri, 13 Jun 2014 14:50:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> In-Reply-To: <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> Date: Fri, 13 Jun 2014 17:49:35 -0400 Message-ID: <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017C_01CF872F.D79850D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qAGayTg4AbY3QWQChw5Z8wECQGW8AliOGgEC5qgM2JrVp8lA Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ezkf4UWXHu3kTJXmJDMrMUfwUOQ Cc: i2rs@ietf.org, 'Susan Hares' , rex@cisco.com, "'t.petch'" , "'Keyur Patel \(keyupate\)'" , 'Hannes Gredler' , 'Russ White' Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:50:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017C_01CF872F.D79850D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean: Thank you for your thoughtful answer. I was looking for it, but I'm glad you watched Croatia (I'm sorry about Croatia's loss). I agree with the types of policies and the status: persistent, transient, and ephemeral. However, do we ever let I2RS upon a command transfer policies to the persistent storage? This what I read in REQ04. In reading the email, I'm not sure how to summarize the WG's approach. My answer would be "no", but if this is a WG document the answer needs to come from the WG. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Friday, June 13, 2014 2:44 PM To: Susan Hares Cc: ; Susan Hares; ; t.petch; Keyur Patel (keyupate); Hannes Gredler; Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Sorry for late reply, but yesterday started a very significant quadrennial event (FIFA World Cup) and Croatia played (and lost with help of the referee). WRT REQ04, I agree with the posts and here are few thoughts on this We should try to divide policies into few categories. 1. persistent There is a set of policies that have to be available from very start on the device. Those policies should be persistent on the device and I see them changing infrequently. IMO, there is no need for I2RS to manage those policies, readonly access is sufficient. 2. transient Policies that are temporary defining some fwd behavior of device. I can see lot of cases where different applications based on some network conditions want to change forwarding behavior. Those should not be available after reboot. 3. locally defined by this I mean policies that defined by admin, applications through local I2RS agent. These can be transient and persistent, where I would classify that I2RS agent policies are only transient. Actually after rereading this, I would even consider policies defined by I2RS as remotely defined and therefore transient. 4. remotely defined by this I mean policies pushed from a different device (policy server, router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always ephemeral. Dean On Jun 11, 2014, at 9:08 PM, Susan Hares wrote: Dean: I combined REQ01/02 and REQ08/09. I've put the requirements in the front of the text. Please let know if have any suggestions on these approved changes. I wait 24 hours, and then spin the draft. On the agreement on REQ04, I cannot find a firm consensus. I would ask Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on the WG. I highlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus. Sue Hares Search for Consensus ===== Based on your comment, I sent looking for WG Direction regarding BGP or I2RS putting state. I cannot find it. BGP has a Flow specification (RFC5575). Where do you think those flow specifications end up? Writing into runtime configuration state? Writing into something like I2RS running data store? BGP ORFs might be kept in the BGP state or in associated features (Add/delete) in BGP, but Flow specifications are targeted toward data flow. On the list I could find the following: 1. I2RS BGP state to configuration - Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is the debate for the architecture document regarding keeping state in the I2RS Begin: http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Joel's: no state across a reboot: http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html 3. Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Multiple clients writing to agents (raised by Himanshu Shah) http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html Jeff (chair hat off) states he does not want to have I2rs changing state tables come from routing protocols (BGP--> I2RS state). He also feel dynamic state tables should be read-only, and not writable as suggested by the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html In the same thread, Sri states the I2RS agent should not provide an interface to change a table if there is no use-case to support it. Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri states " I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case." However, here it has been in the BGP use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html Jeff responds to Sri in tends to agree and does not mention the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html Sue Hares -----Original Message----- From: Dean Bogdanovic [mailto:deanb@ juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; ; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; < rex@cisco.com> Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Reachability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you get to the very and where all requirements are listed and then it makes sense. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should impose persistent policies? It says it should be recorded in the configuration of the local device. I agree that those policies should be visible to operators and other applications, but not sure if dynamic protocols should be allowed to implement persistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the running or ephemeral configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a good idea. If you plan to change only what is configured on the local device, then that is OK, but if you start changing entries that are pushed from other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares < shares@ndzh.com> wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@ btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourselves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" < shares@ndzh.com> > To: > Cc: "'Keyur Patel (keyupate)'" < keyupate@cisco.com>; "Hannes Gredler" > < hannes@juniper.net>; "Russ White" < russw@riw.us>; "'Susan Hares'" > < skh@ndzh.com>; < rex@cisco.com> > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs- bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_017C_01CF872F.D79850D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean:

Thank you for your thoughtful answer.  I was looking for it, but = I’m glad you watched Croatia (I’m sorry about = Croatia’s loss).

 

I agree with the types of policies and the status: persistent, = transient, and ephemeral.  However, do we ever let I2RS upon a = command transfer policies to the persistent storage?  This what I = read in REQ04.    In reading the email, I’m not = sure how to summarize the WG’s approach.  My answer would be = “no”, but if this is a WG document the answer needs to come = from the WG.

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean = Bogdanovic
Sent: Friday, June 13, 2014 2:44 PM
To: = Susan Hares
Cc: <i2rs@ietf.org>; Susan Hares; = <rex@cisco.com>; t.petch; Keyur Patel (keyupate); Hannes Gredler; = Russ White
Subject: Re: [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

=

 

Susan, =

 

Sorry for late reply, but yesterday started a very = significant quadrennial event (FIFA World Cup) and Croatia played (and = lost with help of the referee).

 

WRT REQ04, I agree with the posts and here are few = thoughts on this

 

We should try to divide policies into few = categories.

 

1. persistent

There is a set of policies that have to be available = from very start on the device. Those policies should be persistent on = the device and I see them changing infrequently. IMO, there is no need = for I2RS to manage those policies, readonly access is = sufficient.

2. = transient

Policies that = are temporary defining some fwd behavior of device. I can see lot of = cases where different applications based on some network conditions want = to change forwarding behavior. Those should not be available after = reboot. 

3. locally = defined

by this I mean = policies that defined by admin, applications through local I2RS agent. = These can be transient and persistent, where I would classify that I2RS = agent policies are only transient. Actually after rereading this, I = would even consider policies defined by I2RS as remotely defined and = therefore transient.

4. = remotely defined

by this I = mean policies pushed from a different device (policy server, router) via = some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always = ephemeral.

 

Dean

 

On Jun 11, 2014, at 9:08 PM, Susan Hares <shares@ndzh.com> = wrote:



Dean:=

 =

I combined REQ01/02 = and REQ08/09.  I've put the requirements in the front of the = text.  Please let know if have any suggestions on these approved = changes.  I wait 24 hours, and then spin the draft.=

 =

On the agreement on = REQ04, I cannot find a firm consensus.  I would ask Jeff Haas or Ed = Crabbe to indicate if they think there is a consensus on the WG. I = highlight a few messages below. The document is proposed for WG = consensus so I will change it if the WG has consensus.=

 =

 =

Sue = Hares=

 =

 =

Search for = Consensus=

=3D=3D=3D=3D=3D=

Based on your = comment, I sent looking for WG Direction regarding BGP or I2RS putting = state.   I cannot find it.  BGP has a Flow specification = (RFC5575).  Where do you think those flow specifications end = up?  Writing into runtime configuration state? Writing into = something like I2RS running data store?  BGP ORFs might be kept in = the BGP state or in associated features (Add/delete) in BGP, but Flow = specifications are targeted toward data flow.=

 =

On the list I could = find the following:=

 =

1. I2RS BGP state = to configuration - Wes George (operator) makes a comment that I2RS = configuration should not replace current configuration related to = BGP. =

 =

 =

 =

 =

2. There is the = Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is = the debate for the architecture document regarding keeping state in the = I2RS=

Begin: =

 =

Joel's: no state = across a reboot: =

 =

 =

3. Wes George = (operator) makes a comment that I2RS configuration should not replace = current configuration related to BGP. =

 =

 =

There is the = Architecture Discussion 2: Persistence (ephemeral vs. = permanent)=

 =

 =

Multiple clients = writing to agents (raised by Himanshu Shah)=

 =

 =

Jeff (chair hat = off) states he does not want to have I2rs changing state tables come = from routing protocols (BGP--> I2RS state).  He also feel = dynamic state tables should be read-only, and not writable as suggested = by the use case.=

 =

 =

In the same thread, = Sri states the I2RS agent should not provide an interface to change a = table if there is no use-case to support it.  Dynamic protocols = --> I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri = states " I am yet to see a use-case that requires direct = manipulation of a single dynamic routing-protocol-instance specific = route table by something other than that protocol. I don't believe there = should be any such case."    However, here it has = been in the BGP use case.=

 =

 =

Jeff responds to = Sri in tends to agree and does not mention the use case.=

 =

 =

Sue = Hares

 =

-----Origin= al Message-----

From: Dean = Bogdanovic [mailto:deanb@juniper.net]

Sent: = Friday, June 06, 2014 4:03 PM

To: Susan = Hares

Cc: = t.petch; <i2rs@ietf.org>; = Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; <rex@cisco.com>

=

Subject: = Re: [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

<= p class=3DMsoNormal> =

Susan,=

 =

Many = people don't know what NLRI abbreviation stands for (Network Layer = Reachability Information , so writing it out first time would be a good = idea.

 =

Throughout = the text, the requirement number sequence is confusing until you get to = the very and where all requirements are listed and then it makes = sense.

 =

REQ04: The = ability to interact with various policies configured = on

  = ;    the forwarding devices, in order to inform the = policies

  = ;    implemented by the dynamic routing processes.  = This interaction

  = ;    should be through existing configuration mechanisms, = such as

  = ;    NETCONF, and should be recorded in the configuration = of the local

  = ;    device so operators are aware of the full policy = implemented in

  = ;    the network from the running = configuration.

It is not = clear to me if your requirement is that dynamic protocols should impose = persistent policies? It says it should be recorded in the configuration = of the local device.

 =

I agree = that those policies should be visible to operators and other = applications, but not sure if dynamic protocols should be allowed to = implement persistent policies. IMO, those should be ephemeral = policies.

So maybe = text should look like this

This = interaction should be through existing configuration mechanisms, such as = NETCONF, and should be recorded in the running or ephemeral = configuration of the local device so operators are aware of the full = policy implemented in the network from the running = configuration.

 =

I'm trying = to see major difference between REQ01/REQ02 and = REQ08/REQ09?

 =

In general = I'm not sure if changing entries by dynamic protocol in RIB is a good = idea. If you plan to change only what is configured on the local device, = then that is OK, but if you start changing entries that are pushed from = other devices in the network, the system would get unstable. And it = looks to me that REQ09 would allow = that.

 =

Dean

 =

 =

On Jun 5, = 2014, at 4:47 AM, Susan Hares <shares@ndzh.com> = wrote:

 =

> = Tom:

>&n= bsp;

> I'm = glad to change the citation in the abstract.    On the = authors, this was

> merge = of two drafts.

>&n= bsp;

> = Sue

>&n= bsp;

> = -----Original Message-----

> From: = t.petch [mailto:ietfc@btconnect.com]

> Sent: = Thursday, June 05, 2014 4:35 AM

> To: = Susan Hares; i2rs@ietf.org

> Cc: = 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; = 'Susan

> = Hares'; rex@cisco.com

> = Subject: Re: [i2rs] FW: I-D Action:

> = draft-keyupate-i2rs-bgp-usecases-02.txt

<= p class=3DMsoNormal>>&n= bsp;

> = Sue

>&n= bsp;

> = Currently you have six authors which is too many for an RFC - = someone's

> got = to go!   For me, this is not just an admin point - when = commenting,

> I = like to have one or two names, no more, as the clear pen = holders

> whom = I can expect to act.  Too often, with so many names, = everyone

> = thinks that someone else will do something and nothing happens, so, = in

> all = seriousness, I oppose adoption until you sort this out amongst = yourselves.

>&n= bsp;

> Note = too that you have a citation in the Abstract, again not allowed = -

> this = can be surprising difficult to get round but get round it = you,

> one = or more thereof, must.

>&n= bsp;

> Tom = Petch

>&n= bsp;

>&n= bsp;

> ----- = Original Message -----

> From: = "Susan Hares" <shares@ndzh.com>

> To: = <i2rs@ietf.org>

=

> Cc: = "'Keyur Patel (keyupate)'" <keyupate@cisco.com>; "Hannes = Gredler"

> = <hannes@juniper.net>; "Russ = White" <russw@riw.us>; "'Susan = Hares'"

> Sent: = Wednesday, June 04, 2014 7:49 PM

> = Subject: [i2rs] FW: I-D Action:

> = draft-keyupate-i2rs-bgp-usecases-02.txt

<= p class=3DMsoNormal>>&n= bsp;

>&n= bsp;

>> = Jeff and Ed:

>> 

>> = This updated draft has all the changes that Keyur Patel promised = and

> = updates

>> = to the reference the current i2rs internet = drafts.

>> 

>> = Would you please do a Working Group adoption = call?

>> 

>> = Thank you,

>> = Sue Hares

>> 

>> 

>> = -----Original Message-----

>> = From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf = Of

>> = Sent: Wednesday, June 04, 2014 1:44 = PM

>> = Cc: i2rs@ietf.org

>> = Subject: [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

<= p class=3DMsoNormal>>> 

>> 

>> A = New Internet-Draft is available from the on-line = Internet-Drafts

>> = directories.

>> = This draft is a work item of the Interface to the Routing = System

> = Working

>> = Group of the IETF.

>> 

>>&nb= sp;       = Title           : Use = Cases for an Interface to BGP = Protocol

>>&nb= sp;       = Authors         : Keyur = Patel

>>&nb= sp;           &nbs= p;            = ; Rex Fernando

>>&nb= sp;           &nbs= p;            = ; Hannes Gredler

>>&nb= sp;           &nbs= p;            = ; Shane Amante

>>&nb= sp;           &nbs= p;            = ; Russ White

>>&nb= sp;           &nbs= p;            = ; Susan Hares

>> = Filename        : = draft-keyupate-i2rs-bgp-usecases-02.txt

<= p class=3DMsoNormal>>> = Pages           : = 17

>> = Date            : = 2014-06-04

>> 

>> = Abstract:

>>&nb= sp;  A network routing protocol like BGP is typically configured = and

>>&nb= sp;  analyzed through some form of Command Line Interface (CLI) = or

>>&nb= sp;  NETCONF.  These interactions to control BGP and diagnose = its

>>&nb= sp;  operation encompass: configuration of protocol parameters, = display

> = of

>>&nb= sp;  protocol data, setting of certain protocol state and debugging = of

> = the

>>&nb= sp;  protocol.

>> 

>> =   Interface to the Routing System's (I2RS) Programmatic = interfaces,

> = as

>>&nb= sp;  defined in draft-ietf-i2rs-architecture, provides an alternate = way

> = to

>>&nb= sp;  control and diagnose the operation of the BGP protocol.  = I2RS may

> = be

>>&nb= sp;  used for the configuration, manipulation, analyzing or = collecting

> = the

>>&nb= sp;  protocol data.  This document describes set of use cases = for which

>>&nb= sp;  I2RS can be used for BGP protocol.  It is intended to = provide a

> = base

>>&nb= sp;  for the solution draft describing a set of interfaces to the = BGP

>>&nb= sp;  protocol.

>> 

>> 

>> = The IETF datatracker status page for this draft = is:

>> 

>> = There's also a htmlized version available = at:

>> 

>> A = diff from the previous version is available = at:

>> 

>> 

>> = Please note that it may take a couple of minutes from the time = of

> = submission

 

------=_NextPart_000_017C_01CF872F.D79850D0-- From nobody Fri Jun 13 15:06:46 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB891A025A for ; Fri, 13 Jun 2014 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hgn-q-HbAeEv for ; Fri, 13 Jun 2014 15:06:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82931B2A59 for ; Fri, 13 Jun 2014 15:06:35 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 22:06:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 22:06:31 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Thread-Index: AQHPgcJPUJvejJP5KkGEiMWG5tf2EJtsshcAgAK5SACAADPXgIAABLmA Date: Fri, 13 Jun 2014 22:06:31 +0000 Message-ID: References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> In-Reply-To: <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(428001)(377454003)(13464003)(189002)(199002)(24454002)(377424004)(51704005)(81542001)(87286001)(64706001)(101416001)(4396001)(89996001)(21056001)(77982001)(66066001)(2656002)(62966002)(88136002)(83072002)(46102001)(80022001)(92726001)(87936001)(85852003)(50226001)(81342001)(105586001)(16236675004)(79102001)(20776003)(92566001)(76482001)(16601075003)(15202345003)(36756003)(83716003)(99286001)(77156001)(74662001)(57306001)(31966008)(74502001)(99396002)(50986999)(83322001)(19580395003)(19580405001)(33656002)(104166001)(93886003)(76176999)(93916002)(82746002)(15975445006)(86362001)(104396001)(569005); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB440; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: multipart/alternative; boundary="_000_F09CEB8D4FBB463D97EB96BB2A0C773Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/XqZeVJtx44EybxJxGoLzszXlpsY Cc: "" , Susan Hares , "" , "t.petch" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 22:06:41 -0000 --_000_F09CEB8D4FBB463D97EB96BB2A0C773Djunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Susan, My answer to your question do we ever let I2RS upon a command transfer policies to the persistent stor= age? My initial answer is no. And reason is security. Network admins want to kno= w exact state of the device after rebooting. If we want to allow transfer o= f policies, then we would have to define roles and which roles would be all= owed to do that transfer. We are making things more complex, when there are= existing mechanisms for admins to do that. Dean On Jun 13, 2014, at 5:49 PM, Susan Hares > wrote: Dean: Thank you for your thoughtful answer. I was looking for it, but I=92m glad= you watched Croatia (I=92m sorry about Croatia=92s loss). I agree with the types of policies and the status: persistent, transient, a= nd ephemeral. However, do we ever let I2RS upon a command transfer policie= s to the persistent storage? This what I read in REQ04. In reading the = email, I=92m not sure how to summarize the WG=92s approach. My answer woul= d be =93no=94, but if this is a WG document the answer needs to come from t= he WG. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behal= f Of Dean Bogdanovic Sent: Friday, June 13, 2014 2:44 PM To: Susan Hares Cc: >; Susan Hares; >; t.petch; Keyur Patel (keyupate); Hannes Gredler; Russ W= hite Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Sorry for late reply, but yesterday started a very significant quadrennial = event (FIFA World Cup) and Croatia played (and lost with help of the refere= e). WRT REQ04, I agree with the posts and here are few thoughts on this We should try to divide policies into few categories. 1. persistent There is a set of policies that have to be available from very start on the= device. Those policies should be persistent on the device and I see them c= hanging infrequently. IMO, there is no need for I2RS to manage those polici= es, readonly access is sufficient. 2. transient Policies that are temporary defining some fwd behavior of device. I can see= lot of cases where different applications based on some network conditions= want to change forwarding behavior. Those should not be available after re= boot. 3. locally defined by this I mean policies that defined by admin, applications through local I= 2RS agent. These can be transient and persistent, where I would classify th= at I2RS agent policies are only transient. Actually after rereading this, I= would even consider policies defined by I2RS as remotely defined and there= fore transient. 4. remotely defined by this I mean policies pushed from a different device (policy server, rout= er) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always = ephemeral. Dean On Jun 11, 2014, at 9:08 PM, Susan Hares > wrote: Dean: I combined REQ01/02 and REQ08/09. I've put the requirements in the front o= f the text. Please let know if have any suggestions on these approved chan= ges. I wait 24 hours, and then spin the draft. On the agreement on REQ04, I cannot find a firm consensus. I would ask Jef= f Haas or Ed Crabbe to indicate if they think there is a consensus on the W= G. I highlight a few messages below. The document is proposed for WG consen= sus so I will change it if the WG has consensus. Sue Hares Search for Consensus =3D=3D=3D=3D=3D Based on your comment, I sent looking for WG Direction regarding BGP or I2R= S putting state. I cannot find it. BGP has a Flow specification (RFC5575= ). Where do you think those flow specifications end up? Writing into runt= ime configuration state? Writing into something like I2RS running data stor= e? BGP ORFs might be kept in the BGP state or in associated features (Add/= delete) in BGP, but Flow specifications are targeted toward data flow. On the list I could find the following: 1. I2RS BGP state to configuration - Wes George (operator) makes a comment = that I2RS configuration should not replace current configuration related to= BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. perma= nent) - is the debate for the architecture document regarding keeping state= in the I2RS Begin: http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Joel's: no state across a reboot: http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html 3. Wes George (operator) makes a comment that I2RS configuration should not= replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html There is the Architecture Discussion 2: Persistence (ephemeral vs. permanen= t) http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Multiple clients writing to agents (raised by Himanshu Shah) http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html Jeff (chair hat off) states he does not want to have I2rs changing state ta= bles come from routing protocols (BGP--> I2RS state). He also feel dynamic= state tables should be read-only, and not writable as suggested by the use= case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html In the same thread, Sri states the I2RS agent should not provide an interfa= ce to change a table if there is no use-case to support it. Dynamic protoc= ols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri states " I am yet to = see a use-case that requires direct manipulation of a single dynamic routin= g-protocol-instance specific route table by something other than that proto= col. I don't believe there should be any such case." However, here it ha= s been in the BGP use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html Jeff responds to Sri in tends to agree and does not mention the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html Sue Hares -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; >; Keyur Patel (keyupate);= Hannes Gredler; Russ White; Susan Hares; > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Rea= chability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you= get to the very and where all requirements are listed and then it makes se= nse. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should = impose persistent policies? It says it should be recorded in the configurat= ion of the local device. I agree that those policies should be visible to operators and other applic= ations, but not sure if dynamic protocols should be allowed to implement pe= rsistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such = as NETCONF, and should be recorded in the running or ephemeral configuratio= n of the local device so operators are aware of the full policy implemented= in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a= good idea. If you plan to change only what is configured on the local devi= ce, then that is OK, but if you start changing entries that are pushed from= other devices in the network, the system would get unstable. And it looks = to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares > wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this = was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourse= lves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" > > To: > > Cc: "'Keyur Patel (keyupate)'" >; "Hannes Gredler" > >; "Russ White" >; "'Susan Hares'" > >; = > > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Be= half Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --_000_F09CEB8D4FBB463D97EB96BB2A0C773Djunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <15BE530B8F5968468C3754CB5BCA4EAC@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Susan,

My answer  to your question
do we ever let I2RS upon a command transfer policies to t= he persistent storage? 

My initial answer is no. And reason is security. Network admins want t= o know exact state of the device after rebooting. If we want to allow trans= fer of policies, then we would have to define roles and which roles would b= e allowed to do that transfer. We are making things more complex, when there are existing mechanisms for adm= ins to do that.

Dean

On Jun 13, 2014, at 5:49 PM, Susan Hares <shares@ndzh.com> wrote:

Dean:
Thank you for your thoughtful answer.  I was looking= for it, but I=92m glad you watched Croatia (I=92m sorry about Croatia=92s = loss).
 
I agree with the types of policies and the status: persis= tent, transient, and ephemeral.  However, do we ever let I2RS upon a c= ommand transfer policies to the persistent storage?  This what I read in REQ04.    In reading the= email, I=92m not sure how to summarize the WG=92s approach.  My answe= r would be =93no=94, but if this is a WG document the answer needs to come = from the WG.
 
Sue
 
From:=  i2rs [mailto:i2rs-bounces@ietf.org]&nbs= p;On Behalf Of Dean Bogda= novic
Sent: Friday, June= 13, 2014 2:44 PM
To: Susan Hares Cc: <i2rs@ietf.org>; Susan Hares; <= rex@cisco.com>; t.petch; Keyur Patel (keyupate); Hannes Gredler; Russ White
Subject: Re: [i2rs= ] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt
 
Susan,
 
Sorry for late reply, but yesterday started a very significant quadrennial = event (FIFA World Cup) and Croatia played (and lost with help of the refere= e).
 
WRT REQ04, I agree with the posts and here are few thoughts on this
 
We should try to divide policies into few categories.
 
1. persistent
There is a set of policies that have to be available from very start on the= device. Those policies should be persistent on the device and I see them c= hanging infrequently. IMO, there is no need for I2RS to manage those polici= es, readonly access is sufficient.
2. transient
Policies that are temporary defining some fwd behavior of device. I can see= lot of cases where different applications based on some network conditions= want to change forwarding behavior. Those should not be available after re= boot. 
3. locally defined
by this I mean policies that defined by admin, applications through local I= 2RS agent. These can be transient and persistent, where I would classify th= at I2RS agent policies are only transient. Actually after rereading this, I= would even consider policies defined by I2RS as remotely defined and therefore transient.
4. remotely defined
by this I mean policies pushed from a different device (policy server, rout= er) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always = ephemeral.
 
Dean
 
On Jun 11, 2014, at 9:08 PM, Susan Hares <shares@ndzh.com<= /a>> wrote:


Dean:<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">
 =
I combined RE= Q01/02 and REQ08/09.  I've put the requirements in the front of the te= xt.  Please let know if have any suggestions on these approved changes= .  I wait 24 hours, and then spin the draft.
 =
On the agreem= ent on REQ04, I cannot find a firm consensus.  I would ask Jeff Haas o= r Ed Crabbe to indicate if they think there is a consensus on the WG. I hig= hlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus.<= /span><= o:p>
 =
 =
Sue Hares
 =
 =
Search for Co= nsensus
=3D=3D=3D=3D= =3D Based on your= comment, I sent looking for WG Direction regarding BGP or I2RS putting sta= te.   I cannot find it.  BGP has a Flow specification (RFC55= 75).  Where do you think those flow specifications end up?  Writing into runtime configuration state? Writing into somet= hing like I2RS running data store?  BGP ORFs might be kept in the BGP = state or in associated features (Add/delete) in BGP, but Flow specification= s are targeted toward data flow.
 =
On the list I= could find the following:
 =
1. I2RS BGP s= tate to configuration - Wes George (operator) makes a comment that I2RS con= figuration should not replace current configuration related to BGP. 
 =
 =
 =
 =
2. There is t= he Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is th= e debate for the architecture document regarding keeping state in the I2RS<= /span><= o:p>
Begin: <= /span><= o:p>
 =
Joel's: no st= ate across a reboot: 
 =
 =
3. Wes George= (operator) makes a comment that I2RS configuration should not replace curr= ent configuration related to BGP. 
 =
 =
There is the = Architecture Discussion 2: Persistence (ephemeral vs. permanent)=
 =
 =
Multiple clie= nts writing to agents (raised by Himanshu Shah)
 =
 =
Jeff (chair h= at off) states he does not want to have I2rs changing state tables come fro= m routing protocols (BGP--> I2RS state).  He also feel dynamic stat= e tables should be read-only, and not writable as suggested by the use case.
 =
 =
In the same t= hread, Sri states the I2RS agent should not provide an interface to change = a table if there is no use-case to support it.  Dynamic protocols --&g= t; I2RS (I2RS read only).  I2RS--> RIB-IM.   Sri states " I am yet to see a use-case that requires direct manipula= tion of a single dynamic routing-protocol-instance specific route table by = something other than that protocol. I don't believe there should be any suc= h case."    However, here it has been in the BGP use case.
 =
 =
Jeff responds= to Sri in tends to agree and does not mention the use case.
 =
 <= o:p>
Sue Har= es
 <= o:p>
-----Or= iginal Message-----
From: D= ean Bogdanovic [mailto:deanb@juni= per.net]
Sent: F= riday, June 06, 2014 4:03 PM
To: Sus= an Hares
Cc: t.p= etch; <i2rs@ietf.org>; Keyur Patel (keyupate); Hannes= Gredler; Russ White; Susan Hares; <rex@cisco.com>
Subject= : Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt=
 <= o:p>
Susan,<= o:p>
 <= o:p>
Many pe= ople don't know what NLRI abbreviation stands for (Network Layer Reachabili= ty Information , so writing it out first time would be a good idea.
 <= o:p>
Through= out the text, the requirement number sequence is confusing until you get to= the very and where all requirements are listed and then it makes sense.
 <= o:p>
REQ04: = The ability to interact with various policies configured on
 &= nbsp;    the forwarding devices, in order to inform the poli= cies
 &= nbsp;    implemented by the dynamic routing processes. = This interaction
 &= nbsp;    should be through existing configuration mechanisms= , such as
 &= nbsp;    NETCONF, and should be recorded in the configuratio= n of the local
 &= nbsp;    device so operators are aware of the full policy im= plemented in
 &= nbsp;    the network from the running configuration.
It is n= ot clear to me if your requirement is that dynamic protocols should impose = persistent policies? It says it should be recorded in the configuration of = the local device.
 <= o:p>
I agree= that those policies should be visible to operators and other applications,= but not sure if dynamic protocols should be allowed to implement persisten= t policies. IMO, those should be ephemeral policies.
So mayb= e text should look like this
This in= teraction should be through existing configuration mechanisms, such as NETC= ONF, and should be recorded in the running or ephemeral configuration of th= e local device so operators are aware of the full policy implemented in the network from the running configurati= on.
 <= o:p>
I'm try= ing to see major difference between REQ01/REQ02 and REQ08/REQ09?=
 <= o:p>
In gene= ral I'm not sure if changing entries by dynamic protocol in RIB is a good i= dea. If you plan to change only what is configured on the local device, the= n that is OK, but if you start changing entries that are pushed from other devices in the network, the system woul= d get unstable. And it looks to me that REQ09 would allow that.<= /span>
 <= o:p>
Dean
 <= o:p>
 <= o:p>
On Jun = 5, 2014, at 4:47 AM, Susan Hares <shares@ndzh.com> wrote:
 <= o:p>
> To= m:
> 
> I'= m glad to change the citation in the abstract.    On the aut= hors, this was
> me= rge of two drafts.
> 
> Su= e
> 
> --= ---Original Message-----
> Fr= om: t.petch [mailto:ietfc@btcon= nect.com]
> Se= nt: Thursday, June 05, 2014 4:35 AM
> Su= bject: Re: [i2rs] FW: I-D Action:
> dr= aft-keyupate-i2rs-bgp-usecases-02.txt
> 
> Su= e
> 
> Cu= rrently you have six authors which is too many for an RFC - someone's<= /o:p>
> go= t to go!   For me, this is not just an admin point - when comment= ing,
> I = like to have one or two names, no more, as the clear pen holders=
> wh= om I can expect to act.  Too often, with so many names, everyone<= /o:p>
> th= inks that someone else will do something and nothing happens, so, in
> al= l seriousness, I oppose adoption until you sort this out amongst yourselves= .
> 
> No= te too that you have a citation in the Abstract, again not allowed -
> th= is can be surprising difficult to get round but get round it you,
> on= e or more thereof, must.
> 
> To= m Petch
> 
> 
> --= --- Original Message -----
> Fr= om: "Susan Hares" < > To= : <i2rs@ietf.org>
> Cc= : "'Keyur Patel (keyupate)'" <keyupate@cisco.com>; "Hannes Gredler"
> &l= t;hannes@juniper.net>; "Russ White" <russw@riw.us>; "'Susan Hares'"
> &l= t;skh@ndzh.com>; &= lt;rex@cisco.com>=
> Se= nt: Wednesday, June 04, 2014 7:49 PM
> Su= bject: [i2rs] FW: I-D Action:
> dr= aft-keyupate-i2rs-bgp-usecases-02.txt
> 
> 
>>= ; Jeff and Ed:
>>= ; 
>>= ; This updated draft has all the changes that Keyur Patel promised and=
> up= dates
>>= ; to the reference the current i2rs internet drafts.
>>= ; 
>>= ; Would you please do a Working Group adoption call?
>>= ; 
>>= ; Thank you,
>>= ; Sue Hares
>>= ; 
>>= ; 
>>= ; -----Original Message-----
>>= ; From: i2rs [mailto:i2rs-bo= unces@ietf.org] On Behalf Of
>>= ; Sent: Wednesday, June 04, 2014 1:44 PM
>>= ; Cc: i2rs@ie= tf.org
>>= ; Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt<= /o:p>
>>= ; 
>>= ; 
>>= ; A New Internet-Draft is available from the on-line Internet-Drafts
>>= ; directories.
>>= ; This draft is a work item of the Interface to the Routing System
> Wo= rking
>>= ; Group of the IETF.
>>= ; 
>>= ;        Title    &n= bsp;      : Use Cases for an Interface to BGP Prot= ocol
>>= ;        Authors    =      : Keyur Patel
>>= ;            &n= bsp;            = ; Rex Fernando
>>= ;            &n= bsp;            = ; Hannes Gredler
>>= ;            &n= bsp;            = ; Shane Amante
>>= ;            &n= bsp;            = ; Russ White
>>= ;            &n= bsp;            = ; Susan Hares
>>= ; Filename        : draft-keyupate-i2rs-= bgp-usecases-02.txt
>>= ; Pages           : 17
>>= ; Date            : = 2014-06-04
>>= ; 
>>= ; Abstract:
>>= ;   A network routing protocol like BGP is typically configured a= nd
>>= ;   analyzed through some form of Command Line Interface (CLI) or=
>>= ;   NETCONF.  These interactions to control BGP and diagnose= its
>>= ;   operation encompass: configuration of protocol parameters, di= splay
> of=
>>= ;   protocol data, setting of certain protocol state and debuggin= g of
> th= e
>>= ;   protocol.
>>= ; 
>>= ;   Interface to the Routing System's (I2RS) Programmatic interfa= ces,
> as=
>>= ;   defined in draft-ietf-i2rs-architecture, provides an alternat= e way
> to=
>>= ;   control and diagnose the operation of the BGP protocol. = I2RS may
> be=
>>= ;   used for the configuration, manipulation, analyzing or collec= ting
> th= e
>>= ;   protocol data.  This document describes set of use cases= for which
>>= ;   I2RS can be used for BGP protocol.  It is intended to pr= ovide a
> ba= se
>>= ;   for the solution draft describing a set of interfaces to the = BGP
>>= ;   protocol.
>>= ; 
>>= ; 
>>= ; The IETF datatracker status page for this draft is:
>>= ; 
>>= ; There's also a htmlized version available at:
>>= ; 
>>= ; A diff from the previous version is available at:
>>= ; 
>>= ; 
>>= ; Please note that it may take a couple of minutes from the time of
> su= bmission
>>= ; 
>>= ; Internet-Drafts are also available by anonymous FTP at:=
>>= ; 
>>= ; _______________________________________________
>>= ; i2rs mailing list
>>= ; 
>>= ; _______________________________________________
>>= ; i2rs mailing list
>>= ; 
> 
> 
> __= _____________________________________________
> i2= rs mailing list
 <= o:p>
<= ;draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bgp-use= cases-03.txt.pdf>
 

--_000_F09CEB8D4FBB463D97EB96BB2A0C773Djunipernet_-- From nobody Sun Jun 15 06:06:22 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009D81B28FD for ; Sun, 15 Jun 2014 06:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY6hG4t5VP06 for ; Sun, 15 Jun 2014 06:06:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C441B28FC for ; Sun, 15 Jun 2014 06:06:18 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sun, 15 Jun 2014 13:06:09 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) with mapi id 15.00.0954.000; Sun, 15 Jun 2014 13:06:09 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Thread-Index: Ac+GjQkiVWQpH0dxQVWc/MElqtTQqgAcSyRDAAKEgoAAZJNrgA== Date: Sun, 15 Jun 2014 13:06:08 +0000 Message-ID: References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> In-Reply-To: <055f01cf8708$49597000$dc0c5000$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(377454003)(52044002)(51404002)(189002)(199002)(24454002)(83716003)(66066001)(20776003)(33656002)(85852003)(80022001)(74502001)(74662001)(76482001)(36756003)(77156001)(64706001)(46102001)(50226001)(77096002)(77982001)(104166001)(57306001)(105586001)(76176999)(99396002)(31966008)(21056001)(62966002)(4396001)(82746002)(79102001)(2656002)(19580395003)(50986999)(81342001)(93916002)(88136002)(15975445006)(86362001)(19580405001)(99286001)(87936001)(89996001)(81542001)(92726001)(101416001)(87286001)(83322001)(92566001)(85306003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/XzoNwsmC3UhtgRuPYc-vO1dzTJk Cc: Jeffrey Haas , "" , Russ White , Edward Crabbe , "t.petch" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 13:06:21 -0000 Susan, I like the new format much better. It makes the reading more clear from beg= inning. I disagree with REQ10. REQ10 implies that the i2rs will store data = in persistent storage.=20 I have another use case for the draft, mobile backhaul. Currently governmen= ts are preparing to release some new spectrum bands for public usage. It wi= ll be a very different approach, as the lease period will be significantly = reduced from 15 years to hours. Idea is to use small cells with this new sp= ectrum to respond to increasing demand from mobile users in that geographic= al area, like a sports, music venue or certain city areas that get very pop= ulated during certain peak hours. In such cases, mobile backhaul has to be = able to respond to such increase in demand and that will require changing o= f forwarding policies in the backhaul. I2RS is a very good match for that t= ask and following requirements should be listed: REQ01, REQ02, REQ07, REQ08= , REQ09. Dean On Jun 13, 2014, at 9:06 AM, "Russ White" wrote: >=20 >> I note the reference to ISIS which I find significant. My experience is > more of >> OSPF but appreciate that that is rare with Operators. However, both are > Link >> State and so very different to BGP which makes me think about the use of >> RIB. The NETMOD routing-cfg started with RIBs, dropped them and then >> reinstated them (after consulting with I2RS), whereas for me, RIBs are B= GP >> (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is ver= y >> different in detail (as much research as Lada has done across three > differing >> platforms, I am not certain that the NETMOD has sufficient routing > expertise >> to get this perfect:-(. >=20 > There are two different "RIBs," at least in theory -- vendor implementati= ons > may vary. To try and separate things out, let's describe a few tables, se= e > if that's a complete description, and then try to name these things. >=20 > - There is the set of all the reachability information received by any gi= ven > process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or > IS-IS. >=20 > - There is the set of best paths determined by the particular process. I > would correlate this to the SPT in OSPF or IS-IS, and the BGP best path > table. >=20 > - There is the set of paths actually installed in the local device memory= , > and off of which the local forwarding tables are built. Each process runn= ing > on the device installs reachability information into this table, and ther= e > is some arbitration method within each implementation designed to determi= ne > which process "wins," when there are multiple installs for the same > destination, as well as "callbacks" for when routes are removed, and even > perhaps "backup routes," and the like. >=20 > - There is the set of forwarding table entries actually used for forwardi= ng > traffic. Note there may be two layers of these, but they typically includ= e > mac header rewrites, tunnel headers, and the like -- none of which any of > the "ribs" described above would contain (they would only contain a next > hop, not the actual rewrite information). >=20 > If there are any I've missed, please feel free to add them in. This draft= is > supposed to be addressing use cases that are centered on the third one ab= ove > in a "generic" way (not specific to some routing protocol, etc.). >=20 >> REQ1 last sentence should probably include removing process >=20 > I'm fine with including this, but I can't think of a use case off the top= of > my head...=20 >=20 >> REQ2 I think is about source-based routing but it does not quite say tha= t, >> rather reading as if source or destination routing were equally valid > options >=20 > It intends to say that both source and destination routing are equally va= lid > options from the perspective of installed stuff into the RIB (#3 above). >=20 >> REQ3 again the wording seems odd - I think you mean that traffic with a > given >> destination (or source?) prefix should be discarded, but that is not wha= t > it >> says >=20 > This is akin to remote triggered black holes -- a route to interface null= 0, > which can be targeted either through the source (source routing) or the > destination. >=20 >> REQ4 I find vague, as I do anything with the word policy in it:-( > Something >> concrete (communities, MED, ...) would help >=20 > This isn't really MED (that would fall into the BGP use cases draft), but > rather mostly focused on setting the next hop, backup routes, source rout= es, > and other places where you might forward based on things like port number= s, > etc. >=20 >> REQ6 makes me wonder what is a RIB when it is not local >=20 > I suppose it could be remote in some way. Think of the RIB of a virtual > router that then installs routes using OpenFlow into a remote switch -- i= s > the RIB remote, or the FIB? I don't really know... I guess it might make > more sense just to take the word "local" out here. >=20 >> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like somethi= ng >> more concrete. Again, I wonder if it is technically possible to present >> information in a consistent manner given the difference in underlying >> concepts of protocols. >=20 > This is actually restricted to the RIB (#3 above) by the context of the > draft, but it might be useful to add some restrictive language here. >=20 >> REQ9 - again all embracing and as such, probably impossible, at least as >> written. Limiting it just to BGP and a link-state protocol, again that > seems >> challenging. >=20 > Again, this is implied to be restricted to the RIB (#3 above) by the cont= ext > of the draft. Adding some restrictive language here might be useful, or i= t > might be overkill (your choice :-) ). >=20 >> REQ10 - policies again, and it is unclear who is doing the time > management. >> Some configuration protocols do have timer-based facilities, but not >> NETCONF; do you mean here that I2RS must have functionality based on >> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and > Japan?) >=20 > Time based processing here generally means, "last route installed wins, > given all equal preferences otherwise," or perhaps, "time is the > tiebreaker." This area might need work, as this makes the final state > non-atomic (order dependent). The problem is there's no way to ensure > everyone is using different preference levels, etc. Any thoughts here > welcome. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Jun 15 13:52:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B911B293F for ; Sun, 15 Jun 2014 13:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TykyA-C97g5Y for ; Sun, 15 Jun 2014 13:52:23 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4671B2879 for ; Sun, 15 Jun 2014 13:52:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> In-Reply-To: Date: Sun, 15 Jun 2014 16:52:09 -0400 Message-ID: <001501cf88db$ad661ec0$08325c40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAX03oZkCj15W6pltzqUA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/D1FK0COm23J6kJ7pUrpzBGKovbw Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Russ White' , 'Edward Crabbe' , "'t.petch'" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:52:25 -0000 Dean: Please look at the http://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/ It provides the mobile backhaul use case. If you want to suggest changes, I'm a co-author. Sue -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Sunday, June 15, 2014 9:06 AM To: Susan Hares Cc: t.petch; ; Jeffrey Haas; Edward Crabbe; Russ White Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Susan, I like the new format much better. It makes the reading more clear from beginning. I disagree with REQ10. REQ10 implies that the i2rs will store data in persistent storage. I have another use case for the draft, mobile backhaul. Currently governments are preparing to release some new spectrum bands for public usage. It will be a very different approach, as the lease period will be significantly reduced from 15 years to hours. Idea is to use small cells with this new spectrum to respond to increasing demand from mobile users in that geographical area, like a sports, music venue or certain city areas that get very populated during certain peak hours. In such cases, mobile backhaul has to be able to respond to such increase in demand and that will require changing of forwarding policies in the backhaul. I2RS is a very good match for that task and following requirements should be listed: REQ01, REQ02, REQ07, REQ08, REQ09. Dean On Jun 13, 2014, at 9:06 AM, "Russ White" wrote: > >> I note the reference to ISIS which I find significant. My experience >> is > more of >> OSPF but appreciate that that is rare with Operators. However, both >> are > Link >> State and so very different to BGP which makes me think about the use >> of RIB. The NETMOD routing-cfg started with RIBs, dropped them and >> then reinstated them (after consulting with I2RS), whereas for me, >> RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in >> LSDB, which is very different in detail (as much research as Lada has >> done across three > differing >> platforms, I am not certain that the NETMOD has sufficient routing > expertise >> to get this perfect:-(. > > There are two different "RIBs," at least in theory -- vendor > implementations may vary. To try and separate things out, let's > describe a few tables, see if that's a complete description, and then try to name these things. > > - There is the set of all the reachability information received by any > given process. I would correlate this to the BGP-RIB-IN, or the LSDB > in OSPF or IS-IS. > > - There is the set of best paths determined by the particular process. > I would correlate this to the SPT in OSPF or IS-IS, and the BGP best > path table. > > - There is the set of paths actually installed in the local device > memory, and off of which the local forwarding tables are built. Each > process running on the device installs reachability information into > this table, and there is some arbitration method within each > implementation designed to determine which process "wins," when there > are multiple installs for the same destination, as well as "callbacks" > for when routes are removed, and even perhaps "backup routes," and the like. > > - There is the set of forwarding table entries actually used for > forwarding traffic. Note there may be two layers of these, but they > typically include mac header rewrites, tunnel headers, and the like -- > none of which any of the "ribs" described above would contain (they > would only contain a next hop, not the actual rewrite information). > > If there are any I've missed, please feel free to add them in. This > draft is supposed to be addressing use cases that are centered on the > third one above in a "generic" way (not specific to some routing protocol, etc.). > >> REQ1 last sentence should probably include removing process > > I'm fine with including this, but I can't think of a use case off the > top of my head... > >> REQ2 I think is about source-based routing but it does not quite say >> that, rather reading as if source or destination routing were equally >> valid > options > > It intends to say that both source and destination routing are equally > valid options from the perspective of installed stuff into the RIB (#3 above). > >> REQ3 again the wording seems odd - I think you mean that traffic with >> a > given >> destination (or source?) prefix should be discarded, but that is not >> what > it >> says > > This is akin to remote triggered black holes -- a route to interface > null0, which can be targeted either through the source (source > routing) or the destination. > >> REQ4 I find vague, as I do anything with the word policy in it:-( > Something >> concrete (communities, MED, ...) would help > > This isn't really MED (that would fall into the BGP use cases draft), > but rather mostly focused on setting the next hop, backup routes, > source routes, and other places where you might forward based on > things like port numbers, etc. > >> REQ6 makes me wonder what is a RIB when it is not local > > I suppose it could be remote in some way. Think of the RIB of a > virtual router that then installs routes using OpenFlow into a remote > switch -- is the RIB remote, or the FIB? I don't really know... I > guess it might make more sense just to take the word "local" out here. > >> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like >> something more concrete. Again, I wonder if it is technically >> possible to present information in a consistent manner given the >> difference in underlying concepts of protocols. > > This is actually restricted to the RIB (#3 above) by the context of > the draft, but it might be useful to add some restrictive language here. > >> REQ9 - again all embracing and as such, probably impossible, at least >> as written. Limiting it just to BGP and a link-state protocol, again >> that > seems >> challenging. > > Again, this is implied to be restricted to the RIB (#3 above) by the > context of the draft. Adding some restrictive language here might be > useful, or it might be overkill (your choice :-) ). > >> REQ10 - policies again, and it is unclear who is doing the time > management. >> Some configuration protocols do have timer-based facilities, but not >> NETCONF; do you mean here that I2RS must have functionality based on >> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and > Japan?) > > Time based processing here generally means, "last route installed > wins, given all equal preferences otherwise," or perhaps, "time is the > tiebreaker." This area might need work, as this makes the final state > non-atomic (order dependent). The problem is there's no way to ensure > everyone is using different preference levels, etc. Any thoughts here > welcome. > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 16 10:41:44 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2185B1A0139 for ; Mon, 16 Jun 2014 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI3mdiktjSoJ for ; Mon, 16 Jun 2014 10:41:13 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED171A00DA for ; Mon, 16 Jun 2014 10:41:12 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id 83c2f935.2ba857e52940.4043178.00-2471.10332517.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 16 Jun 2014 17:41:12 +0000 (UTC) X-MXL-Hash: 539f2c387340fb39-d9f408d963c098b998b217ec0b87e5ed8cf4a2f8 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id b2c2f935.0.4043023.00-2334.10332123.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 16 Jun 2014 17:41:02 +0000 (UTC) X-MXL-Hash: 539f2c2e601cdcee-e5526b082f9d9287209b65b322baa6076131c240 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5GHewNO024367; Mon, 16 Jun 2014 13:40:59 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5GHej6e024122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 13:40:54 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (MISOUT7MSGHUB9E.itservices.sbc.com [144.151.223.61]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 16 Jun 2014 17:40:29 GMT Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.4]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.03.0174.001; Mon, 16 Jun 2014 13:40:29 -0400 From: "UTTARO, JAMES" To: "'Dean Bogdanovic'" , "'Susan Hares'" Thread-Topic: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Thread-Index: Ac+GjQkiVWQpH0dxQVWc/MElqtTQqgAcSyRDAAKEgoAAZJNrgAA38yoA Date: Mon, 16 Jun 2014 17:40:29 +0000 Message-ID: References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=WZIhCSci5ecA:10 a=ofMgfj31e3cA:10 a=lB4lNuC3LbQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=VZ-CQN67oZaW7gJobXwA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=EJ_lzN1bkxcA:10 a=JxscI1F778J] X-AnalysisOut: [MrRH6:21 a=Em8AOnBlHiP2jYOj:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/l9R5WPKWBhmZ1bQL4QUC8Tud3-w Cc: 'Jeffrey Haas' , "''" , 'Russ White' , 'Edward Crabbe' , "'t.petch'" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 17:41:40 -0000 Susan, Following find my comments in re this document.. General Comments. 1) There is a need to better define what is meant by the "halfway point" b= etween completely replacing the distributed control plane and configuring i= t all. It would seem to be that this "halfway point" is different based on = what is being programmed. To that end it would be useful to call out higher= level reqs some suggestions. 2) Dissemination Scope of an I2RS Instruction Set ( Block of instructions = intended to be atomic ) - An instruction set may be local or global in natu= re as it pertains to affected the distributed control plane when configured= on a network element. a) A locally scoped instruction set may configure routing state in the R= IB for comparison purposes but that state may not be disseminated via the d= istributed control plane.=20 b) A globally scoped instruction set must configure routing state in the = RIB for comparison purposes and that state is available for dissemination s= ubject to any other policy. 3) Ephemeral/Persistent Scope of an I2RS Instruction Set a) Should the instruction set persist? What comes to mind for me are the = "configuration" like changes i.e RT-C, FlowSpec .=20 4) Liveness/Safety Properties - Would like to see some discussion in re th= ese items. 5) Uses Cases - I believe addl use cases whose focus is on configuration l= ike services would be desirable. As an ex.. RT-C.. Specific Comments=20 C1 - P1 - Para 2 ..." Such a system would not interact...." The paragraph uses a routing an= d best path selection as an example. I assume that this not limited to this= application but spans configuration like state etc.... C2 - P3 -Para 1 "This represents a "halfway point" ..." This needs a clearer definition, I= would suggest wording regarding how the distributed control plane will be= augmented by the addition of I2RS C3 - P3 - Para 3=20 "...Each unique has been" Typo missing the word reqs. C4 - P3 - Para 5 The reaction to Network Based Attacks may also include other actions i.e m= irror, drop ...I assume you are not limiting the response to the attack to = only re-direct. C5 - P4 - Para 4 1st Bullet Can the I2RS agent interact with other tools and get the desired info in t= his case available routes in the RIB? In general can I2RS provide a framewo= rk to collect data from multiple sources including directly from a router, = RR, NM? C6 - P4 - Para 4 2nd Bullet Need to describe in how state learned via I2RS agent and state learned via= distributed control plane interact across the set of applications ( See Ab= ove General Comments. ) C7 - P5 - Para 4 3rd Bullet What is the ask for here? Is there a consistent definition of /dev/null be= ing sought? C8 - P5 -Para 4 4th Bullet Not sure what this req is. Is it saying the policies configured via distri= buted control plane, local and/or via I2Rs should have some form of id? Wh= y is this needed if the policy no matter where it is learned is recorded in= the running configuration?? C10 - P5 - Para `1 "In hub and spoke..." There are other hub/spoke solutions i.e Virtual Hub = Rekhter et al...that do not rely on a centralized server. =09 Jim Uttaro =09 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Sunday, June 15, 2014 9:06 AM To: Susan Hares Cc: Jeffrey Haas; ; Russ White; Edward Crabbe; t.petch Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Susan, I like the new format much better. It makes the reading more clear from beg= inning. I disagree with REQ10. REQ10 implies that the i2rs will store data = in persistent storage.=20 I have another use case for the draft, mobile backhaul. Currently governmen= ts are preparing to release some new spectrum bands for public usage. It wi= ll be a very different approach, as the lease period will be significantly = reduced from 15 years to hours. Idea is to use small cells with this new sp= ectrum to respond to increasing demand from mobile users in that geographic= al area, like a sports, music venue or certain city areas that get very pop= ulated during certain peak hours. In such cases, mobile backhaul has to be = able to respond to such increase in demand and that will require changing o= f forwarding policies in the backhaul. I2RS is a very good match for that t= ask and following requirements should be listed: REQ01, REQ02, REQ07, REQ08= , REQ09. Dean On Jun 13, 2014, at 9:06 AM, "Russ White" wrote: >=20 >> I note the reference to ISIS which I find significant. My experience is > more of >> OSPF but appreciate that that is rare with Operators. However, both are > Link >> State and so very different to BGP which makes me think about the use of >> RIB. The NETMOD routing-cfg started with RIBs, dropped them and then >> reinstated them (after consulting with I2RS), whereas for me, RIBs are B= GP >> (as defined in RFC4271) and OSPF has an equivalent in LSDB, which is ver= y >> different in detail (as much research as Lada has done across three > differing >> platforms, I am not certain that the NETMOD has sufficient routing > expertise >> to get this perfect:-(. >=20 > There are two different "RIBs," at least in theory -- vendor implementati= ons > may vary. To try and separate things out, let's describe a few tables, se= e > if that's a complete description, and then try to name these things. >=20 > - There is the set of all the reachability information received by any gi= ven > process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or > IS-IS. >=20 > - There is the set of best paths determined by the particular process. I > would correlate this to the SPT in OSPF or IS-IS, and the BGP best path > table. >=20 > - There is the set of paths actually installed in the local device memory= , > and off of which the local forwarding tables are built. Each process runn= ing > on the device installs reachability information into this table, and ther= e > is some arbitration method within each implementation designed to determi= ne > which process "wins," when there are multiple installs for the same > destination, as well as "callbacks" for when routes are removed, and even > perhaps "backup routes," and the like. >=20 > - There is the set of forwarding table entries actually used for forwardi= ng > traffic. Note there may be two layers of these, but they typically includ= e > mac header rewrites, tunnel headers, and the like -- none of which any of > the "ribs" described above would contain (they would only contain a next > hop, not the actual rewrite information). >=20 > If there are any I've missed, please feel free to add them in. This draft= is > supposed to be addressing use cases that are centered on the third one ab= ove > in a "generic" way (not specific to some routing protocol, etc.). >=20 >> REQ1 last sentence should probably include removing process >=20 > I'm fine with including this, but I can't think of a use case off the top= of > my head...=20 >=20 >> REQ2 I think is about source-based routing but it does not quite say tha= t, >> rather reading as if source or destination routing were equally valid > options >=20 > It intends to say that both source and destination routing are equally va= lid > options from the perspective of installed stuff into the RIB (#3 above). >=20 >> REQ3 again the wording seems odd - I think you mean that traffic with a > given >> destination (or source?) prefix should be discarded, but that is not wha= t > it >> says >=20 > This is akin to remote triggered black holes -- a route to interface null= 0, > which can be targeted either through the source (source routing) or the > destination. >=20 >> REQ4 I find vague, as I do anything with the word policy in it:-( > Something >> concrete (communities, MED, ...) would help >=20 > This isn't really MED (that would fall into the BGP use cases draft), but > rather mostly focused on setting the next hop, backup routes, source rout= es, > and other places where you might forward based on things like port number= s, > etc. >=20 >> REQ6 makes me wonder what is a RIB when it is not local >=20 > I suppose it could be remote in some way. Think of the RIB of a virtual > router that then installs routes using OpenFlow into a remote switch -- i= s > the RIB remote, or the FIB? I don't really know... I guess it might make > more sense just to take the word "local" out here. >=20 >> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like somethi= ng >> more concrete. Again, I wonder if it is technically possible to present >> information in a consistent manner given the difference in underlying >> concepts of protocols. >=20 > This is actually restricted to the RIB (#3 above) by the context of the > draft, but it might be useful to add some restrictive language here. >=20 >> REQ9 - again all embracing and as such, probably impossible, at least as >> written. Limiting it just to BGP and a link-state protocol, again that > seems >> challenging. >=20 > Again, this is implied to be restricted to the RIB (#3 above) by the cont= ext > of the draft. Adding some restrictive language here might be useful, or i= t > might be overkill (your choice :-) ). >=20 >> REQ10 - policies again, and it is unclear who is doing the time > management. >> Some configuration protocols do have timer-based facilities, but not >> NETCONF; do you mean here that I2RS must have functionality based on >> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and > Japan?) >=20 > Time based processing here generally means, "last route installed wins, > given all equal preferences otherwise," or perhaps, "time is the > tiebreaker." This area might need work, as this makes the final state > non-atomic (order dependent). The problem is there's no way to ensure > everyone is using different preference levels, etc. Any thoughts here > welcome. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 17 01:58:34 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FABB1A0327 for ; Tue, 17 Jun 2014 01:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuSLvi8-Cz90 for ; Tue, 17 Jun 2014 01:58:30 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780AF1A02C2 for ; Tue, 17 Jun 2014 01:58:30 -0700 (PDT) Received: from DBXPRD0610HT002.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 08:58:27 +0000 Message-ID: <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> Date: Tue, 17 Jun 2014 09:55:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DBXPR07CA016.eurprd07.prod.outlook.com (10.141.8.174) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(189002)(24454002)(51414003)(13464003)(199002)(54094003)(377454003)(50466002)(81816999)(46102001)(23756003)(81686999)(76176999)(50986999)(19580395003)(19580405001)(83322001)(88136002)(62966002)(21056001)(87976001)(15975445006)(74502001)(84392001)(95666004)(79102001)(62236002)(92566001)(92726001)(44716002)(77982001)(66066001)(80022001)(83072002)(85852003)(102836001)(99396002)(81542001)(89996001)(575784001)(86362001)(81342001)(76482001)(104166001)(64706001)(33646001)(93916002)(20776003)(47776003)(15202345003)(4396001)(105586001)(50226001)(42186005)(31966008)(74662001)(44736004)(61296003)(101416001)(14496001)(77096002)(87286001)(85306003)(77156001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT002.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gBxsmD23G-wRRZ-u3ujnlEV56QI Cc: Jeffrey Haas , i2rs@ietf.org, Edward Crabbe , Susan Hares Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 08:58:33 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" Sent: Friday, June 13, 2014 1:11 PM > > On 13 Jun 2014, at 13:49, t.petch wrote: > > ---- Original Message ----- > > From: "Susan Hares" > Sent: Thursday, June 12, 2014 11:26 PM > > > >> I've posted a version of white-i2rs-use-case-05 with the > > recommendations at the front of the document. I look forward to > > additional comments. I appreciate Tom Petch and Dean B.'s comments on > > these drafts. > > > > Sue > > > > I am flattered; I am not sure that I deserve such mention. > > > > I am more interested in the use cases part of the I-D, seeing > > requirements and info-model as the next stage when use cases are agreed, > > and they look fine (perhaps /may Data Centers/many Data Centers/). > > > > I note the reference to ISIS which I find significant. My experience is > > more of OSPF but appreciate that that is rare with Operators. However, > > both are Link State and so very different to BGP which makes me think > > about the use of RIB. The NETMOD routing-cfg started with RIBs, dropped > > them and then reinstated them (after consulting with I2RS), whereas for > > me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in > > LSDB, which is very different in detail (as much research as Lada has > > done across three differing platforms, I am not certain that the NETMOD > > has sufficient routing expertise to get this perfect:-(. > > > > I think you need a definition of RIB, perhaps by a Normative reference > > to rib-info-model, but for me that leaves unclear the relationship > > between routing instance, routing protocol and RIB, at least when you > > get into requirements. > > Sounds like recurring deja vu: > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html or, once again with feeling, http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html Tom Petch > > Lada > > > > > Likewise, this I-D is cast in terms of a table identifier and a route > > process identifier, whereas routing-cfg has routing-instance [name] > > with router-id, ribs, interfaces, routing-protocols etc I have a sense > > of two divergent models of what a router is for all the discussions. > > > > REQ1 last sentence should probably include removing process > > > > REQ2 I think is about source-based routing but it does not quite say > > that, rather reading as if source or destination routing were equally > > valid options > > > > REQ3 again the wording seems odd - I think you mean that traffic with a > > given destination (or source?) prefix should be discarded, but that is > > not what it says > > > > REQ4 I find vague, as I do anything with the word policy in it:-( > > Something concrete (communities, MED, ...) would help > > > > REQ6 makes me wonder what is a RIB when it is not local > > > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > > something more concrete. Again, I wonder if it is technically possible > > to present information in a consistent manner given the difference in > > underlying concepts of protocols. > > > > REQ9 - again all embracing and as such, probably impossible, at least as > > written. Limiting it just to BGP and a link-state protocol, again that > > seems challenging. > > > > REQ10 - policies again, and it is unclear who is doing the time > > management. Some configuration protocols do have timer-based > > facilities, but not NETCONF; do you mean here that I2RS must have > > functionality based on timers (e.g. between 08:00 and 17:00 EDT, route > > this via Europe and Japan?) > > > > Tom Petch > > > >> > >> URL: > > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > >> > >> Sue Hares > >> > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Jun 17 02:29:38 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2301A0340 for ; Tue, 17 Jun 2014 02:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2dyA5YKz-k2 for ; Tue, 17 Jun 2014 02:29:33 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7038A1A033C for ; Tue, 17 Jun 2014 02:29:33 -0700 (PDT) Received: from DBXPRD0610HT001.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 09:29:31 +0000 Message-ID: <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> From: t.petch To: Russ White , 'Susan Hares' , References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> Date: Tue, 17 Jun 2014 10:11:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB3PR07CA008.eurprd07.prod.outlook.com (10.242.134.48) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(979002)(6009001)(428001)(51704005)(52044002)(189002)(13464003)(199002)(377454003)(51444003)(50466002)(81816999)(46102001)(23756003)(81686999)(76176999)(50986999)(19580405001)(19580395003)(83322001)(88136002)(21056001)(87976001)(62966002)(74502001)(84392001)(95666004)(79102001)(62236002)(92566001)(92726001)(44716002)(77982001)(66066001)(80022001)(83072002)(85852003)(102836001)(99396002)(89996001)(81542001)(86362001)(81342001)(76482001)(104166001)(64706001)(33646001)(93916002)(20776003)(47776003)(4396001)(105586001)(50226001)(42186005)(31966008)(74662001)(44736004)(61296003)(101416001)(14496001)(77096002)(87286001)(85306003)(77156001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT001.eurprd06.prod.outlook.com; FPR:; MLV:ovr; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/lMs1FVLOVcWG3SoEhY-pHA8zPos Cc: 'Jeffrey Haas' , 'Edward Crabbe' Subject: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:29:35 -0000 ----- Original Message ----- From: "Russ White" Sent: Friday, June 13, 2014 2:06 PM > > There are two different "RIBs," at least in theory -- vendor implementations > may vary. To try and separate things out, let's describe a few tables, see > if that's a complete description, and then try to name these things. > > A - There is the set of all the reachability information received by any given > process. I would correlate this to the BGP-RIB-IN, or the LSDB in OSPF or > IS-IS. > > B - There is the set of best paths determined by the particular process. I > would correlate this to the SPT in OSPF or IS-IS, and the BGP best path > table. > > C - There is the set of paths actually installed in the local device memory, > and off of which the local forwarding tables are built. Each process running > on the device installs reachability information into this table, and there > is some arbitration method within each implementation designed to determine > which process "wins," when there are multiple installs for the same > destination, as well as "callbacks" for when routes are removed, and even > perhaps "backup routes," and the like. > > D - There is the set of forwarding table entries actually used for forwarding > traffic. Note there may be two layers of these, but they typically include > mac header rewrites, tunnel headers, and the like -- none of which any of > the "ribs" described above would contain (they would only contain a next > hop, not the actual rewrite information). > > If there are any I've missed, please feel free to add them in. This draft is > supposed to be addressing use cases that are centered on the third one above > in a "generic" way (not specific to some routing protocol, etc.). Looks comprehensive. D may vary, but I think that it is outside the remit of I2RS. It is B that I am doubtful about. It is fine for BGP or RIP, but I do not see it for link state protocols, that is for me, the SPT is not a table of routes, backup routes and so on but, well shortest paths. Do you see an IS-IS, or OSPF, table comparable to the BGP table? Tom Petch From nobody Tue Jun 17 02:29:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A571A033C for ; Tue, 17 Jun 2014 02:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmnzFwk9upng for ; Tue, 17 Jun 2014 02:29:34 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C06F1A033E for ; Tue, 17 Jun 2014 02:29:34 -0700 (PDT) Received: from DBXPRD0610HT001.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 09:29:31 +0000 Message-ID: <01f901cf8a0e$33426c00$4001a8c0@gateway.2wire.net> From: t.petch To: Russ White , 'Susan Hares' , References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> Date: Tue, 17 Jun 2014 10:25:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB3PR07CA008.eurprd07.prod.outlook.com (10.242.134.48) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(189002)(13464003)(199002)(51404002)(54094003)(377454003)(51444003)(50466002)(81816999)(46102001)(23756003)(81686999)(76176999)(50986999)(19580405001)(19580395003)(83322001)(88136002)(21056001)(87976001)(62966002)(74502001)(84392001)(95666004)(79102001)(62236002)(92566001)(92726001)(44716002)(77982001)(66066001)(80022001)(83072002)(85852003)(102836001)(99396002)(89996001)(81542001)(86362001)(81342001)(76482001)(104166001)(64706001)(33646001)(93916002)(20776003)(47776003)(4396001)(105586001)(50226001)(42186005)(31966008)(74662001)(44736004)(61296003)(101416001)(14496001)(77096002)(87286001)(85306003)(77156001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT001.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/NAUa8-SpAqSRbOnSaf8HfEcDN2E Cc: 'Jeffrey Haas' , 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:29:36 -0000 Part two, on the specific Q. Tom Petch ----- Original Message ----- From: "Russ White" Sent: Friday, June 13, 2014 2:06 PM > > REQ1 last sentence should probably include removing process > > I'm fine with including this, but I can't think of a use case off the top of > my head... Nor can I , but the first sentence talks of instal and remove, the last sentence only of instal; I would like the two to be in line. > > REQ2 I think is about source-based routing but it does not quite say that, > > rather reading as if source or destination routing were equally valid > options > > It intends to say that both source and destination routing are equally valid > options from the perspective of installed stuff into the RIB (#3 above). I would reword it to say "source based routes, and destination based routes" (unless you mean 'source-and-destination based routes') > > REQ3 again the wording seems odd - I think you mean that traffic with a > given > > destination (or source?) prefix should be discarded, but that is not what > it > > says > > This is akin to remote triggered black holes -- a route to interface null0, > which can be targeted either through the source (source routing) or the > destination. Again, it is a matter of wording, I am guessing that what you mean is "The ability to install a route for a given prefix to a null destination ...." > > REQ4 I find vague, as I do anything with the word policy in it:-( > Something > > concrete (communities, MED, ...) would help > > This isn't really MED (that would fall into the BGP use cases draft), but > rather mostly focused on setting the next hop, backup routes, source routes, > and other places where you might forward based on things like port numbers, > etc. OK, I did not really think MED but wanted something concrete:-) Again, adding a few words makes such a difference, such as "The ability to interact with various policies configured on the forwarding devices, such as by changing the next hop, backup routes and such like, ...." > > REQ6 makes me wonder what is a RIB when it is not local > > I suppose it could be remote in some way. Think of the RIB of a virtual > router that then installs routes using OpenFlow into a remote switch -- is > the RIB remote, or the FIB? I don't really know... I guess it might make > more sense just to take the word "local" out here. Yes, WFM > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like something > > more concrete. Again, I wonder if it is technically possible to present > > information in a consistent manner given the difference in underlying > > concepts of protocols. > > This is actually restricted to the RIB (#3 above) by the context of the > draft, but it might be useful to add some restrictive language here. Yes please - I think that when you move from the context of a discussion of a specific revision of a specific I-D on a WG mailing list to a published I-D, then what was clear may become too vague to convey the intended meaning > > > REQ9 - again all embracing and as such, probably impossible, at least as > > written. Limiting it just to BGP and a link-state protocol, again that > seems > > challenging. > > Again, this is implied to be restricted to the RIB (#3 above) by the context > of the draft. Adding some restrictive language here might be useful, or it > might be overkill (your choice :-) ). > > > REQ10 - policies again, and it is unclear who is doing the time > management. > > Some configuration protocols do have timer-based facilities, but not > > NETCONF; do you mean here that I2RS must have functionality based on > > timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and > Japan?) > > Time based processing here generally means, "last route installed wins, > given all equal preferences otherwise," or perhaps, "time is the > tiebreaker." This area might need work, as this makes the final state > non-atomic (order dependent). The problem is there's no way to ensure > everyone is using different preference levels, etc. Any thoughts here > welcome. Tom Petch > > :-) > > Russ > From nobody Tue Jun 17 02:39:17 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018FD1A033C for ; Tue, 17 Jun 2014 02:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3forwvXY4Ajv for ; Tue, 17 Jun 2014 02:39:13 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0076.outbound.protection.outlook.com [213.199.154.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75AF31A0337 for ; Tue, 17 Jun 2014 02:39:12 -0700 (PDT) Received: from DBXPRD0610HT002.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 17 Jun 2014 09:39:09 +0000 Message-ID: <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> From: t.petch To: Dean Bogdanovic , Susan Hares References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> Date: Tue, 17 Jun 2014 10:35:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AM3PR07CA006.eurprd07.prod.outlook.com (10.242.16.46) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(199002)(189002)(24454002)(377454003)(377424004)(51704005)(31966008)(74662001)(42186005)(50226001)(105586001)(64706001)(104166001)(33646001)(81342001)(86362001)(4396001)(93916002)(20776003)(15202345003)(47776003)(101416001)(14496001)(61296003)(85306003)(77156001)(77096002)(87286001)(44736004)(93886003)(74502001)(15975445006)(87976001)(62966002)(21056001)(95666004)(50466002)(81816999)(46102001)(19580405001)(19580395003)(83322001)(1941001)(50986999)(88136002)(81686999)(76176999)(83072002)(80022001)(66066001)(77982001)(81542001)(89996001)(85852003)(99396002)(102836001)(44716002)(92726001)(79102001)(23746002)(62236002)(92566001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB050; H:DBXPRD0610HT002.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ghVaOrkAhNmmZfQV-0H-1P2goIg Cc: i2rs@ietf.org, Susan Hares , rex@cisco.com, "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 09:39:16 -0000 ----- Original Message ----- From: "Dean Bogdanovic" To: "Susan Hares" Sent: Friday, June 13, 2014 11:06 PM Susan, My answer to your question do we ever let I2RS upon a command transfer policies to the persistent storage? My initial answer is no. And reason is security. Network admins want to know exact state of the device after rebooting. If we want to allow transfer of policies, then we would have to define roles and which roles would be allowed to do that transfer. We are making things more complex, when there are existing mechanisms for admins to do that. The counter argument to this is having got it right once, for some, perhaps large, instantiation of an I2RS it, do you want to have to do it all over again? That is, I agree that after reboot, an operator should know that the box is in the state defined by the NETCONF startup configuration datastore with nothing added but that there may be a valid case for saying that all the changes downloaded by I2RS remain stored, but not applied, eg in a candidate I2RS datastore, which can then be copied to the running I2RS datastore when the operator is satisfied that the time is right. Just a thought. Tom Petch Dean On Jun 13, 2014, at 5:49 PM, Susan Hares > wrote: Dean: Thank you for your thoughtful answer. I was looking for it, but I’m glad you watched Croatia (I’m sorry about Croatia’s loss). I agree with the types of policies and the status: persistent, transient, and ephemeral. However, do we ever let I2RS upon a command transfer policies to the persistent storage? This what I read in REQ04. In reading the email, I’m not sure how to summarize the WG’s approach. My answer would be “no”, but if this is a WG document the answer needs to come from the WG. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Dean Bogdanovic Sent: Friday, June 13, 2014 2:44 PM To: Susan Hares Cc: >; Susan Hares; >; t.petch; Keyur Patel (keyupate); Hannes Gredler; Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Sorry for late reply, but yesterday started a very significant quadrennial event (FIFA World Cup) and Croatia played (and lost with help of the referee). WRT REQ04, I agree with the posts and here are few thoughts on this We should try to divide policies into few categories. 1. persistent There is a set of policies that have to be available from very start on the device. Those policies should be persistent on the device and I see them changing infrequently. IMO, there is no need for I2RS to manage those policies, readonly access is sufficient. 2. transient Policies that are temporary defining some fwd behavior of device. I can see lot of cases where different applications based on some network conditions want to change forwarding behavior. Those should not be available after reboot. 3. locally defined by this I mean policies that defined by admin, applications through local I2RS agent. These can be transient and persistent, where I would classify that I2RS agent policies are only transient. Actually after rereading this, I would even consider policies defined by I2RS as remotely defined and therefore transient. 4. remotely defined by this I mean policies pushed from a different device (policy server, router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be always ephemeral. Dean On Jun 11, 2014, at 9:08 PM, Susan Hares > wrote: Dean: I combined REQ01/02 and REQ08/09. I've put the requirements in the front of the text. Please let know if have any suggestions on these approved changes. I wait 24 hours, and then spin the draft. On the agreement on REQ04, I cannot find a firm consensus. I would ask Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on the WG. I highlight a few messages below. The document is proposed for WG consensus so I will change it if the WG has consensus. Sue Hares Search for Consensus ===== Based on your comment, I sent looking for WG Direction regarding BGP or I2RS putting state. I cannot find it. BGP has a Flow specification (RFC5575). Where do you think those flow specifications end up? Writing into runtime configuration state? Writing into something like I2RS running data store? BGP ORFs might be kept in the BGP state or in associated features (Add/delete) in BGP, but Flow specifications are targeted toward data flow. On the list I could find the following: 1. I2RS BGP state to configuration - Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) - is the debate for the architecture document regarding keeping state in the I2RS Begin: http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Joel's: no state across a reboot: http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html 3. Wes George (operator) makes a comment that I2RS configuration should not replace current configuration related to BGP. http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html There is the Architecture Discussion 2: Persistence (ephemeral vs. permanent) http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html Multiple clients writing to agents (raised by Himanshu Shah) http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html Jeff (chair hat off) states he does not want to have I2rs changing state tables come from routing protocols (BGP--> I2RS state). He also feel dynamic state tables should be read-only, and not writable as suggested by the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html In the same thread, Sri states the I2RS agent should not provide an interface to change a table if there is no use-case to support it. Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri states " I am yet to see a use-case that requires direct manipulation of a single dynamic routing-protocol-instance specific route table by something other than that protocol. I don't believe there should be any such case." However, here it has been in the BGP use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html Jeff responds to Sri in tends to agree and does not mention the use case. http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html Sue Hares -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, June 06, 2014 4:03 PM To: Susan Hares Cc: t.petch; >; Keyur Patel (keyupate); Hannes Gredler; Russ White; Susan Hares; > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Susan, Many people don't know what NLRI abbreviation stands for (Network Layer Reachability Information , so writing it out first time would be a good idea. Throughout the text, the requirement number sequence is confusing until you get to the very and where all requirements are listed and then it makes sense. REQ04: The ability to interact with various policies configured on the forwarding devices, in order to inform the policies implemented by the dynamic routing processes. This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. It is not clear to me if your requirement is that dynamic protocols should impose persistent policies? It says it should be recorded in the configuration of the local device. I agree that those policies should be visible to operators and other applications, but not sure if dynamic protocols should be allowed to implement persistent policies. IMO, those should be ephemeral policies. So maybe text should look like this This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the running or ephemeral configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration. I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? In general I'm not sure if changing entries by dynamic protocol in RIB is a good idea. If you plan to change only what is configured on the local device, then that is OK, but if you start changing entries that are pushed from other devices in the network, the system would get unstable. And it looks to me that REQ09 would allow that. Dean On Jun 5, 2014, at 4:47 AM, Susan Hares > wrote: > Tom: > > I'm glad to change the citation in the abstract. On the authors, this was > merge of two drafts. > > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Thursday, June 05, 2014 4:35 AM > To: Susan Hares; i2rs@ietf.org > Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan > Hares'; rex@cisco.com > Subject: Re: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Sue > > Currently you have six authors which is too many for an RFC - someone's > got to go! For me, this is not just an admin point - when commenting, > I like to have one or two names, no more, as the clear pen holders > whom I can expect to act. Too often, with so many names, everyone > thinks that someone else will do something and nothing happens, so, in > all seriousness, I oppose adoption until you sort this out amongst yourselves. > > Note too that you have a citation in the Abstract, again not allowed - > this can be surprising difficult to get round but get round it you, > one or more thereof, must. > > Tom Petch > > > ----- Original Message ----- > From: "Susan Hares" > > To: > > Cc: "'Keyur Patel (keyupate)'" >; "Hannes Gredler" > >; "Russ White" >; "'Susan Hares'" > >; > > Sent: Wednesday, June 04, 2014 7:49 PM > Subject: [i2rs] FW: I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > >> Jeff and Ed: >> >> This updated draft has all the changes that Keyur Patel promised and > updates >> to the reference the current i2rs internet drafts. >> >> Would you please do a Working Group adoption call? >> >> Thank you, >> Sue Hares >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, June 04, 2014 1:44 PM >> To: i-d-announce@ietf.org >> Cc: i2rs@ietf.org >> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System > Working >> Group of the IETF. >> >> Title : Use Cases for an Interface to BGP Protocol >> Authors : Keyur Patel >> Rex Fernando >> Hannes Gredler >> Shane Amante >> Russ White >> Susan Hares >> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >> Pages : 17 >> Date : 2014-06-04 >> >> Abstract: >> A network routing protocol like BGP is typically configured and >> analyzed through some form of Command Line Interface (CLI) or >> NETCONF. These interactions to control BGP and diagnose its >> operation encompass: configuration of protocol parameters, display > of >> protocol data, setting of certain protocol state and debugging of > the >> protocol. >> >> Interface to the Routing System's (I2RS) Programmatic interfaces, > as >> defined in draft-ietf-i2rs-architecture, provides an alternate way > to >> control and diagnose the operation of the BGP protocol. I2RS may > be >> used for the configuration, manipulation, analyzing or collecting > the >> protocol data. This document describes set of use cases for which >> I2RS can be used for BGP protocol. It is intended to provide a > base >> for the solution draft describing a set of interfaces to the BGP >> protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >> >> >> Please note that it may take a couple of minutes from the time of > submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 17 06:15:58 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5DF1A037D for ; Tue, 17 Jun 2014 06:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifwbJnLE7iGS for ; Tue, 17 Jun 2014 06:15:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ED0B11A0375 for ; Tue, 17 Jun 2014 06:15:51 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9C341C13B; Tue, 17 Jun 2014 09:15:51 -0400 (EDT) Date: Tue, 17 Jun 2014 09:15:51 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140617131551.GM31387@pfrc> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/r2aaCS8LqOLr2Fy3cHoL9i0-bJw Cc: Russ White , i2rs@ietf.org, 'Edward Crabbe' , 'Susan Hares' , 'Jeffrey Haas' Subject: Re: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:15:56 -0000 On Tue, Jun 17, 2014 at 10:11:01AM +0100, t.petch wrote: > It is B that I am doubtful about. It is fine for BGP or RIP, but I do > not see it for link state protocols, that is for me, the SPT is not a > table of routes, backup routes and so on but, well shortest paths. > > Do you see an IS-IS, or OSPF, table comparable to the BGP table? Without making specific comment on what *should* be present in the model, there are three classes of clearly (IMO) useful information available from the IGPs: - The LSDB, which provides topology - The TEDB - The active route for a given destination at a given node as per SPF computations. The third item is RIB-like and is the usual input to broader router route-selection of an active path from multiple candidates. The third item will probably have tie-in to our RIB models. The first two items are places where abstractions in the model may make sense, but there's also some benefit to simply exposing protocol mechanics in the models. The difference is "this is a type-X LSA in OSPF" vs. "this is a link, this is a node, here are how they connect". The abstraction is a bit more useful in an I2RS context. The protocol mechanics are likely to be something that gets a protocol specific module in the owning Working Group. There will be interesting overlaps in the above two, and one of the more interesting bits of coordination work I2RS will have. -- Jeff From nobody Tue Jun 17 06:25:42 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B031A0383 for ; Tue, 17 Jun 2014 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KrjSOEv5EtC for ; Tue, 17 Jun 2014 06:25:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597D91A037D for ; Tue, 17 Jun 2014 06:25:35 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 17 Jun 2014 13:25:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Tue, 17 Jun 2014 13:25:32 +0000 From: Dean Bogdanovic To: t.petch Thread-Topic: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt Thread-Index: AQHPgcJPUJvejJP5KkGEiMWG5tf2EJtsshcAgAK5SACAADPXgIAABLmAgAV4kMqAAD8ygA== Date: Tue, 17 Jun 2014 13:25:31 +0000 Message-ID: References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> In-Reply-To: <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(377424004)(189002)(199002)(24454002)(76094002)(13464003)(377454003)(51704005)(92566001)(15975445006)(83072002)(19580395003)(105586001)(19580405001)(86362001)(85852003)(57306001)(83322001)(89996001)(93886003)(95666004)(101416001)(81342001)(77982001)(92726001)(99286002)(36756003)(4396001)(21056001)(74662001)(76482001)(33656002)(77096002)(85306003)(46102001)(77156001)(31966008)(62966002)(79102001)(74502001)(81542001)(15202345003)(50986999)(20776003)(87936001)(99396002)(83716003)(88136002)(76176999)(2656002)(104166001)(80022001)(93916002)(66066001)(64706001)(87286001)(50226001)(82746002)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB438; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="Windows-1252" Content-ID: <75B58ADEB9ACBB4487BCB5FF165E7EE5@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/63OVniV7CxMv8XJgbxWsvWzn0hU Cc: "" , Susan Hares , "" , "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White , Susan Hares Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:25:40 -0000 On Jun 17, 2014, at 5:35 AM, t.petch wrote: > ----- Original Message ----- > From: "Dean Bogdanovic" > To: "Susan Hares" > Sent: Friday, June 13, 2014 11:06 PM >=20 > Susan, >=20 > My answer to your question > do we ever let I2RS upon a command transfer policies to the persistent > storage? >=20 > My initial answer is no. And reason is security. Network admins want to > know exact state of the device after rebooting. If we want to allow > transfer of policies, then we would have to define roles and which roles > would be allowed to do that transfer. We are making things more complex, > when there are existing mechanisms for admins to do that. >=20 > > The counter argument to this is having got it right once, for some, > perhaps large, instantiation of an I2RS it, do you want to have to do it > all over again? why not? Isn't the point of automation to be able to reliably repeat action= s over and over again? >=20 > That is, I agree that after reboot, an operator should know that the box > is in the state defined by the NETCONF startup configuration datastore > with nothing added but that there may be a valid case for saying that > all the changes downloaded by I2RS remain stored, but not applied, eg in > a candidate I2RS datastore, which can then be copied to the running I2RS > datastore when the operator is satisfied that the time is right. I don't want to have multiple data stores in I2RS. I have recommended RESTC= ONF for I2RS and one of the main reasons for that was single data store, wh= ich makes config management very easy, as there is only one config. >=20 > Just a thought. >=20 > Tom Petch >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Dean >=20 > On Jun 13, 2014, at 5:49 PM, Susan Hares > > wrote: >=20 > Dean: > Thank you for your thoughtful answer. I was looking for it, but I=92m > glad you watched Croatia (I=92m sorry about Croatia=92s loss). >=20 > I agree with the types of policies and the status: persistent, > transient, and ephemeral. However, do we ever let I2RS upon a command > transfer policies to the persistent storage? This what I read in REQ04. > In reading the email, I=92m not sure how to summarize the WG=92s approach= . > My answer would be =93no=94, but if this is a WG document the answer need= s > to come from the WG. >=20 > Sue >=20 > From: i2rs [mailto:i2rs-bounces@ietf.org] On > Behalf Of Dean Bogdanovic > Sent: Friday, June 13, 2014 2:44 PM > To: Susan Hares > Cc: >; Susan Hares; > >; t.petch; Keyur Patel (keyupate); > Hannes Gredler; Russ White > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >=20 > Susan, >=20 > Sorry for late reply, but yesterday started a very significant > quadrennial event (FIFA World Cup) and Croatia played (and lost with > help of the referee). >=20 > WRT REQ04, I agree with the posts and here are few thoughts on this >=20 > We should try to divide policies into few categories. >=20 > 1. persistent > There is a set of policies that have to be available from very start on > the device. Those policies should be persistent on the device and I see > them changing infrequently. IMO, there is no need for I2RS to manage > those policies, readonly access is sufficient. > 2. transient > Policies that are temporary defining some fwd behavior of device. I can > see lot of cases where different applications based on some network > conditions want to change forwarding behavior. Those should not be > available after reboot. > 3. locally defined > by this I mean policies that defined by admin, applications through > local I2RS agent. These can be transient and persistent, where I would > classify that I2RS agent policies are only transient. Actually after > rereading this, I would even consider policies defined by I2RS as > remotely defined and therefore transient. > 4. remotely defined > by this I mean policies pushed from a different device (policy server, > router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be > always ephemeral. >=20 > Dean >=20 > On Jun 11, 2014, at 9:08 PM, Susan Hares > > wrote: >=20 >=20 > Dean: >=20 > I combined REQ01/02 and REQ08/09. I've put the requirements in the > front of the text. Please let know if have any suggestions on these > approved changes. I wait 24 hours, and then spin the draft. >=20 > On the agreement on REQ04, I cannot find a firm consensus. I would ask > Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on > the WG. I highlight a few messages below. The document is proposed for > WG consensus so I will change it if the WG has consensus. >=20 >=20 > Sue Hares >=20 >=20 > Search for Consensus > =3D=3D=3D=3D=3D > Based on your comment, I sent looking for WG Direction regarding BGP or > I2RS putting state. I cannot find it. BGP has a Flow specification > (RFC5575). Where do you think those flow specifications end up? > Writing into runtime configuration state? Writing into something like > I2RS running data store? BGP ORFs might be kept in the BGP state or in > associated features (Add/delete) in BGP, but Flow specifications are > targeted toward data flow. >=20 > On the list I could find the following: >=20 > 1. I2RS BGP state to configuration - Wes George (operator) makes a > comment that I2RS configuration should not replace current configuration > related to BGP. >=20 > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html >=20 >=20 >=20 > 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) - is the debate for the architecture document regarding > keeping state in the I2RS > Begin: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html >=20 > Joel's: no state across a reboot: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html >=20 >=20 > 3. Wes George (operator) makes a comment that I2RS configuration should > not replace current configuration related to BGP. > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html >=20 >=20 > There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html >=20 >=20 > Multiple clients writing to agents (raised by Himanshu Shah) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html >=20 >=20 > Jeff (chair hat off) states he does not want to have I2rs changing state > tables come from routing protocols (BGP--> I2RS state). He also feel > dynamic state tables should be read-only, and not writable as suggested > by the use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html >=20 >=20 > In the same thread, Sri states the I2RS agent should not provide an > interface to change a table if there is no use-case to support it. > Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri > states " I am yet to see a use-case that requires direct manipulation of > a single dynamic routing-protocol-instance specific route table by > something other than that protocol. I don't believe there should be any > such case." However, here it has been in the BGP use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html >=20 >=20 > Jeff responds to Sri in tends to agree and does not mention the use > case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html >=20 >=20 > Sue Hares >=20 > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net] > Sent: Friday, June 06, 2014 4:03 PM > To: Susan Hares > Cc: t.petch; >; Keyur Patel > (keyupate); Hannes Gredler; Russ White; Susan Hares; > > > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >=20 > Susan, >=20 > Many people don't know what NLRI abbreviation stands for (Network Layer > Reachability Information , so writing it out first time would be a good > idea. >=20 > Throughout the text, the requirement number sequence is confusing until > you get to the very and where all requirements are listed and then it > makes sense. >=20 > REQ04: The ability to interact with various policies configured on > the forwarding devices, in order to inform the policies > implemented by the dynamic routing processes. This interaction > should be through existing configuration mechanisms, such as > NETCONF, and should be recorded in the configuration of the local > device so operators are aware of the full policy implemented in > the network from the running configuration. > It is not clear to me if your requirement is that dynamic protocols > should impose persistent policies? It says it should be recorded in the > configuration of the local device. >=20 > I agree that those policies should be visible to operators and other > applications, but not sure if dynamic protocols should be allowed to > implement persistent policies. IMO, those should be ephemeral policies. > So maybe text should look like this > This interaction should be through existing configuration mechanisms, > such as NETCONF, and should be recorded in the running or ephemeral > configuration of the local device so operators are aware of the full > policy implemented in the network from the running configuration. >=20 > I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? >=20 > In general I'm not sure if changing entries by dynamic protocol in RIB > is a good idea. If you plan to change only what is configured on the > local device, then that is OK, but if you start changing entries that > are pushed from other devices in the network, the system would get > unstable. And it looks to me that REQ09 would allow that. >=20 > Dean >=20 >=20 > On Jun 5, 2014, at 4:47 AM, Susan Hares > > wrote: >=20 >> Tom: >>=20 >> I'm glad to change the citation in the abstract. On the authors, > this was >> merge of two drafts. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Thursday, June 05, 2014 4:35 AM >> To: Susan Hares; i2rs@ietf.org >> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan >> Hares'; rex@cisco.com >> Subject: Re: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >>=20 >> Sue >>=20 >> Currently you have six authors which is too many for an RFC - > someone's >> got to go! For me, this is not just an admin point - when > commenting, >> I like to have one or two names, no more, as the clear pen holders >> whom I can expect to act. Too often, with so many names, everyone >> thinks that someone else will do something and nothing happens, so, in >> all seriousness, I oppose adoption until you sort this out amongst > yourselves. >>=20 >> Note too that you have a citation in the Abstract, again not allowed - >> this can be surprising difficult to get round but get round it you, >> one or more thereof, must. >>=20 >> Tom Petch >>=20 >>=20 >> ----- Original Message ----- >> From: "Susan Hares" > >> To: > >> Cc: "'Keyur Patel (keyupate)'" > >; "Hannes Gredler" >> >; "Russ White" > >; "'Susan Hares'" >> >; > > >> Sent: Wednesday, June 04, 2014 7:49 PM >> Subject: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >>=20 >>=20 >>> Jeff and Ed: >>>=20 >>> This updated draft has all the changes that Keyur Patel promised and >> updates >>> to the reference the current i2rs internet drafts. >>>=20 >>> Would you please do a Working Group adoption call? >>>=20 >>> Thank you, >>> Sue Hares >>>=20 >>>=20 >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On > Behalf Of >>> internet-drafts@ietf.org >>> Sent: Wednesday, June 04, 2014 1:44 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Interface to the Routing System >> Working >>> Group of the IETF. >>>=20 >>> Title : Use Cases for an Interface to BGP Protocol >>> Authors : Keyur Patel >>> Rex Fernando >>> Hannes Gredler >>> Shane Amante >>> Russ White >>> Susan Hares >>> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >>> Pages : 17 >>> Date : 2014-06-04 >>>=20 >>> Abstract: >>> A network routing protocol like BGP is typically configured and >>> analyzed through some form of Command Line Interface (CLI) or >>> NETCONF. These interactions to control BGP and diagnose its >>> operation encompass: configuration of protocol parameters, display >> of >>> protocol data, setting of certain protocol state and debugging of >> the >>> protocol. >>>=20 >>> Interface to the Routing System's (I2RS) Programmatic interfaces, >> as >>> defined in draft-ietf-i2rs-architecture, provides an alternate way >> to >>> control and diagnose the operation of the BGP protocol. I2RS may >> be >>> used for the configuration, manipulation, analyzing or collecting >> the >>> protocol data. This document describes set of use cases for which >>> I2RS can be used for BGP protocol. It is intended to provide a >> base >>> for the solution draft describing a set of interfaces to the BGP >>> protocol. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at > tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > es-03.txt.pdf> >=20 >=20 >=20 From nobody Tue Jun 17 06:28:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81CD1A038A for ; Tue, 17 Jun 2014 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8fb2LnEIVIn for ; Tue, 17 Jun 2014 06:28:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F93B1A0389 for ; Tue, 17 Jun 2014 06:28:18 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 17 Jun 2014 13:28:16 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.141]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.155]) with mapi id 15.00.0954.000; Tue, 17 Jun 2014 13:28:16 +0000 From: Dean Bogdanovic To: Susan Hares Thread-Topic: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Thread-Index: Ac+GjQkiVWQpH0dxQVWc/MElqtTQqgAcSyRDAAKEgoAAZJNrgAAQRcWAAFUUboA= Date: Tue, 17 Jun 2014 13:28:16 +0000 Message-ID: <939A1A7E-7A12-468B-B3E0-853E85F93BE3@juniper.net> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <001501cf88db$ad661ec0$08325c40$@ndzh.com> In-Reply-To: <001501cf88db$ad661ec0$08325c40$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(54094003)(189002)(51404002)(13464003)(52044002)(51704005)(24454002)(377454003)(21056001)(77156001)(19580395003)(99396002)(15975445006)(92726001)(99286002)(81542001)(95666004)(85306003)(15188555004)(4396001)(77096002)(87286001)(88136002)(79102001)(74662001)(76176999)(66066001)(82746002)(2656002)(36756003)(87936001)(92566001)(85852003)(19580405001)(20776003)(50226001)(86362001)(89996001)(83322001)(64706001)(81342001)(83072002)(105586001)(62966002)(93886003)(33656002)(83716003)(15202345003)(31966008)(74502001)(104166001)(50986999)(76482001)(101416001)(93916002)(77982001)(80022001)(57306001)(46102001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=deanb@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/4Zw7YKsGu5Mn0HP29ftjtwgxAAs Cc: Jeffrey Haas , "" , Russ White , Edward Crabbe , "t.petch" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:28:24 -0000 Susan, I sent you my comments to this draft back in March and this was your reply = :-) http://www.ietf.org/mail-archive/web/i2rs/current/msg01319.html Dean On Jun 15, 2014, at 4:52 PM, Susan Hares wrote: > Dean: >=20 > Please look at the=20 > http://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/ >=20 > It provides the mobile backhaul use case. If you want to suggest changes= , > I'm a co-author. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net]=20 > Sent: Sunday, June 15, 2014 9:06 AM > To: Susan Hares > Cc: t.petch; ; Jeffrey Haas; Edward Crabbe; Russ White > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted >=20 > Susan, >=20 > I like the new format much better. It makes the reading more clear from > beginning. I disagree with REQ10. REQ10 implies that the i2rs will store > data in persistent storage.=20 >=20 > I have another use case for the draft, mobile backhaul. Currently > governments are preparing to release some new spectrum bands for public > usage. It will be a very different approach, as the lease period will be > significantly reduced from 15 years to hours. Idea is to use small cells > with this new spectrum to respond to increasing demand from mobile users = in > that geographical area, like a sports, music venue or certain city areas > that get very populated during certain peak hours. In such cases, mobile > backhaul has to be able to respond to such increase in demand and that wi= ll > require changing of forwarding policies in the backhaul. I2RS is a very g= ood > match for that task and following requirements should be listed: REQ01, > REQ02, REQ07, REQ08, REQ09. >=20 > Dean >=20 > On Jun 13, 2014, at 9:06 AM, "Russ White" > wrote: >=20 >>=20 >>> I note the reference to ISIS which I find significant. My experience=20 >>> is >> more of >>> OSPF but appreciate that that is rare with Operators. However, both=20 >>> are >> Link >>> State and so very different to BGP which makes me think about the use=20 >>> of RIB. The NETMOD routing-cfg started with RIBs, dropped them and=20 >>> then reinstated them (after consulting with I2RS), whereas for me,=20 >>> RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in=20 >>> LSDB, which is very different in detail (as much research as Lada has=20 >>> done across three >> differing >>> platforms, I am not certain that the NETMOD has sufficient routing >> expertise >>> to get this perfect:-(. >>=20 >> There are two different "RIBs," at least in theory -- vendor=20 >> implementations may vary. To try and separate things out, let's=20 >> describe a few tables, see if that's a complete description, and then tr= y > to name these things. >>=20 >> - There is the set of all the reachability information received by any=20 >> given process. I would correlate this to the BGP-RIB-IN, or the LSDB=20 >> in OSPF or IS-IS. >>=20 >> - There is the set of best paths determined by the particular process.=20 >> I would correlate this to the SPT in OSPF or IS-IS, and the BGP best=20 >> path table. >>=20 >> - There is the set of paths actually installed in the local device=20 >> memory, and off of which the local forwarding tables are built. Each=20 >> process running on the device installs reachability information into=20 >> this table, and there is some arbitration method within each=20 >> implementation designed to determine which process "wins," when there=20 >> are multiple installs for the same destination, as well as "callbacks"=20 >> for when routes are removed, and even perhaps "backup routes," and the > like. >>=20 >> - There is the set of forwarding table entries actually used for=20 >> forwarding traffic. Note there may be two layers of these, but they=20 >> typically include mac header rewrites, tunnel headers, and the like --=20 >> none of which any of the "ribs" described above would contain (they=20 >> would only contain a next hop, not the actual rewrite information). >>=20 >> If there are any I've missed, please feel free to add them in. This=20 >> draft is supposed to be addressing use cases that are centered on the=20 >> third one above in a "generic" way (not specific to some routing protoco= l, > etc.). >>=20 >>> REQ1 last sentence should probably include removing process >>=20 >> I'm fine with including this, but I can't think of a use case off the=20 >> top of my head... >>=20 >>> REQ2 I think is about source-based routing but it does not quite say=20 >>> that, rather reading as if source or destination routing were equally=20 >>> valid >> options >>=20 >> It intends to say that both source and destination routing are equally=20 >> valid options from the perspective of installed stuff into the RIB (#3 > above). >>=20 >>> REQ3 again the wording seems odd - I think you mean that traffic with=20 >>> a >> given >>> destination (or source?) prefix should be discarded, but that is not=20 >>> what >> it >>> says >>=20 >> This is akin to remote triggered black holes -- a route to interface=20 >> null0, which can be targeted either through the source (source=20 >> routing) or the destination. >>=20 >>> REQ4 I find vague, as I do anything with the word policy in it:-( >> Something >>> concrete (communities, MED, ...) would help >>=20 >> This isn't really MED (that would fall into the BGP use cases draft),=20 >> but rather mostly focused on setting the next hop, backup routes,=20 >> source routes, and other places where you might forward based on=20 >> things like port numbers, etc. >>=20 >>> REQ6 makes me wonder what is a RIB when it is not local >>=20 >> I suppose it could be remote in some way. Think of the RIB of a=20 >> virtual router that then installs routes using OpenFlow into a remote=20 >> switch -- is the RIB remote, or the FIB? I don't really know... I=20 >> guess it might make more sense just to take the word "local" out here. >>=20 >>> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like=20 >>> something more concrete. Again, I wonder if it is technically=20 >>> possible to present information in a consistent manner given the=20 >>> difference in underlying concepts of protocols. >>=20 >> This is actually restricted to the RIB (#3 above) by the context of=20 >> the draft, but it might be useful to add some restrictive language here. >>=20 >>> REQ9 - again all embracing and as such, probably impossible, at least=20 >>> as written. Limiting it just to BGP and a link-state protocol, again=20 >>> that >> seems >>> challenging. >>=20 >> Again, this is implied to be restricted to the RIB (#3 above) by the=20 >> context of the draft. Adding some restrictive language here might be=20 >> useful, or it might be overkill (your choice :-) ). >>=20 >>> REQ10 - policies again, and it is unclear who is doing the time >> management. >>> Some configuration protocols do have timer-based facilities, but not=20 >>> NETCONF; do you mean here that I2RS must have functionality based on=20 >>> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and >> Japan?) >>=20 >> Time based processing here generally means, "last route installed=20 >> wins, given all equal preferences otherwise," or perhaps, "time is the=20 >> tiebreaker." This area might need work, as this makes the final state=20 >> non-atomic (order dependent). The problem is there's no way to ensure=20 >> everyone is using different preference levels, etc. Any thoughts here=20 >> welcome. >>=20 >> :-) >>=20 >> Russ >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 >=20 From nobody Tue Jun 17 08:24:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DB31A0087 for ; Tue, 17 Jun 2014 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEFWMXVma39a for ; Tue, 17 Jun 2014 08:24:13 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E89601A0061 for ; Tue, 17 Jun 2014 08:24:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'t.petch'" , "'Ladislav Lhotka'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> In-Reply-To: <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> Date: Tue, 17 Jun 2014 11:23:42 -0400 Message-ID: <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAYz4lWgBliSQ9Jl34yGw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dU8CObDqaKeaV1g9IP7LQcvllo8 Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:24:17 -0000 Lada and Tom: You've convinced me that I should define the term RIB and FIB in the draft-white-i2rs-use-case-05. Would you like to suggest any text? Otherwise give me a day or so to come up with text for this draft. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch Sent: Tuesday, June 17, 2014 4:55 AM To: Ladislav Lhotka Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" Sent: Friday, June 13, 2014 1:11 PM > > On 13 Jun 2014, at 13:49, t.petch wrote: > > ---- Original Message ----- > > From: "Susan Hares" > Sent: Thursday, June 12, 2014 11:26 PM > > > >> I've posted a version of white-i2rs-use-case-05 with the > > recommendations at the front of the document. I look forward to > > additional comments. I appreciate Tom Petch and Dean B.'s comments on > > these drafts. > > > > Sue > > > > I am flattered; I am not sure that I deserve such mention. > > > > I am more interested in the use cases part of the I-D, seeing > > requirements and info-model as the next stage when use cases are agreed, > > and they look fine (perhaps /may Data Centers/many Data Centers/). > > > > I note the reference to ISIS which I find significant. My experience is > > more of OSPF but appreciate that that is rare with Operators. However, > > both are Link State and so very different to BGP which makes me think > > about the use of RIB. The NETMOD routing-cfg started with RIBs, dropped > > them and then reinstated them (after consulting with I2RS), whereas for > > me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent in > > LSDB, which is very different in detail (as much research as Lada has > > done across three differing platforms, I am not certain that the NETMOD > > has sufficient routing expertise to get this perfect:-(. > > > > I think you need a definition of RIB, perhaps by a Normative reference > > to rib-info-model, but for me that leaves unclear the relationship > > between routing instance, routing protocol and RIB, at least when you > > get into requirements. > > Sounds like recurring deja vu: > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html or, once again with feeling, http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html Tom Petch > > Lada > > > > > Likewise, this I-D is cast in terms of a table identifier and a route > > process identifier, whereas routing-cfg has routing-instance [name] > > with router-id, ribs, interfaces, routing-protocols etc I have a sense > > of two divergent models of what a router is for all the discussions. > > > > REQ1 last sentence should probably include removing process > > > > REQ2 I think is about source-based routing but it does not quite say > > that, rather reading as if source or destination routing were equally > > valid options > > > > REQ3 again the wording seems odd - I think you mean that traffic with a > > given destination (or source?) prefix should be discarded, but that is > > not what it says > > > > REQ4 I find vague, as I do anything with the word policy in it:-( > > Something concrete (communities, MED, ...) would help > > > > REQ6 makes me wonder what is a RIB when it is not local > > > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > > something more concrete. Again, I wonder if it is technically possible > > to present information in a consistent manner given the difference in > > underlying concepts of protocols. > > > > REQ9 - again all embracing and as such, probably impossible, at least as > > written. Limiting it just to BGP and a link-state protocol, again that > > seems challenging. > > > > REQ10 - policies again, and it is unclear who is doing the time > > management. Some configuration protocols do have timer-based > > facilities, but not NETCONF; do you mean here that I2RS must have > > functionality based on timers (e.g. between 08:00 and 17:00 EDT, route > > this via Europe and Japan?) > > > > Tom Petch > > > >> > >> URL: > > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > >> > >> Sue Hares > >> > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 17 08:35:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28441A0032 for ; Tue, 17 Jun 2014 08:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEbnkBP_yNXK for ; Tue, 17 Jun 2014 08:35:30 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 274C41A0024 for ; Tue, 17 Jun 2014 08:35:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Dean Bogdanovic'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <001501cf88db$ad661ec0$08325c40$@ndzh.com> <939A1A7E-7A12-468B-B3E0-853E85F93BE3@juniper.net> In-Reply-To: <939A1A7E-7A12-468B-B3E0-853E85F93BE3@juniper.net> Date: Tue, 17 Jun 2014 11:35:16 -0400 Message-ID: <009401cf8a41$bdc25290$3946f7b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAX03oZkCj15W6gGn8L+2AfpL12SZU4dZAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/olzodNBdSNnX_Ov40M7ENR6U3sc Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Russ White' , 'Edward Crabbe' , "'t.petch'" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:35:35 -0000 Dean: Thank you for those comments in March. -----Original Message----- From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Tuesday, June 17, 2014 9:28 AM To: Susan Hares Cc: t.petch; ; Jeffrey Haas; Edward Crabbe; Russ White Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Susan, I sent you my comments to this draft back in March and this was your reply :-) http://www.ietf.org/mail-archive/web/i2rs/current/msg01319.html. Thank you for the reply to my questions. I apologize. I missed sending you're a reply. I will reply on that mail thread. My co-authors and I are working on a revision based on your comments. Dean On Jun 15, 2014, at 4:52 PM, Susan Hares wrote: > Dean: > > Please look at the > http://datatracker.ietf.org/doc/draft-zhang-i2rs-mbb-usecases/ > > It provides the mobile backhaul use case. If you want to suggest > changes, I'm a co-author. > > Sue > > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net] > Sent: Sunday, June 15, 2014 9:06 AM > To: Susan Hares > Cc: t.petch; ; Jeffrey Haas; Edward Crabbe; Russ White > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > Susan, > > I like the new format much better. It makes the reading more clear > from beginning. I disagree with REQ10. REQ10 implies that the i2rs > will store data in persistent storage. > > I have another use case for the draft, mobile backhaul. Currently > governments are preparing to release some new spectrum bands for > public usage. It will be a very different approach, as the lease > period will be significantly reduced from 15 years to hours. Idea is > to use small cells with this new spectrum to respond to increasing > demand from mobile users in that geographical area, like a sports, > music venue or certain city areas that get very populated during > certain peak hours. In such cases, mobile backhaul has to be able to > respond to such increase in demand and that will require changing of > forwarding policies in the backhaul. I2RS is a very good match for > that task and following requirements should be listed: REQ01, REQ02, REQ07, REQ08, REQ09. > > Dean > > On Jun 13, 2014, at 9:06 AM, "Russ White" > wrote: > >> >>> I note the reference to ISIS which I find significant. My >>> experience is >> more of >>> OSPF but appreciate that that is rare with Operators. However, both >>> are >> Link >>> State and so very different to BGP which makes me think about the >>> use of RIB. The NETMOD routing-cfg started with RIBs, dropped them >>> and then reinstated them (after consulting with I2RS), whereas for >>> me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent >>> in LSDB, which is very different in detail (as much research as Lada >>> has done across three >> differing >>> platforms, I am not certain that the NETMOD has sufficient routing >> expertise >>> to get this perfect:-(. >> >> There are two different "RIBs," at least in theory -- vendor >> implementations may vary. To try and separate things out, let's >> describe a few tables, see if that's a complete description, and then >> try > to name these things. >> >> - There is the set of all the reachability information received by >> any given process. I would correlate this to the BGP-RIB-IN, or the >> LSDB in OSPF or IS-IS. >> >> - There is the set of best paths determined by the particular process. >> I would correlate this to the SPT in OSPF or IS-IS, and the BGP best >> path table. >> >> - There is the set of paths actually installed in the local device >> memory, and off of which the local forwarding tables are built. Each >> process running on the device installs reachability information into >> this table, and there is some arbitration method within each >> implementation designed to determine which process "wins," when there >> are multiple installs for the same destination, as well as "callbacks" >> for when routes are removed, and even perhaps "backup routes," and >> the > like. >> >> - There is the set of forwarding table entries actually used for >> forwarding traffic. Note there may be two layers of these, but they >> typically include mac header rewrites, tunnel headers, and the like >> -- none of which any of the "ribs" described above would contain >> (they would only contain a next hop, not the actual rewrite information). >> >> If there are any I've missed, please feel free to add them in. This >> draft is supposed to be addressing use cases that are centered on the >> third one above in a "generic" way (not specific to some routing >> protocol, > etc.). >> >>> REQ1 last sentence should probably include removing process >> >> I'm fine with including this, but I can't think of a use case off the >> top of my head... >> >>> REQ2 I think is about source-based routing but it does not quite say >>> that, rather reading as if source or destination routing were >>> equally valid >> options >> >> It intends to say that both source and destination routing are >> equally valid options from the perspective of installed stuff into >> the RIB (#3 > above). >> >>> REQ3 again the wording seems odd - I think you mean that traffic >>> with a >> given >>> destination (or source?) prefix should be discarded, but that is not >>> what >> it >>> says >> >> This is akin to remote triggered black holes -- a route to interface >> null0, which can be targeted either through the source (source >> routing) or the destination. >> >>> REQ4 I find vague, as I do anything with the word policy in it:-( >> Something >>> concrete (communities, MED, ...) would help >> >> This isn't really MED (that would fall into the BGP use cases draft), >> but rather mostly focused on setting the next hop, backup routes, >> source routes, and other places where you might forward based on >> things like port numbers, etc. >> >>> REQ6 makes me wonder what is a RIB when it is not local >> >> I suppose it could be remote in some way. Think of the RIB of a >> virtual router that then installs routes using OpenFlow into a remote >> switch -- is the RIB remote, or the FIB? I don't really know... I >> guess it might make more sense just to take the word "local" out here. >> >>> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like >>> something more concrete. Again, I wonder if it is technically >>> possible to present information in a consistent manner given the >>> difference in underlying concepts of protocols. >> >> This is actually restricted to the RIB (#3 above) by the context of >> the draft, but it might be useful to add some restrictive language here. >> >>> REQ9 - again all embracing and as such, probably impossible, at >>> least as written. Limiting it just to BGP and a link-state >>> protocol, again that >> seems >>> challenging. >> >> Again, this is implied to be restricted to the RIB (#3 above) by the >> context of the draft. Adding some restrictive language here might be >> useful, or it might be overkill (your choice :-) ). >> >>> REQ10 - policies again, and it is unclear who is doing the time >> management. >>> Some configuration protocols do have timer-based facilities, but not >>> NETCONF; do you mean here that I2RS must have functionality based on >>> timers (e.g. between 08:00 and 17:00 EDT, route this via Europe and >> Japan?) >> >> Time based processing here generally means, "last route installed >> wins, given all equal preferences otherwise," or perhaps, "time is >> the tiebreaker." This area might need work, as this makes the final >> state non-atomic (order dependent). The problem is there's no way to >> ensure everyone is using different preference levels, etc. Any >> thoughts here welcome. >> >> :-) >> >> Russ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue Jun 17 08:36:16 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6401A0087 for ; Tue, 17 Jun 2014 08:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGfXbneOEMnT for ; Tue, 17 Jun 2014 08:36:08 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FCF71A0032 for ; Tue, 17 Jun 2014 08:36:08 -0700 (PDT) Received: from DBXPRD0610HT001.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 17 Jun 2014 15:36:05 +0000 Message-ID: <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> From: t.petch To: Jeffrey Haas References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> <20140617131551.GM31387@pfrc> Date: Tue, 17 Jun 2014 16:29:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AMXPR07CA003.eurprd07.prod.outlook.com (10.242.64.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(13464003)(51704005)(189002)(199002)(377454003)(23756003)(89996001)(46102001)(42186005)(81542001)(19580395003)(79102001)(85306003)(104166001)(88136002)(62966002)(102836001)(81342001)(83322001)(101416001)(19580405001)(87286001)(99396002)(50986999)(76482001)(77156001)(77982001)(21056001)(105586001)(4396001)(14496001)(83072002)(44736004)(84392001)(93886003)(50466002)(74502001)(92566001)(92726001)(76176999)(31966008)(81816999)(81686999)(47776003)(20776003)(85852003)(87976001)(93916002)(86362001)(77096002)(61296003)(50226001)(74662001)(80022001)(33646001)(66066001)(62236002)(95666004)(44716002)(64706001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0610HT001.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/ckzPFBj6EMex97q1--H50CnJUks Cc: Russ White , i2rs@ietf.org, 'Edward Crabbe' , 'Susan Hares' , 'Jeffrey Haas' Subject: Re: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:36:13 -0000 ----- Original Message ----- From: "Jeffrey Haas" To: "t.petch" Cc: "Russ White" ; "'Susan Hares'" ; ; "'Jeffrey Haas'" ; "'Edward Crabbe'" Sent: Tuesday, June 17, 2014 2:15 PM Subject: Re: tables was: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > On Tue, Jun 17, 2014 at 10:11:01AM +0100, t.petch wrote: > > It is B that I am doubtful about. It is fine for BGP or RIP, but I do > > not see it for link state protocols, that is for me, the SPT is not a > > table of routes, backup routes and so on but, well shortest paths. > > > > Do you see an IS-IS, or OSPF, table comparable to the BGP table? > > Without making specific comment on what *should* be present in the model, > there are three classes of clearly (IMO) useful information available from > the IGPs: > > - The LSDB, which provides topology > - The TEDB > - The active route for a given destination at a given node as per SPF > computations. > > The third item is RIB-like and is the usual input to broader router > route-selection of an active path from multiple candidates. > > The third item will probably have tie-in to our RIB models. > > The first two items are places where abstractions in the model may make > sense, but there's also some benefit to simply exposing protocol mechanics > in the models. The difference is "this is a type-X LSA in OSPF" vs. "this > is a link, this is a node, here are how they connect". > > The abstraction is a bit more useful in an I2RS context. > The protocol mechanics are likely to be something that gets a protocol > specific module in the owning Working Group. > > There will be interesting overlaps in the above two, and one of the more > interesting bits of coordination work I2RS will have. Jeff We have just got a netmod-isis draft draft-litkowski-netmod-isis-cfg-00.txt and I look for items of the third type, and at first sight, I do not see them, just as I cannot recall seeing them in SMI models, either standards-based or proprietary (unlike the LSDB). Of course they can be added but .... well, I have said enough about it. Tom Petch > > -- Jeff From nobody Tue Jun 17 08:36:18 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799201A0032 for ; Tue, 17 Jun 2014 08:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72S6PHfFRIjQ for ; Tue, 17 Jun 2014 08:36:09 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0075.outbound.protection.outlook.com [213.199.154.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D226B1A0066 for ; Tue, 17 Jun 2014 08:36:08 -0700 (PDT) Received: from DBXPRD0610HT001.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.959.24; Tue, 17 Jun 2014 15:36:06 +0000 Message-ID: <011901cf8a41$69162500$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , 'Ladislav Lhotka' References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> Date: Tue, 17 Jun 2014 16:32:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AMXPR07CA003.eurprd07.prod.outlook.com (10.242.64.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(54094003)(24454002)(51414003)(13464003)(51704005)(189002)(199002)(377454003)(23756003)(89996001)(46102001)(42186005)(81542001)(19580395003)(79102001)(85306003)(104166001)(88136002)(62966002)(102836001)(81342001)(83322001)(101416001)(19580405001)(87286001)(99396002)(50986999)(76482001)(77156001)(77982001)(21056001)(105586001)(4396001)(14496001)(83072002)(44736004)(84392001)(93886003)(15975445006)(15188555004)(50466002)(74502001)(92566001)(92726001)(76176999)(31966008)(81816999)(81686999)(47776003)(20776003)(85852003)(87976001)(575784001)(93916002)(86362001)(77096002)(61296003)(50226001)(74662001)(80022001)(33646001)(66066001)(62236002)(15202345003)(95666004)(44716002)(64706001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0610HT001.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Pmbd7aMpH0dwkjftY99gIsdZ1So Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:36:13 -0000 Sue Probably best to do it yourself. I did offer a reprise of previous IETF work in http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html but it did not gain traction in NETMOD, so I would not expect it to here. Tom Petch ----- Original Message ----- From: "Susan Hares" To: "'t.petch'" ; "'Ladislav Lhotka'" Cc: "'Jeffrey Haas'" ; ; "'Edward Crabbe'" Sent: Tuesday, June 17, 2014 4:23 PM Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > Lada and Tom: > > You've convinced me that I should define the term RIB and FIB in the > draft-white-i2rs-use-case-05. Would you like to suggest any text? > Otherwise give me a day or so to come up with text for this draft. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 17, 2014 4:55 AM > To: Ladislav Lhotka > Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" > Sent: Friday, June 13, 2014 1:11 PM > > > > On 13 Jun 2014, at 13:49, t.petch wrote: > > > ---- Original Message ----- > > > From: "Susan Hares" > > Sent: Thursday, June 12, 2014 11:26 PM > > > > > >> I've posted a version of white-i2rs-use-case-05 with the > > > recommendations at the front of the document. I look forward to > > > additional comments. I appreciate Tom Petch and Dean B.'s comments > on > > > these drafts. > > > > > > Sue > > > > > > I am flattered; I am not sure that I deserve such mention. > > > > > > I am more interested in the use cases part of the I-D, seeing > > > requirements and info-model as the next stage when use cases are > agreed, > > > and they look fine (perhaps /may Data Centers/many Data Centers/). > > > > > > I note the reference to ISIS which I find significant. My > experience is > > > more of OSPF but appreciate that that is rare with Operators. > However, > > > both are Link State and so very different to BGP which makes me > think > > > about the use of RIB. The NETMOD routing-cfg started with RIBs, > dropped > > > them and then reinstated them (after consulting with I2RS), whereas > for > > > me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent > in > > > LSDB, which is very different in detail (as much research as Lada > has > > > done across three differing platforms, I am not certain that the > NETMOD > > > has sufficient routing expertise to get this perfect:-(. > > > > > > I think you need a definition of RIB, perhaps by a Normative > reference > > > to rib-info-model, but for me that leaves unclear the relationship > > > between routing instance, routing protocol and RIB, at least when > you > > > get into requirements. > > > > Sounds like recurring deja vu: > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html > > > or, once again with feeling, > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > Tom Petch > > > > > Lada > > > > > > > > Likewise, this I-D is cast in terms of a table identifier and a > route > > > process identifier, whereas routing-cfg has routing-instance [name] > > > with router-id, ribs, interfaces, routing-protocols etc I have a > sense > > > of two divergent models of what a router is for all the discussions. > > > > > > REQ1 last sentence should probably include removing process > > > > > > REQ2 I think is about source-based routing but it does not quite say > > > that, rather reading as if source or destination routing were > equally > > > valid options > > > > > > REQ3 again the wording seems odd - I think you mean that traffic > with a > > > given destination (or source?) prefix should be discarded, but that > is > > > not what it says > > > > > > REQ4 I find vague, as I do anything with the word policy in it:-( > > > Something concrete (communities, MED, ...) would help > > > > > > REQ6 makes me wonder what is a RIB when it is not local > > > > > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > > > something more concrete. Again, I wonder if it is technically > possible > > > to present information in a consistent manner given the difference > in > > > underlying concepts of protocols. > > > > > > REQ9 - again all embracing and as such, probably impossible, at > least as > > > written. Limiting it just to BGP and a link-state protocol, again > that > > > seems challenging. > > > > > > REQ10 - policies again, and it is unclear who is doing the time > > > management. Some configuration protocols do have timer-based > > > facilities, but not NETCONF; do you mean here that I2RS must have > > > functionality based on timers (e.g. between 08:00 and 17:00 EDT, > route > > > this via Europe and Japan?) > > > > > > Tom Petch > > > > > >> > > >> URL: > > > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > > >> > > >> Sue Hares > > >> > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 17 08:45:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA45B1A0043 for ; Tue, 17 Jun 2014 08:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVC-7KGhiOWg for ; Tue, 17 Jun 2014 08:45:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9298A1A0041 for ; Tue, 17 Jun 2014 08:45:31 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A31DA140940; Tue, 17 Jun 2014 17:45:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403019930; bh=on9Izqf7ynLWCHOjcBLnrgqbSMIgRuIandyxsxSYVXs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wT0BL/E78Zn74tLXhL45El1gaiBCVPG6M9DHq2RVpscdVAnrKfHd8kUYGQJ2ic6hG QmM340dgwMxVXPPccDNp8hkgXvXZHOVWfo2LAxLAyDpB4Qemlqf9Gts7ZQj2hoE8Wa OTftHHVWf5eDVMV4MABGPr3UnV0YgiErm2u7znY0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> Date: Tue, 17 Jun 2014 17:45:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wMool_MDC7QGgzDj6yKyCpe9I4A Cc: Jeffrey Haas , i2rs@ietf.org, Edward Crabbe , "t.petch" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:45:36 -0000 Hi Sue, as for RIB, I=92d suggest to use the definition from = draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2), or at least one = that=92s compatible with it. We actually agreed on this definition = previously with the guys working on the RIB info model. Thanks, Lada On 17 Jun 2014, at 17:23, Susan Hares wrote: > Lada and Tom: =20 >=20 > You've convinced me that I should define the term RIB and FIB in the > draft-white-i2rs-use-case-05. Would you like to suggest any text? > Otherwise give me a day or so to come up with text for this draft.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 17, 2014 4:55 AM > To: Ladislav Lhotka > Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted >=20 > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" > Sent: Friday, June 13, 2014 1:11 PM >>=20 >> On 13 Jun 2014, at 13:49, t.petch wrote: >>> ---- Original Message ----- >>> From: "Susan Hares" >> Sent: Thursday, June 12, 2014 11:26 PM >>>=20 >>>> I've posted a version of white-i2rs-use-case-05 with the >>> recommendations at the front of the document. I look forward to=20 >>> additional comments. I appreciate Tom Petch and Dean B.'s comments > on >>> these drafts. >>>=20 >>> Sue >>>=20 >>> I am flattered; I am not sure that I deserve such mention. >>>=20 >>> I am more interested in the use cases part of the I-D, seeing=20 >>> requirements and info-model as the next stage when use cases are > agreed, >>> and they look fine (perhaps /may Data Centers/many Data Centers/). >>>=20 >>> I note the reference to ISIS which I find significant. My > experience is >>> more of OSPF but appreciate that that is rare with Operators. > However, >>> both are Link State and so very different to BGP which makes me > think >>> about the use of RIB. The NETMOD routing-cfg started with RIBs, > dropped >>> them and then reinstated them (after consulting with I2RS), whereas > for >>> me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent > in >>> LSDB, which is very different in detail (as much research as Lada > has >>> done across three differing platforms, I am not certain that the > NETMOD >>> has sufficient routing expertise to get this perfect:-(. >>>=20 >>> I think you need a definition of RIB, perhaps by a Normative > reference >>> to rib-info-model, but for me that leaves unclear the relationship=20= >>> between routing instance, routing protocol and RIB, at least when > you >>> get into requirements. >>=20 >> Sounds like recurring deja vu: >>=20 >> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html >>=20 >> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html >=20 >=20 > or, once again with feeling, >=20 > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html >=20 > Tom Petch >=20 >>=20 >> Lada >>=20 >>>=20 >>> Likewise, this I-D is cast in terms of a table identifier and a > route >>> process identifier, whereas routing-cfg has routing-instance [name]=20= >>> with router-id, ribs, interfaces, routing-protocols etc I have a > sense >>> of two divergent models of what a router is for all the discussions. >>>=20 >>> REQ1 last sentence should probably include removing process >>>=20 >>> REQ2 I think is about source-based routing but it does not quite say=20= >>> that, rather reading as if source or destination routing were > equally >>> valid options >>>=20 >>> REQ3 again the wording seems odd - I think you mean that traffic > with a >>> given destination (or source?) prefix should be discarded, but that > is >>> not what it says >>>=20 >>> REQ4 I find vague, as I do anything with the word policy in it:-(=20 >>> Something concrete (communities, MED, ...) would help >>>=20 >>> REQ6 makes me wonder what is a RIB when it is not local >>>=20 >>> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like=20 >>> something more concrete. Again, I wonder if it is technically > possible >>> to present information in a consistent manner given the difference > in >>> underlying concepts of protocols. >>>=20 >>> REQ9 - again all embracing and as such, probably impossible, at > least as >>> written. Limiting it just to BGP and a link-state protocol, again > that >>> seems challenging. >>>=20 >>> REQ10 - policies again, and it is unclear who is doing the time=20 >>> management. Some configuration protocols do have timer-based=20 >>> facilities, but not NETCONF; do you mean here that I2RS must have=20 >>> functionality based on timers (e.g. between 08:00 and 17:00 EDT, > route >>> this via Europe and Japan?) >>>=20 >>> Tom Petch >>>=20 >>>>=20 >>>> URL: >>> http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt >>>>=20 >>>> Sue Hares >>>>=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 17 08:51:11 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB3C1A006D for ; Tue, 17 Jun 2014 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3NP8KARU0e8 for ; Tue, 17 Jun 2014 08:51:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 291041A0391 for ; Tue, 17 Jun 2014 08:51:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Ladislav Lhotka'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> In-Reply-To: Date: Tue, 17 Jun 2014 11:50:36 -0400 Message-ID: <000301cf8a43$e2304590$a690d0b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAYz4lWgBliSQ9AI3ySfdAuPd/l2ZTw3eYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/plHmulZv5QcrCQ1tqa8ZsdwXnNA Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Edward Crabbe' , "'t.petch'" Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:51:10 -0000 Lada: Thanks for the pointer to text. Sue Hares -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz] Sent: Tuesday, June 17, 2014 11:45 AM To: Susan Hares Cc: t.petch; Jeffrey Haas; i2rs@ietf.org; Edward Crabbe Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Hi Sue, as for RIB, I'd suggest to use the definition from draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2), or at least one that's compatible with it. We actually agreed on this definition previously with the guys working on the RIB info model. Thanks, Lada On 17 Jun 2014, at 17:23, Susan Hares wrote: > Lada and Tom: > > You've convinced me that I should define the term RIB and FIB in the > draft-white-i2rs-use-case-05. Would you like to suggest any text? > Otherwise give me a day or so to come up with text for this draft. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 17, 2014 4:55 AM > To: Ladislav Lhotka > Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" > Sent: Friday, June 13, 2014 1:11 PM >> >> On 13 Jun 2014, at 13:49, t.petch wrote: >>> ---- Original Message ----- >>> From: "Susan Hares" >> Sent: Thursday, June 12, 2014 11:26 PM >>> >>>> I've posted a version of white-i2rs-use-case-05 with the >>> recommendations at the front of the document. I look forward to >>> additional comments. I appreciate Tom Petch and Dean B.'s comments > on >>> these drafts. >>> >>> Sue >>> >>> I am flattered; I am not sure that I deserve such mention. >>> >>> I am more interested in the use cases part of the I-D, seeing >>> requirements and info-model as the next stage when use cases are > agreed, >>> and they look fine (perhaps /may Data Centers/many Data Centers/). >>> >>> I note the reference to ISIS which I find significant. My > experience is >>> more of OSPF but appreciate that that is rare with Operators. > However, >>> both are Link State and so very different to BGP which makes me > think >>> about the use of RIB. The NETMOD routing-cfg started with RIBs, > dropped >>> them and then reinstated them (after consulting with I2RS), whereas > for >>> me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent > in >>> LSDB, which is very different in detail (as much research as Lada > has >>> done across three differing platforms, I am not certain that the > NETMOD >>> has sufficient routing expertise to get this perfect:-(. >>> >>> I think you need a definition of RIB, perhaps by a Normative > reference >>> to rib-info-model, but for me that leaves unclear the relationship >>> between routing instance, routing protocol and RIB, at least when > you >>> get into requirements. >> >> Sounds like recurring deja vu: >> >> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html >> >> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html > > > or, once again with feeling, > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > Tom Petch > >> >> Lada >> >>> >>> Likewise, this I-D is cast in terms of a table identifier and a > route >>> process identifier, whereas routing-cfg has routing-instance [name] >>> with router-id, ribs, interfaces, routing-protocols etc I have a > sense >>> of two divergent models of what a router is for all the discussions. >>> >>> REQ1 last sentence should probably include removing process >>> >>> REQ2 I think is about source-based routing but it does not quite say >>> that, rather reading as if source or destination routing were > equally >>> valid options >>> >>> REQ3 again the wording seems odd - I think you mean that traffic > with a >>> given destination (or source?) prefix should be discarded, but that > is >>> not what it says >>> >>> REQ4 I find vague, as I do anything with the word policy in it:-( >>> Something concrete (communities, MED, ...) would help >>> >>> REQ6 makes me wonder what is a RIB when it is not local >>> >>> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like >>> something more concrete. Again, I wonder if it is technically > possible >>> to present information in a consistent manner given the difference > in >>> underlying concepts of protocols. >>> >>> REQ9 - again all embracing and as such, probably impossible, at > least as >>> written. Limiting it just to BGP and a link-state protocol, again > that >>> seems challenging. >>> >>> REQ10 - policies again, and it is unclear who is doing the time >>> management. Some configuration protocols do have timer-based >>> facilities, but not NETCONF; do you mean here that I2RS must have >>> functionality based on timers (e.g. between 08:00 and 17:00 EDT, > route >>> this via Europe and Japan?) >>> >>> Tom Petch >>> >>>> >>>> URL: >>> http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt >>>> >>>> Sue Hares >>>> >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 17 08:53:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA071A0066 for ; Tue, 17 Jun 2014 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL-fZHK6IrbP for ; Tue, 17 Jun 2014 08:53:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5C1A0051 for ; Tue, 17 Jun 2014 08:53:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'t.petch'" , "'Ladislav Lhotka'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> <011901cf8a41$69162500$4001a8c0@gateway.2wire.net> In-Reply-To: <011901cf8a41$69162500$4001a8c0@gateway.2wire.net> Date: Tue, 17 Jun 2014 11:53:02 -0400 Message-ID: <000501cf8a44$38d07af0$aa7170d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAYz4lWgBliSQ9AI3ySfdAiL69V+ZVRVooA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/7mJ0PqA2w5jeDlyZy3WGRc_o2BE Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:53:18 -0000 Tom: Thank you for the pointer to your earlier message. What do you think of Lada's suggestion of "draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2)"? Sue -----Original Message----- From: t.petch [mailto:ietfc@btconnect.com] Sent: Tuesday, June 17, 2014 11:33 AM To: Susan Hares; 'Ladislav Lhotka' Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted Sue Probably best to do it yourself. I did offer a reprise of previous IETF work in http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html but it did not gain traction in NETMOD, so I would not expect it to here. Tom Petch ----- Original Message ----- From: "Susan Hares" To: "'t.petch'" ; "'Ladislav Lhotka'" Cc: "'Jeffrey Haas'" ; ; "'Edward Crabbe'" Sent: Tuesday, June 17, 2014 4:23 PM Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > Lada and Tom: > > You've convinced me that I should define the term RIB and FIB in the > draft-white-i2rs-use-case-05. Would you like to suggest any text? > Otherwise give me a day or so to come up with text for this draft. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 17, 2014 4:55 AM > To: Ladislav Lhotka > Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" > Sent: Friday, June 13, 2014 1:11 PM > > > > On 13 Jun 2014, at 13:49, t.petch wrote: > > > ---- Original Message ----- > > > From: "Susan Hares" > > Sent: Thursday, June 12, 2014 11:26 PM > > > > > >> I've posted a version of white-i2rs-use-case-05 with the > > > recommendations at the front of the document. I look forward to > > > additional comments. I appreciate Tom Petch and Dean B.'s comments > on > > > these drafts. > > > > > > Sue > > > > > > I am flattered; I am not sure that I deserve such mention. > > > > > > I am more interested in the use cases part of the I-D, seeing > > > requirements and info-model as the next stage when use cases are > agreed, > > > and they look fine (perhaps /may Data Centers/many Data Centers/). > > > > > > I note the reference to ISIS which I find significant. My > experience is > > > more of OSPF but appreciate that that is rare with Operators. > However, > > > both are Link State and so very different to BGP which makes me > think > > > about the use of RIB. The NETMOD routing-cfg started with RIBs, > dropped > > > them and then reinstated them (after consulting with I2RS), whereas > for > > > me, RIBs are BGP (as defined in RFC4271) and OSPF has an equivalent > in > > > LSDB, which is very different in detail (as much research as Lada > has > > > done across three differing platforms, I am not certain that the > NETMOD > > > has sufficient routing expertise to get this perfect:-(. > > > > > > I think you need a definition of RIB, perhaps by a Normative > reference > > > to rib-info-model, but for me that leaves unclear the relationship > > > between routing instance, routing protocol and RIB, at least when > you > > > get into requirements. > > > > Sounds like recurring deja vu: > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html > > > or, once again with feeling, > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > Tom Petch > > > > > Lada > > > > > > > > Likewise, this I-D is cast in terms of a table identifier and a > route > > > process identifier, whereas routing-cfg has routing-instance [name] > > > with router-id, ribs, interfaces, routing-protocols etc I have a > sense > > > of two divergent models of what a router is for all the discussions. > > > > > > REQ1 last sentence should probably include removing process > > > > > > REQ2 I think is about source-based routing but it does not quite say > > > that, rather reading as if source or destination routing were > equally > > > valid options > > > > > > REQ3 again the wording seems odd - I think you mean that traffic > with a > > > given destination (or source?) prefix should be discarded, but that > is > > > not what it says > > > > > > REQ4 I find vague, as I do anything with the word policy in it:-( > > > Something concrete (communities, MED, ...) would help > > > > > > REQ6 makes me wonder what is a RIB when it is not local > > > > > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > > > something more concrete. Again, I wonder if it is technically > possible > > > to present information in a consistent manner given the difference > in > > > underlying concepts of protocols. > > > > > > REQ9 - again all embracing and as such, probably impossible, at > least as > > > written. Limiting it just to BGP and a link-state protocol, again > that > > > seems challenging. > > > > > > REQ10 - policies again, and it is unclear who is doing the time > > > management. Some configuration protocols do have timer-based > > > facilities, but not NETCONF; do you mean here that I2RS must have > > > functionality based on timers (e.g. between 08:00 and 17:00 EDT, > route > > > this via Europe and Japan?) > > > > > > Tom Petch > > > > > >> > > >> URL: > > > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > > >> > > >> Sue Hares > > >> > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 17 09:14:28 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CF71A0085 for ; Tue, 17 Jun 2014 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phrKhpm66JPp for ; Tue, 17 Jun 2014 09:14:21 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4BE1A0043 for ; Tue, 17 Jun 2014 09:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7B65C246BFD; Tue, 17 Jun 2014 09:14:21 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from host-78-75-253-53.homerun.telia.com (host-78-75-253-53.homerun.telia.com [78.75.253.53]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 67FE9246BFE; Tue, 17 Jun 2014 09:14:19 -0700 (PDT) Message-ID: <53A0695D.6090309@joelhalpern.com> Date: Tue, 17 Jun 2014 12:14:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "t.petch" , Dean Bogdanovic , Susan Hares References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> In-Reply-To: <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/794GqtdvGPzIbtEQTltmeGLRDdM Cc: i2rs@ietf.org, Susan Hares , rex@cisco.com, "Keyur Patel \(keyupate\)" , Hannes Gredler , Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 16:14:24 -0000 I REALLY do not want I2RS getting into writing persistent storage. It creates many complications in implementing I2RS and in maintaining system state. it also interacts interestingly with configuration maintenance. (Yes, I2RS itself itneracts interestingly there, but at least that does not affect the reboot state.) Yours, Joel On 6/17/14, 5:35 AM, t.petch wrote: > ----- Original Message ----- > From: "Dean Bogdanovic" > To: "Susan Hares" > Sent: Friday, June 13, 2014 11:06 PM > > Susan, > > My answer to your question > do we ever let I2RS upon a command transfer policies to the persistent > storage? > > My initial answer is no. And reason is security. Network admins want to > know exact state of the device after rebooting. If we want to allow > transfer of policies, then we would have to define roles and which roles > would be allowed to do that transfer. We are making things more complex, > when there are existing mechanisms for admins to do that. > > > The counter argument to this is having got it right once, for some, > perhaps large, instantiation of an I2RS it, do you want to have to do it > all over again? > > That is, I agree that after reboot, an operator should know that the box > is in the state defined by the NETCONF startup configuration datastore > with nothing added but that there may be a valid case for saying that > all the changes downloaded by I2RS remain stored, but not applied, eg in > a candidate I2RS datastore, which can then be copied to the running I2RS > datastore when the operator is satisfied that the time is right. > > Just a thought. > > Tom Petch > > > > > > > > > > Dean > > On Jun 13, 2014, at 5:49 PM, Susan Hares > > wrote: > > Dean: > Thank you for your thoughtful answer. I was looking for it, but I’m > glad you watched Croatia (I’m sorry about Croatia’s loss). > > I agree with the types of policies and the status: persistent, > transient, and ephemeral. However, do we ever let I2RS upon a command > transfer policies to the persistent storage? This what I read in REQ04. > In reading the email, I’m not sure how to summarize the WG’s approach. > My answer would be “no”, but if this is a WG document the answer needs > to come from the WG. > > Sue > > From: i2rs [mailto:i2rs-bounces@ietf.org] On > Behalf Of Dean Bogdanovic > Sent: Friday, June 13, 2014 2:44 PM > To: Susan Hares > Cc: >; Susan Hares; > >; t.petch; Keyur Patel (keyupate); > Hannes Gredler; Russ White > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > > Susan, > > Sorry for late reply, but yesterday started a very significant > quadrennial event (FIFA World Cup) and Croatia played (and lost with > help of the referee). > > WRT REQ04, I agree with the posts and here are few thoughts on this > > We should try to divide policies into few categories. > > 1. persistent > There is a set of policies that have to be available from very start on > the device. Those policies should be persistent on the device and I see > them changing infrequently. IMO, there is no need for I2RS to manage > those policies, readonly access is sufficient. > 2. transient > Policies that are temporary defining some fwd behavior of device. I can > see lot of cases where different applications based on some network > conditions want to change forwarding behavior. Those should not be > available after reboot. > 3. locally defined > by this I mean policies that defined by admin, applications through > local I2RS agent. These can be transient and persistent, where I would > classify that I2RS agent policies are only transient. Actually after > rereading this, I would even consider policies defined by I2RS as > remotely defined and therefore transient. > 4. remotely defined > by this I mean policies pushed from a different device (policy server, > router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should be > always ephemeral. > > Dean > > On Jun 11, 2014, at 9:08 PM, Susan Hares > > wrote: > > > Dean: > > I combined REQ01/02 and REQ08/09. I've put the requirements in the > front of the text. Please let know if have any suggestions on these > approved changes. I wait 24 hours, and then spin the draft. > > On the agreement on REQ04, I cannot find a firm consensus. I would ask > Jeff Haas or Ed Crabbe to indicate if they think there is a consensus on > the WG. I highlight a few messages below. The document is proposed for > WG consensus so I will change it if the WG has consensus. > > > Sue Hares > > > Search for Consensus > ===== > Based on your comment, I sent looking for WG Direction regarding BGP or > I2RS putting state. I cannot find it. BGP has a Flow specification > (RFC5575). Where do you think those flow specifications end up? > Writing into runtime configuration state? Writing into something like > I2RS running data store? BGP ORFs might be kept in the BGP state or in > associated features (Add/delete) in BGP, but Flow specifications are > targeted toward data flow. > > On the list I could find the following: > > 1. I2RS BGP state to configuration - Wes George (operator) makes a > comment that I2RS configuration should not replace current configuration > related to BGP. > > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html > > > > 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) - is the debate for the architecture document regarding > keeping state in the I2RS > Begin: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html > > Joel's: no state across a reboot: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html > > > 3. Wes George (operator) makes a comment that I2RS configuration should > not replace current configuration related to BGP. > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html > > > There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html > > > Multiple clients writing to agents (raised by Himanshu Shah) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html > > > Jeff (chair hat off) states he does not want to have I2rs changing state > tables come from routing protocols (BGP--> I2RS state). He also feel > dynamic state tables should be read-only, and not writable as suggested > by the use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html > > > In the same thread, Sri states the I2RS agent should not provide an > interface to change a table if there is no use-case to support it. > Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri > states " I am yet to see a use-case that requires direct manipulation of > a single dynamic routing-protocol-instance specific route table by > something other than that protocol. I don't believe there should be any > such case." However, here it has been in the BGP use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html > > > Jeff responds to Sri in tends to agree and does not mention the use > case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html > > > Sue Hares > > -----Original Message----- > From: Dean Bogdanovic [mailto:deanb@juniper.net] > Sent: Friday, June 06, 2014 4:03 PM > To: Susan Hares > Cc: t.petch; >; Keyur Patel > (keyupate); Hannes Gredler; Russ White; Susan Hares; > > > Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt > > Susan, > > Many people don't know what NLRI abbreviation stands for (Network Layer > Reachability Information , so writing it out first time would be a good > idea. > > Throughout the text, the requirement number sequence is confusing until > you get to the very and where all requirements are listed and then it > makes sense. > > REQ04: The ability to interact with various policies configured on > the forwarding devices, in order to inform the policies > implemented by the dynamic routing processes. This interaction > should be through existing configuration mechanisms, such as > NETCONF, and should be recorded in the configuration of the local > device so operators are aware of the full policy implemented in > the network from the running configuration. > It is not clear to me if your requirement is that dynamic protocols > should impose persistent policies? It says it should be recorded in the > configuration of the local device. > > I agree that those policies should be visible to operators and other > applications, but not sure if dynamic protocols should be allowed to > implement persistent policies. IMO, those should be ephemeral policies. > So maybe text should look like this > This interaction should be through existing configuration mechanisms, > such as NETCONF, and should be recorded in the running or ephemeral > configuration of the local device so operators are aware of the full > policy implemented in the network from the running configuration. > > I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? > > In general I'm not sure if changing entries by dynamic protocol in RIB > is a good idea. If you plan to change only what is configured on the > local device, then that is OK, but if you start changing entries that > are pushed from other devices in the network, the system would get > unstable. And it looks to me that REQ09 would allow that. > > Dean > > > On Jun 5, 2014, at 4:47 AM, Susan Hares > > wrote: > >> Tom: >> >> I'm glad to change the citation in the abstract. On the authors, > this was >> merge of two drafts. >> >> Sue >> >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Thursday, June 05, 2014 4:35 AM >> To: Susan Hares; i2rs@ietf.org >> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan >> Hares'; rex@cisco.com >> Subject: Re: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >> >> Sue >> >> Currently you have six authors which is too many for an RFC - > someone's >> got to go! For me, this is not just an admin point - when > commenting, >> I like to have one or two names, no more, as the clear pen holders >> whom I can expect to act. Too often, with so many names, everyone >> thinks that someone else will do something and nothing happens, so, in >> all seriousness, I oppose adoption until you sort this out amongst > yourselves. >> >> Note too that you have a citation in the Abstract, again not allowed - >> this can be surprising difficult to get round but get round it you, >> one or more thereof, must. >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Susan Hares" > >> To: > >> Cc: "'Keyur Patel (keyupate)'" > >; "Hannes Gredler" >> >; "Russ White" > >; "'Susan Hares'" >> >; > > >> Sent: Wednesday, June 04, 2014 7:49 PM >> Subject: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >>> Jeff and Ed: >>> >>> This updated draft has all the changes that Keyur Patel promised and >> updates >>> to the reference the current i2rs internet drafts. >>> >>> Would you please do a Working Group adoption call? >>> >>> Thank you, >>> Sue Hares >>> >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On > Behalf Of >>> internet-drafts@ietf.org >>> Sent: Wednesday, June 04, 2014 1:44 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Interface to the Routing System >> Working >>> Group of the IETF. >>> >>> Title : Use Cases for an Interface to BGP Protocol >>> Authors : Keyur Patel >>> Rex Fernando >>> Hannes Gredler >>> Shane Amante >>> Russ White >>> Susan Hares >>> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >>> Pages : 17 >>> Date : 2014-06-04 >>> >>> Abstract: >>> A network routing protocol like BGP is typically configured and >>> analyzed through some form of Command Line Interface (CLI) or >>> NETCONF. These interactions to control BGP and diagnose its >>> operation encompass: configuration of protocol parameters, display >> of >>> protocol data, setting of certain protocol state and debugging of >> the >>> protocol. >>> >>> Interface to the Routing System's (I2RS) Programmatic interfaces, >> as >>> defined in draft-ietf-i2rs-architecture, provides an alternate way >> to >>> control and diagnose the operation of the BGP protocol. I2RS may >> be >>> used for the configuration, manipulation, analyzing or collecting >> the >>> protocol data. This document describes set of use cases for which >>> I2RS can be used for BGP protocol. It is intended to provide a >> base >>> for the solution draft describing a set of interfaces to the BGP >>> protocol. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at > tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > es-03.txt.pdf> > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 17 09:16:37 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD61A0043; Tue, 17 Jun 2014 09:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6m3K5ETixpX; Tue, 17 Jun 2014 09:16:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF051A00A7; Tue, 17 Jun 2014 09:16:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140617161627.10189.83467.idtracker@ietfa.amsl.com> Date: Tue, 17 Jun 2014 09:16:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/bSa3lWm3Q0uCYFvyci-MPTSqCbk Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 16:16:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Use Cases for an Interface to BGP Protocol Authors : Keyur Patel Rex Fernando Hannes Gredler Shane Amante Russ White Susan Hares Filename : draft-keyupate-i2rs-bgp-usecases-03.txt Pages : 21 Date : 2014-06-17 Abstract: A network routing protocol like BGP is typically configured and analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. Interface to the Routing System's (I2RS) Programmatic interfaces provides an alternate way to control and diagnose the operation of the BGP protocol. I2RS may be used for the configuration, manipulation, analyzing or collecting the protocol data. This document describes set of use cases for which I2RS can be used for BGP protocol. It is intended to provide a base for the solution draft describing a set of interfaces to the BGP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 17 09:50:43 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E921A00ED for ; Tue, 17 Jun 2014 09:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F61qduuF0VeX for ; Tue, 17 Jun 2014 09:50:35 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EE93E1A00E8 for ; Tue, 17 Jun 2014 09:50:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B0E21C23D; Tue, 17 Jun 2014 12:50:34 -0400 (EDT) Date: Tue, 17 Jun 2014 12:50:34 -0400 From: Jeffrey Haas To: "t.petch" Message-ID: <20140617165034.GC11842@pfrc> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> <20140617131551.GM31387@pfrc> <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dM6EeDihuFTN82nAzP5lc5GC5-o Cc: Jeffrey Haas , Russ White , 'Edward Crabbe' , 'Susan Hares' , i2rs@ietf.org Subject: Re: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 16:50:35 -0000 On Tue, Jun 17, 2014 at 04:29:51PM +0100, t.petch wrote: > We have just got a netmod-isis draft > draft-litkowski-netmod-isis-cfg-00.txt Thanks, I'll add it to my reading list. > and I look for items of the third type, and at first sight, I do not see > them, just as I cannot recall seeing them in SMI models, either > standards-based or proprietary (unlike the LSDB). Of course > they can be added but .... Already present, but not necessarily in the IGP MIBs: inetCidrRouteProto OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { inetCidrRouteEntry 9 } Multiple route candidates don't show up in this sort of MIB due to the excruciating details of the abstract indices. (AKA "why we don't want to do SNMP for this stuff any more".) -- Jeff From nobody Tue Jun 17 10:01:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110351A00F8 for ; Tue, 17 Jun 2014 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYKL_0eilFty for ; Tue, 17 Jun 2014 10:01:49 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 012EE1A00A7 for ; Tue, 17 Jun 2014 10:01:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Jeffrey Haas'" , "'t.petch'" References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> <20140617131551.GM31387@pfrc> <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> <20140617165034.GC11842@pfrc> In-Reply-To: <20140617165034.GC11842@pfrc> Date: Tue, 17 Jun 2014 13:01:35 -0400 Message-ID: <004501cf8a4d$cc6304f0$65290ed0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK5VOIf05CTwB1oThINzfr06mO3ogIbOvLqAX03oZkCJJWJkQJNYI6uARZcurYBXwiQOZlN8uxg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/smVqoDohYYjpsMlsdWKMA8BUoDM Cc: 'Russ White' , i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:01:50 -0000 Jeff: +1 on adding netmod-isis-cfg-00.txt to my reading list. +1! On the SNMP and MIB indexes. Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Tuesday, June 17, 2014 12:51 PM To: t.petch Cc: Jeffrey Haas; Russ White; 'Susan Hares'; i2rs@ietf.org; 'Edward Crabbe' Subject: Re: tables was: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted On Tue, Jun 17, 2014 at 04:29:51PM +0100, t.petch wrote: > We have just got a netmod-isis draft > draft-litkowski-netmod-isis-cfg-00.txt Thanks, I'll add it to my reading list. > and I look for items of the third type, and at first sight, I do not > see them, just as I cannot recall seeing them in SMI models, either > standards-based or proprietary (unlike the LSDB). Of course they can > be added but .... Already present, but not necessarily in the IGP MIBs: inetCidrRouteProto OBJECT-TYPE SYNTAX IANAipRouteProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." ::= { inetCidrRouteEntry 9 } Multiple route candidates don't show up in this sort of MIB due to the excruciating details of the abstract indices. (AKA "why we don't want to do SNMP for this stuff any more".) -- Jeff From nobody Tue Jun 17 10:13:10 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DEC1A00F8 for ; Tue, 17 Jun 2014 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf3PwJ4E_Ojh for ; Tue, 17 Jun 2014 10:13:04 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8E1A00D7 for ; Tue, 17 Jun 2014 10:13:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: Date: Tue, 17 Jun 2014 13:12:45 -0400 Message-ID: <004d01cf8a4f$5c10d450$14327cf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01CF8A2D.D4FFA980" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+KTngAgK+ufKAmQa+2VrQhPNKOcg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Dyou178jqy3nwrt7ANi2h9A31O8 Cc: 'Jeffrey Haas' , Edward Crabbe , 'Alia Atlas' Subject: [i2rs] Security Considerations interim draft posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:13:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004E_01CF8A2D.D4FFA980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WG adoption call by the chairs for the Security Considerations draft surprised the security discussion group that had been working on it. The reason for the large author list is this document is the product of this security discussion group. This discussion group had been working on a revision in the works to the very drafty -00.txt. The chairs action spurred this slow moving discussion group to action. This revision provides the WG with an updated version of the draft, but the discussion group does not feel this version is ready for WG adoption. The coauthors on the draft are still debating some of the text. My co-authors represent the appreciate your comments, and will try to incorporate these comments in the next version coming out next Monday 6/24/14. http://www.ietf.org/internet-drafts/draft-hares-i2rs-security-01.txt Sue Hares ------=_NextPart_000_004E_01CF8A2D.D4FFA980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The WG adoption call by the chairs = for the Security Considerations draft surprised the security discussion = group that had been working on it. The reason for the large author list = is this document is the product of this security discussion group.  = This discussion group had been working on a revision in the works to the = very drafty -00.txt.  The chairs action spurred this slow moving = discussion group to action.  This revision provides the WG with an = updated version of the draft, but the discussion group does not feel = this version is ready for WG adoption.  The coauthors on the draft = are still debating some of the text.   My co-authors represent = the appreciate your comments, and will try to incorporate these comments = in the next version coming out next Monday = 6/24/14.

 

http://www.ietf.org/internet-drafts/draft-hares-i2rs-security-01.txt=

 

Sue Hares =

 

------=_NextPart_000_004E_01CF8A2D.D4FFA980-- From nobody Tue Jun 17 10:17:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58ABD1A00D7 for ; Tue, 17 Jun 2014 10:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.546 X-Spam-Level: * X-Spam-Status: No, score=1.546 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l1N7qfT00GL for ; Tue, 17 Jun 2014 10:17:13 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1CE1A00FD for ; Tue, 17 Jun 2014 10:17:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.216.66; From: "Susan Hares" To: "'Joel M. Halpern'" , "'t.petch'" , "'Dean Bogdanovic'" References: <20140604174423.25048.19110.idtracker@ietfa.amsl.com> <005101cf8025$b7cc2b70$27648250$@ndzh.com> <010001cf8099$1c8ba860$4001a8c0@gateway.2wire.net> <004301cf809a$c5d6a090$5183e1b0$@ndzh.com> <8368317D-0E4F-4D6A-8B5C-9366E0F5FC1C@juniper.net> <00ce01cf85da$ce8b8ad0$6ba2a070$@ndzh.com> <41EEF4CB-4694-4617-B2BF-71F89237AB1D@juniper.net> <017b01cf8751$5e9e3100$1bda9300$@ndzh.com> <022701cf8a0f$8ba93b20$4001a8c0@gateway.2wire.net> <53A0695D.6090309@joelhalpern.com> In-Reply-To: <53A0695D.6090309@joelhalpern.com> Date: Tue, 17 Jun 2014 13:16:41 -0400 Message-ID: <005c01cf8a4f$e8c444e0$ba4ccea0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01CF8A2E.61B8BF60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHsFk5zAvf2vS9rxXc9LGt7Dvw7qAGayTg4AbY3QWQChw5Z8wECQGW8AliOGgEC5qgM2ADyF94EAZuwcWgCMD9+bgJuuPCDmqIzyTA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/uWjq46i59Bv5Wo0ayUSOGVyomvw Cc: i2rs@ietf.org, 'Susan Hares' , rex@cisco.com, "'Keyur Patel \(keyupate\)'" , 'Hannes Gredler' , 'Russ White' Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:17:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005D_01CF8A2E.61B8BF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joel, Tom and Dean: I've released draft-keyupate-i2rs-bgp-usecases-03.txt as an updated, but it does not any fixes to the requirements that you-all and Lada suggested. Since we are commenting on text that is not online, I've updated the online text. My very high level summary of the issues are: 1) Use cases have specified write between I2RS and configuration store; and this should be removed from the next version of draft-keyupate-i2rs-bgp-usecases-03.txt 2) The requirements as specified in draft-keyupate-i2rs-bgp-usecases-03.txt overlap. Although I think we all agree on #1, I will start a separate mail topic on each of these questions. Thank you for all your comments, Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, June 17, 2014 12:14 PM To: t.petch; Dean Bogdanovic; Susan Hares Cc: i2rs@ietf.org; Susan Hares; rex@cisco.com; Keyur Patel (keyupate); Hannes Gredler; Russ White Subject: Re: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt I REALLY do not want I2RS getting into writing persistent storage. It creates many complications in implementing I2RS and in maintaining system state. it also interacts interestingly with configuration maintenance. (Yes, I2RS itself itneracts interestingly there, but at least that does not affect the reboot state.) Yours, Joel On 6/17/14, 5:35 AM, t.petch wrote: > ----- Original Message ----- > From: "Dean Bogdanovic" < deanb@juniper.net> > To: "Susan Hares" < shares@ndzh.com> > Sent: Friday, June 13, 2014 11:06 PM > > Susan, > > My answer to your question > do we ever let I2RS upon a command transfer policies to the persistent > storage? > > My initial answer is no. And reason is security. Network admins want > to know exact state of the device after rebooting. If we want to allow > transfer of policies, then we would have to define roles and which > roles would be allowed to do that transfer. We are making things more > complex, when there are existing mechanisms for admins to do that. > > > The counter argument to this is having got it right once, for some, > perhaps large, instantiation of an I2RS it, do you want to have to do > it all over again? > > That is, I agree that after reboot, an operator should know that the > box is in the state defined by the NETCONF startup configuration > datastore with nothing added but that there may be a valid case for > saying that all the changes downloaded by I2RS remain stored, but not > applied, eg in a candidate I2RS datastore, which can then be copied to > the running I2RS datastore when the operator is satisfied that the time is right. > > Just a thought. > > Tom Petch > > > > > > > > > > Dean > > On Jun 13, 2014, at 5:49 PM, Susan Hares > < shares@ndzh.com> wrote: > > Dean: > Thank you for your thoughtful answer. I was looking for it, but I'm > glad you watched Croatia (I'm sorry about Croatia's loss). > > I agree with the types of policies and the status: persistent, > transient, and ephemeral. However, do we ever let I2RS upon a command > transfer policies to the persistent storage? This what I read in REQ04. > In reading the email, I'm not sure how to summarize the WG's approach. > My answer would be "no", but if this is a WG document the answer needs > to come from the WG. > > Sue > > From: i2rs [ mailto:i2rs-bounces@ietf.org] On > Behalf Of Dean Bogdanovic > Sent: Friday, June 13, 2014 2:44 PM > To: Susan Hares > Cc: < i2rs@ietf.org>; Susan Hares; > < rex@cisco.com>; t.petch; Keyur Patel > (keyupate); Hannes Gredler; Russ White > Subject: Re: [i2rs] I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Susan, > > Sorry for late reply, but yesterday started a very significant > quadrennial event (FIFA World Cup) and Croatia played (and lost with > help of the referee). > > WRT REQ04, I agree with the posts and here are few thoughts on this > > We should try to divide policies into few categories. > > 1. persistent > There is a set of policies that have to be available from very start > on the device. Those policies should be persistent on the device and I > see them changing infrequently. IMO, there is no need for I2RS to > manage those policies, readonly access is sufficient. > 2. transient > Policies that are temporary defining some fwd behavior of device. I > can see lot of cases where different applications based on some > network conditions want to change forwarding behavior. Those should > not be available after reboot. > 3. locally defined > by this I mean policies that defined by admin, applications through > local I2RS agent. These can be transient and persistent, where I would > classify that I2RS agent policies are only transient. Actually after > rereading this, I would even consider policies defined by I2RS as > remotely defined and therefore transient. > 4. remotely defined > by this I mean policies pushed from a different device (policy server, > router) via some protocol (DIAMETER, RADIUS, BGP). IMO, those should > be always ephemeral. > > Dean > > On Jun 11, 2014, at 9:08 PM, Susan Hares > < shares@ndzh.com> wrote: > > > Dean: > > I combined REQ01/02 and REQ08/09. I've put the requirements in the > front of the text. Please let know if have any suggestions on these > approved changes. I wait 24 hours, and then spin the draft. > > On the agreement on REQ04, I cannot find a firm consensus. I would > ask Jeff Haas or Ed Crabbe to indicate if they think there is a > consensus on the WG. I highlight a few messages below. The document is > proposed for WG consensus so I will change it if the WG has consensus. > > > Sue Hares > > > Search for Consensus > ===== > Based on your comment, I sent looking for WG Direction regarding BGP or > I2RS putting state. I cannot find it. BGP has a Flow specification > (RFC5575). Where do you think those flow specifications end up? > Writing into runtime configuration state? Writing into something like > I2RS running data store? BGP ORFs might be kept in the BGP state or > in associated features (Add/delete) in BGP, but Flow specifications > are targeted toward data flow. > > On the list I could find the following: > > 1. I2RS BGP state to configuration - Wes George (operator) makes a > comment that I2RS configuration should not replace current > configuration related to BGP. > > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html > > > > 2. There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) - is the debate for the architecture document regarding > keeping state in the I2RS > Begin: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html > > Joel's: no state across a reboot: > http://www.ietf.org/mail-archive/web/i2rs/current/msg01034.html > > > 3. Wes George (operator) makes a comment that I2RS configuration > should not replace current configuration related to BGP. > http://www.ietf.org/mail-archive/web/i2rs/current/msg00826.html > > > There is the Architecture Discussion 2: Persistence (ephemeral vs. > permanent) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01027.html > > > Multiple clients writing to agents (raised by Himanshu Shah) > http://www.ietf.org/mail-archive/web/i2rs/current/msg01139.html > > > Jeff (chair hat off) states he does not want to have I2rs changing > state tables come from routing protocols (BGP--> I2RS state). He also > feel dynamic state tables should be read-only, and not writable as > suggested by the use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01666.html > > > In the same thread, Sri states the I2RS agent should not provide an > interface to change a table if there is no use-case to support it. > Dynamic protocols --> I2RS (I2RS read only). I2RS--> RIB-IM. Sri > states " I am yet to see a use-case that requires direct manipulation > of a single dynamic routing-protocol-instance specific route table by > something other than that protocol. I don't believe there should be any > such case." However, here it has been in the BGP use case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01671.html > > > Jeff responds to Sri in tends to agree and does not mention the use > case. > http://www.ietf.org/mail-archive/web/i2rs/current/msg01752.html > > > Sue Hares > > -----Original Message----- > From: Dean Bogdanovic [ mailto:deanb@juniper.net] > Sent: Friday, June 06, 2014 4:03 PM > To: Susan Hares > Cc: t.petch; < i2rs@ietf.org>; Keyur Patel > (keyupate); Hannes Gredler; Russ White; Susan Hares; > < rex@cisco.com> > Subject: Re: [i2rs] I-D Action: > draft-keyupate-i2rs-bgp-usecases-02.txt > > Susan, > > Many people don't know what NLRI abbreviation stands for (Network > Layer Reachability Information , so writing it out first time would be > a good idea. > > Throughout the text, the requirement number sequence is confusing > until you get to the very and where all requirements are listed and > then it makes sense. > > REQ04: The ability to interact with various policies configured on > the forwarding devices, in order to inform the policies > implemented by the dynamic routing processes. This interaction > should be through existing configuration mechanisms, such as > NETCONF, and should be recorded in the configuration of the local > device so operators are aware of the full policy implemented in > the network from the running configuration. > It is not clear to me if your requirement is that dynamic protocols > should impose persistent policies? It says it should be recorded in > the configuration of the local device. > > I agree that those policies should be visible to operators and other > applications, but not sure if dynamic protocols should be allowed to > implement persistent policies. IMO, those should be ephemeral policies. > So maybe text should look like this > This interaction should be through existing configuration mechanisms, > such as NETCONF, and should be recorded in the running or ephemeral > configuration of the local device so operators are aware of the full > policy implemented in the network from the running configuration. > > I'm trying to see major difference between REQ01/REQ02 and REQ08/REQ09? > > In general I'm not sure if changing entries by dynamic protocol in RIB > is a good idea. If you plan to change only what is configured on the > local device, then that is OK, but if you start changing entries that > are pushed from other devices in the network, the system would get > unstable. And it looks to me that REQ09 would allow that. > > Dean > > > On Jun 5, 2014, at 4:47 AM, Susan Hares > < shares@ndzh.com> wrote: > >> Tom: >> >> I'm glad to change the citation in the abstract. On the authors, > this was >> merge of two drafts. >> >> Sue >> >> -----Original Message----- >> From: t.petch [ mailto:ietfc@btconnect.com] >> Sent: Thursday, June 05, 2014 4:35 AM >> To: Susan Hares; i2rs@ietf.org >> Cc: 'Keyur Patel (keyupate)'; Hannes Gredler; Russ White; 'Susan >> Hares'; rex@cisco.com >> Subject: Re: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >> >> Sue >> >> Currently you have six authors which is too many for an RFC - > someone's >> got to go! For me, this is not just an admin point - when > commenting, >> I like to have one or two names, no more, as the clear pen holders >> whom I can expect to act. Too often, with so many names, everyone >> thinks that someone else will do something and nothing happens, so, >> in all seriousness, I oppose adoption until you sort this out amongst > yourselves. >> >> Note too that you have a citation in the Abstract, again not allowed >> - this can be surprising difficult to get round but get round it you, >> one or more thereof, must. >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Susan Hares" < shares@ndzh.com> >> To: < i2rs@ietf.org> >> Cc: "'Keyur Patel (keyupate)'" > < keyupate@cisco.com>; "Hannes Gredler" >> < hannes@juniper.net>; "Russ White" > < russw@riw.us>; "'Susan Hares'" >> < skh@ndzh.com>; > < rex@cisco.com> >> Sent: Wednesday, June 04, 2014 7:49 PM >> Subject: [i2rs] FW: I-D Action: >> draft-keyupate-i2rs-bgp-usecases-02.txt >> >> >>> Jeff and Ed: >>> >>> This updated draft has all the changes that Keyur Patel promised and >> updates >>> to the reference the current i2rs internet drafts. >>> >>> Would you please do a Working Group adoption call? >>> >>> Thank you, >>> Sue Hares >>> >>> >>> -----Original Message----- >>> From: i2rs [ mailto:i2rs-bounces@ietf.org] >>> On > Behalf Of >>> internet-drafts@ietf.org >>> Sent: Wednesday, June 04, 2014 1:44 PM >>> To: i-d-announce@ietf.org >>> Cc: i2rs@ietf.org >>> Subject: [i2rs] I-D Action: draft-keyupate-i2rs-bgp-usecases-02.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Interface to the Routing System >> Working >>> Group of the IETF. >>> >>> Title : Use Cases for an Interface to BGP Protocol >>> Authors : Keyur Patel >>> Rex Fernando >>> Hannes Gredler >>> Shane Amante >>> Russ White >>> Susan Hares >>> Filename : draft-keyupate-i2rs-bgp-usecases-02.txt >>> Pages : 17 >>> Date : 2014-06-04 >>> >>> Abstract: >>> A network routing protocol like BGP is typically configured and >>> analyzed through some form of Command Line Interface (CLI) or >>> NETCONF. These interactions to control BGP and diagnose its >>> operation encompass: configuration of protocol parameters, >>> display >> of >>> protocol data, setting of certain protocol state and debugging of >> the >>> protocol. >>> >>> Interface to the Routing System's (I2RS) Programmatic interfaces, >> as >>> defined in draft-ietf-i2rs-architecture, provides an alternate >>> way >> to >>> control and diagnose the operation of the BGP protocol. I2RS may >> be >>> used for the configuration, manipulation, analyzing or collecting >> the >>> protocol data. This document describes set of use cases for which >>> I2RS can be used for BGP protocol. It is intended to provide a >> base >>> for the solution draft describing a set of interfaces to the BGP >>> protocol. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-keyupate-i2rs-bgp-usecases/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-keyupate-i2rs-bgp-usecases-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at > tools.ietf.org< http://tools.ietf.org>. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > as > es-03.txt.pdf> > > > > _______________________________________________ > 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 ------=_NextPart_000_005D_01CF8A2E.61B8BF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joel, Tom and Dean: =

 

I've released = draft-keyupate-i2rs-bgp-usecases-03.txt as an updated, but it does not = any fixes to the requirements that you-all and Lada suggested.  = Since we are commenting on text that is not online, I’ve updated = the online text. My very high level summary of the issues are: =

  

1) Use cases have = specified write between I2RS and configuration store; and this should be = removed from the next version of = draft-keyupate-i2rs-bgp-usecases-03.txt

 

2) The requirements = as specified in draft-keyupate-i2rs-bgp-usecases-03.txt overlap. =

 

Although I think we = all agree on #1, I will start a separate mail topic on each of these = questions.

 

Thank you for all = your comments,

 

Sue Hares =

 

 

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: = Tuesday, June 17, 2014 12:14 PM
To: t.petch; Dean Bogdanovic; Susan = Hares
Cc: i2rs@ietf.org; Susan Hares; rex@cisco.com; Keyur Patel = (keyupate); Hannes Gredler; Russ White
Subject: Re: [i2rs] I-D = Action: draft-keyupate-i2rs-bgp-usecases-02.txt

 

I = REALLY do not want I2RS getting into writing persistent storage.  = It creates many complications in implementing I2RS and in maintaining = system state.  it also interacts interestingly with configuration = maintenance.  (Yes, I2RS itself itneracts interestingly there, but = at least that does not affect the reboot state.)

 

Yours,

Joel

 

On = 6/17/14, 5:35 AM, t.petch wrote:

> ----- Original Message -----

> From: "Dean Bogdanovic" <deanb@juniper.net<= /a>>

> To: "Susan = Hares" <shares@ndzh.com>

> Sent: Friday, June 13, = 2014 11:06 PM

> 

> Susan,

> 

> My answer  to your = question

> do we ever let I2RS = upon a command transfer policies to the persistent

> storage?

> 

> My initial answer is no. And reason is = security. Network admins want

> to know exact state of the device after = rebooting. If we want to allow

> transfer of policies, then we would have to = define roles and which

> roles = would be allowed to do that transfer. We are making things more =

> complex, when there are = existing mechanisms for admins to do that.

> 

> <tp>

> The counter argument to this is having got it = right once, for some,

> = perhaps large, instantiation of an I2RS it, do you want to have to do =

> it all over = again?

> 

> That is, I agree that after reboot, an = operator should know that the

> box is in the state defined by the NETCONF = startup configuration

> = datastore with nothing added but that there may be a valid case for =

> saying that all the changes = downloaded by I2RS remain stored, but not

> applied, eg in a candidate I2RS datastore, = which can then be copied to

> = the running I2RS datastore when the operator is satisfied that the time = is right.

> 

> Just a thought.

> 

> Tom Petch

> 

> 

> 

> 

> 

> 

> 

> 

> 

> Dean

> 

> On Jun 13, 2014, at 5:49 PM, Susan Hares =

> <shares@ndzh.com<mailto= :shares@ndzh.com>> wrote:

> 

> Dean:

> Thank you for your thoughtful answer.  I = was looking for it, but I’m

> glad you watched Croatia (I’m sorry = about Croatia’s loss).

> 

> I agree with the types of policies and the = status: persistent,

> = transient, and ephemeral.  However, do we ever let I2RS upon a = command

> transfer policies to = the persistent storage?  This what I read in = REQ04.

> In reading the email, = I’m not sure how to summarize the WG’s = approach.

> My answer would be = “no”, but if this is a WG document the answer needs =

> to come from the = WG.

> 

> Sue

> 

> From: i2rs [mailto:i2rs-bounces@ietf.= org<mailto:bounces@ietf.org>] On

> Behalf Of Dean Bogdanovic

> Sent: Friday, June 13, 2014 2:44 = PM

> To: Susan = Hares

> Cc: <i2rs@ietf.org<mailto:i= 2rs@ietf.org>>; Susan Hares;

> <rex@cisco.com<mailto:r= ex@cisco.com>>; t.petch; Keyur Patel

> (keyupate); Hannes Gredler; Russ = White

> Subject: Re: [i2rs] I-D = Action:

> = draft-keyupate-i2rs-bgp-usecases-02.txt

> 

> Susan,

> 

> Sorry for late reply, but yesterday started a = very significant

> quadrennial = event (FIFA World Cup) and Croatia played (and lost with =

> help of the = referee).

> 

> WRT REQ04, I agree with the posts and here are = few thoughts on this

> 

> We should try to divide policies into few = categories.

> 

> 1. persistent

> There is a set of policies that have to be = available from very start

> on = the device. Those policies should be persistent on the device and I =

> see them changing = infrequently. IMO, there is no need for I2RS to

> manage those policies, readonly access is = sufficient.

> 2. = transient

> Policies that are = temporary defining some fwd behavior of device. I

> can see lot of cases where different = applications based on some

> = network conditions want to change forwarding behavior. Those should =

> not be available after = reboot.

> 3. locally = defined

> by this I mean = policies that defined by admin, applications through

> local I2RS agent. These can be transient and = persistent, where I would

> = classify that I2RS agent policies are only transient. Actually after =

> rereading this, I would even = consider policies defined by I2RS as

> remotely defined and therefore = transient.

> 4. remotely = defined

> by this I mean = policies pushed from a different device (policy server,

> router) via some protocol (DIAMETER, RADIUS, = BGP). IMO, those should

> be = always ephemeral.

> 

> Dean

> 

> On Jun 11, 2014, at 9:08 PM, Susan Hares =

> <shares@ndzh.com<mailto= :shares@ndzh.com>> wrote:

> 

> 

> Dean:

> 

> I combined REQ01/02 and REQ08/09.  I've = put the requirements in the

> = front of the text.  Please let know if have any suggestions on = these

> approved = changes.  I wait 24 hours, and then spin the = draft.

> 

> On the agreement on REQ04, I cannot find a = firm consensus.  I would

> ask Jeff Haas or Ed Crabbe to indicate if they = think there is a

> consensus = on the WG. I highlight a few messages below. The document is =

> proposed for WG consensus so = I will change it if the WG has consensus.

> 

> 

> Sue Hares

> 

> 

> Search for Consensus

> =3D=3D=3D=3D=3D

> Based on your comment, I sent looking for WG = Direction regarding BGP or

> = I2RS putting state.   I cannot find it.  BGP has a Flow = specification

> = (RFC5575).  Where do you think those flow specifications end = up?

> Writing into runtime = configuration state? Writing into something like

> I2RS running data store?  BGP ORFs might = be kept in the BGP state or

> = in associated features (Add/delete) in BGP, but Flow specifications =

> are targeted toward data = flow.

> 

> On the list I could find the = following:

> 

> 1. I2RS BGP state to configuration - Wes = George (operator) makes a

> = comment that I2RS configuration should not replace current =

> configuration related to = BGP.

> 

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg00826.html

> 

> 

> 

> 2. There is the Architecture Discussion 2: = Persistence (ephemeral vs.

> = permanent) - is the debate for the architecture document regarding =

> keeping state in the = I2RS

> Begin:

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01027.html

> 

> Joel's: no state across a = reboot:

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01034.html

> 

> 

> 3. Wes George (operator) makes a comment that = I2RS configuration

> should = not replace current configuration related to BGP.

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg00826.html

> 

> 

> There is the Architecture Discussion 2: = Persistence (ephemeral vs.

> = permanent)

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01027.html

> 

> 

> Multiple clients writing to agents (raised by = Himanshu Shah)

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01139.html

> 

> 

> Jeff (chair hat off) states he does not want = to have I2rs changing

> state = tables come from routing protocols (BGP--> I2RS state).  He also =

> feel dynamic state tables = should be read-only, and not writable as

> suggested by the use case.

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01666.html

> 

> 

> In the same thread, Sri states the I2RS agent = should not provide an

> = interface to change a table if there is no use-case to support = it.

> Dynamic protocols --> = I2RS (I2RS read only).  I2RS--> RIB-IM.   = Sri

> states " I am yet to = see a use-case that requires direct manipulation

> of a single dynamic routing-protocol-instance = specific route table by

> = something other than that protocol. I don't believe there should be = any

> such = case."    However, here it has been in the BGP use = case.

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01671.html

> 

> 

> Jeff responds to Sri in tends to agree and = does not mention the use

> = case.

> = http://www.ietf.org/mail-= archive/web/i2rs/current/msg01752.html

> 

> 

> Sue Hares

> 

> -----Original Message-----

> From: Dean Bogdanovic [mailto:deanb@juniper.net&= lt;http://juniper.net>]

> Sent: Friday, June 06, 2014 4:03 = PM

> To: Susan = Hares

> Cc: t.petch; <i2rs@ietf.org<mailto:i= 2rs@ietf.org>>; Keyur Patel

> (keyupate); Hannes Gredler; Russ White; Susan = Hares;

> <rex@cisco.com<mailto:r= ex@cisco.com>>

> Subject: Re: [i2rs] I-D Action: =

> = draft-keyupate-i2rs-bgp-usecases-02.txt

> 

> Susan,

> 

> Many people don't know what NLRI abbreviation = stands for (Network

> Layer = Reachability Information , so writing it out first time would be =

> a good = idea.

> 

> Throughout the text, the requirement number = sequence is confusing

> until = you get to the very and where all requirements are listed and =

> then it makes = sense.

> 

> REQ04: The ability to interact with various = policies configured on

>        the = forwarding devices, in order to inform the policies

>        = implemented by the dynamic routing processes.  This = interaction

>        = should be through existing configuration mechanisms, such = as

>        = NETCONF, and should be recorded in the configuration of the = local

>        = device so operators are aware of the full policy implemented = in

>        the = network from the running configuration.

> It is not clear to me if your requirement is = that dynamic protocols

> = should impose persistent policies? It says it should be recorded in =

> the configuration of the = local device.

> 

> I agree that those policies should be visible = to operators and other

> = applications, but not sure if dynamic protocols should be allowed to =

> implement persistent = policies. IMO, those should be ephemeral policies.

> So maybe text should look like = this

> This interaction should = be through existing configuration mechanisms,

> such as NETCONF, and should be recorded in the = running or ephemeral

> = configuration of the local device so operators are aware of the full =

> policy implemented in the = network from the running configuration.

> 

> I'm trying to see major difference between = REQ01/REQ02 and REQ08/REQ09?

> 

> In general I'm not sure if changing entries by = dynamic protocol in RIB

> is a = good idea. If you plan to change only what is configured on the =

> local device, then that is = OK, but if you start changing entries that

> are pushed from other devices in the network, = the system would get

> = unstable. And it looks to me that REQ09 would allow = that.

> 

> Dean

> 

> 

> On Jun 5, 2014, at 4:47 AM, Susan Hares =

> <shares@ndzh.com<mailto= :shares@ndzh.com>> wrote:

> 

>> Tom:

>> 

>> I'm glad to change the citation in the = abstract.    On the authors,

> this was

>> merge of two drafts.

>> 

>> Sue

>> 

>> -----Original = Message-----

>> From: = t.petch [mailto:ietfc@btconnect.co= m<http://btconnect.com>]

>> Sent: Thursday, June 05, 2014 4:35 = AM

>> To: Susan Hares; i2rs@ietf.org<mailto:i= 2rs@ietf.org>

>> Cc: 'Keyur Patel (keyupate)'; Hannes = Gredler; Russ White; 'Susan

>> Hares'; rex@cisco.com<mailto:r= ex@cisco.com>

>> Subject: Re: [i2rs] FW: I-D = Action:

>> = draft-keyupate-i2rs-bgp-usecases-02.txt

>> 

>> Sue

>> 

>> Currently you have six authors which is = too many for an RFC -

> = someone's

>> got to = go!   For me, this is not just an admin point - = when

> = commenting,

>> I like to = have one or two names, no more, as the clear pen holders =

>> whom I can expect to = act.  Too often, with so many names, everyone

>> thinks that someone else will do something = and nothing happens, so,

>> = in all seriousness, I oppose adoption until you sort this out = amongst

> = yourselves.

>> 

>> Note too that you have a citation in the = Abstract, again not allowed

>> - this can be surprising difficult to get = round but get round it you,

>> one or more thereof, = must.

>> 

>> Tom Petch

>> 

>> 

>> ----- Original Message = -----

>> From: "Susan = Hares" <shares@ndzh.com<mailto= :shares@ndzh.com>>

>> To: <i2rs@ietf.org<mailto:i= 2rs@ietf.org>>

>> Cc: "'Keyur Patel = (keyupate)'"

> <keyupate@cisco.com<mai= lto:keyupate@cisco.com>>; "Hannes = Gredler"

>> <hannes@juniper.net<mai= lto:hannes@juniper.net>>; "Russ = White"

> <russw@riw.us<mailto:ru= ssw@riw.us>>; "'Susan = Hares'"

>> <skh@ndzh.com<mailto:sk= h@ndzh.com>>;

> <rex@cisco.com<mailto:r= ex@cisco.com>>

>> Sent: Wednesday, June 04, 2014 7:49 = PM

>> Subject: [i2rs] FW: = I-D Action:

>> = draft-keyupate-i2rs-bgp-usecases-02.txt

>> 

>> 

>>> Jeff and Ed:

>>> 

>>> This updated draft has all the changes = that Keyur Patel promised and

>> updates

>>> to the reference the current i2rs = internet drafts.

>>> 

>>> Would you please do a Working Group = adoption call?

>>> 

>>> Thank you,

>>> Sue Hares

>>> 

>>> 

>>> -----Original = Message-----

>>> From: = i2rs [mailto:i2rs-bounces@ietf.= org<mailto:bounces@ietf.org>]

>>> On

> Behalf Of

>>> internet-drafts@ietf.org&= lt;mailto:internet-drafts@ietf.org>

>>> Sent: Wednesday, June 04, 2014 1:44 = PM

>>> To: i-d-announce@ietf.org<= mailto:i-d-announce@ietf.org>

>>> Cc: i2rs@ietf.org<mailto:i= 2rs@ietf.org>

>>> Subject: [i2rs] I-D Action: = draft-keyupate-i2rs-bgp-usecases-02.txt

>>> 

>>> 

>>> A New Internet-Draft is available from = the on-line Internet-Drafts

>>> directories.

>>> This draft is a work item of the = Interface to the Routing System

>> Working

>>> Group of the IETF.

>>> 

>>>      &nbs= p;  = Title           : Use = Cases for an Interface to BGP Protocol

>>>      &nbs= p;  Authors         : Keyur = Patel

>>>      &nbs= p;            = ;        Rex = Fernando

>>>      &nbs= p;            = ;        Hannes = Gredler

>>>      &nbs= p;            = ;        Shane = Amante

>>>      &nbs= p;            = ;        Russ White

>>>      &nbs= p;            = ;        Susan Hares

>>> = Filename        : = draft-keyupate-i2rs-bgp-usecases-02.txt

>>> Pages     =       : 17

>>> = Date            : = 2014-06-04

>>> 

>>> Abstract:

>>>    A network routing = protocol like BGP is typically configured and

>>>    analyzed through = some form of Command Line Interface (CLI) or

>>>    NETCONF.  These = interactions to control BGP and diagnose its

>>>    operation encompass: = configuration of protocol parameters,

>>> display

>> of

>>>    protocol data, = setting of certain protocol state and debugging of

>> the

>>>    = protocol.

>>> 

>>>    Interface to the = Routing System's (I2RS) Programmatic interfaces,

>> as

>>>    defined in = draft-ietf-i2rs-architecture, provides an alternate

>>> way

>> to

>>>    control and diagnose = the operation of the BGP protocol.  I2RS may

>> be

>>>    used for the = configuration, manipulation, analyzing or collecting

>> the

>>>    protocol data.  = This document describes set of use cases for which

>>>    I2RS can be used for = BGP protocol.  It is intended to provide a

>> base

>>>    for the solution = draft describing a set of interfaces to the BGP

>>>    = protocol.

>>> 

>>> 

>>> The IETF datatracker status page for = this draft is:

>>> https://datatracker.ietf.= org/doc/draft-keyupate-i2rs-bgp-usecases/

>>> 

>>> There's also a htmlized version = available at:

>>> <= span = style=3D'color:windowtext;text-decoration:none'>http://tools.ietf.org/htm= l/draft-keyupate-i2rs-bgp-usecases-02

>>> 

>>> A diff from the previous version is = available at:

>>> http://www.ietf.org/rfcdi= ff?url2=3Ddraft-keyupate-i2rs-bgp-usecases-02

>>> 

>>> 

>>> Please note that it may take a couple = of minutes from the time of

>> submission

>>> until the htmlized version and diff = are available at

> = tools.ietf.org<http://tools.ietf.org>.

>>> 

>>> Internet-Drafts are also available by = anonymous FTP at:

>>> ftp://ftp.ietf.org/intern= et-drafts/

>>> 

>>> = _______________________________________________

>>> i2rs mailing list

>>> i2rs@ietf.org<mailto:i= 2rs@ietf.org>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>>> 

>>> = _______________________________________________

>>> i2rs mailing list

>>> i2rs@ietf.org<mailto:i= 2rs@ietf.org>

>>> https://www.ietf.org/mail= man/listinfo/i2rs

>>> 

>> 

>> 

>> = _______________________________________________

>> i2rs mailing list

>> i2rs@ietf.org<mailto:i= 2rs@ietf.org>

>> https://www.ietf.org/mail= man/listinfo/i2rs

> 

> = <draft-keyupate-i2rs-bgp-usecases-03.txt><draft-keyupate-i2rs-bg= p-usec

> as

> es-03.txt.pdf>

> 

> 

> 

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/i2rs

> 

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_005D_01CF8A2E.61B8BF60-- From nobody Thu Jun 19 02:15:41 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE361A008C for ; Thu, 19 Jun 2014 02:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikySerYD3Mdj for ; Thu, 19 Jun 2014 02:15:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09821A007C for ; Thu, 19 Jun 2014 02:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1F03C54073B; Thu, 19 Jun 2014 11:15:34 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ver7Md1GKyeo; Thu, 19 Jun 2014 11:15:28 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EF44D5401FC; Thu, 19 Jun 2014 11:15:26 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , Jeffrey Haas In-Reply-To: <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <055f01cf8708$49597000$dc0c5000$@riw.us> <01f801cf8a0e$32d48f00$4001a8c0@gateway.2wire.net> <20140617131551.GM31387@pfrc> <011801cf8a41$688fde00$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 19 Jun 2014 11:15:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/hIPMzrSLtI_PJ9B94Jk-oJ_dQ5M Cc: Russ White , i2rs@ietf.org, 'Edward Crabbe' , 'Susan Hares' , 'Jeffrey Haas' Subject: Re: [i2rs] tables was: Re: draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 09:15:40 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: "Russ White" ; "'Susan Hares'" ; > ; "'Jeffrey Haas'" ; "'Edward Crabbe'" > > Sent: Tuesday, June 17, 2014 2:15 PM > Subject: Re: tables was: Re: [i2rs] draft-white-i2rs-use-case-05.txt has > been posted > > >> On Tue, Jun 17, 2014 at 10:11:01AM +0100, t.petch wrote: >> > It is B that I am doubtful about. It is fine for BGP or RIP, but I > do >> > not see it for link state protocols, that is for me, the SPT is not > a >> > table of routes, backup routes and so on but, well shortest paths. >> > >> > Do you see an IS-IS, or OSPF, table comparable to the BGP table? >> >> Without making specific comment on what *should* be present in the > model, >> there are three classes of clearly (IMO) useful information available > from >> the IGPs: >> >> - The LSDB, which provides topology >> - The TEDB >> - The active route for a given destination at a given node as per SPF >> computations. >> >> The third item is RIB-like and is the usual input to broader router >> route-selection of an active path from multiple candidates. >> >> The third item will probably have tie-in to our RIB models. >> >> The first two items are places where abstractions in the model may > make >> sense, but there's also some benefit to simply exposing protocol > mechanics >> in the models. The difference is "this is a type-X LSA in OSPF" vs. > "this >> is a link, this is a node, here are how they connect". >> >> The abstraction is a bit more useful in an I2RS context. >> The protocol mechanics are likely to be something that gets a protocol >> specific module in the owning Working Group. >> >> There will be interesting overlaps in the above two, and one of the > more >> interesting bits of coordination work I2RS will have. > > Jeff > > We have just got a netmod-isis draft > draft-litkowski-netmod-isis-cfg-00.txt > and I look for items of the third type, and at first sight, I do not see > them, just as I cannot recall seeing them in SMI models, either > standards-based or proprietary (unlike the LSDB). Of course > they can be added but .... This is provided already by the core "ietf-routing" module's RPC method "active-route". The ISIS module properly augments the definition of this RPC with ISIS-specific route attributes. Lada > well, I have said enough about it. > > Tom Petch > > > > > > >> >> -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 19 02:22:39 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31A61A036A for ; Thu, 19 Jun 2014 02:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruWBt2hXlfJv for ; Thu, 19 Jun 2014 02:22:34 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C147A1A008C for ; Thu, 19 Jun 2014 02:22:33 -0700 (PDT) Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (10.255.75.37) by AMSPR07MB293.eurprd07.prod.outlook.com (10.242.20.11) with Microsoft SMTP Server (TLS) id 15.0.959.24; Thu, 19 Jun 2014 09:22:26 +0000 Received: from pc6 (86.151.169.188) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.459.0; Thu, 19 Jun 2014 09:22:25 +0000 Message-ID: <021301cf8b9f$883b91e0$4001a8c0@gateway.2wire.net> From: t.petch To: Susan Hares , 'Ladislav Lhotka' References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> <011901cf8a41$69162500$4001a8c0@gateway.2wire.net> <000501cf8a44$38d07af0$aa7170d0$@ndzh.com> Date: Thu, 19 Jun 2014 10:19:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.151.169.188] X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02475B2A01 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(51444003)(54094003)(76104003)(24454002)(51414003)(377454003)(13464003)(51704005)(14496001)(92566001)(92726001)(85852003)(83072002)(66066001)(50226001)(81342001)(575784001)(81686999)(102836001)(50986999)(93916002)(80022001)(86362001)(81816999)(44736004)(74662001)(31966008)(33646001)(4396001)(77096002)(50466002)(21056001)(83322001)(19580405001)(19580395003)(15975445006)(95666004)(84392001)(61296003)(23756003)(105586002)(85306003)(46102001)(104166001)(87936001)(89996001)(88136002)(99396002)(77982001)(79102001)(76482001)(87286001)(81542001)(101416001)(76176999)(93886003)(44716002)(77156001)(47776003)(62236002)(62966002)(64706001)(20776003)(74502001)(15202345003)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB293; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/gEnT39tpFqPTZE2c0qgE8AggzMA Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Edward Crabbe' Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 09:22:37 -0000 ----- Original Message ----- From: "Susan Hares" To: "'t.petch'" ; "'Ladislav Lhotka'" Cc: "'Jeffrey Haas'" ; ; "'Edward Crabbe'" Sent: Tuesday, June 17, 2014 4:53 PM > Tom: > > Thank you for the pointer to your earlier message. What do you think of > Lada's suggestion of > "draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2)"? Sue I lost the argument against that definition on the NETMOD list so I expect I would lose it again on the I2RS list:-( But I would commend to you the taxonomy of Russ as in http://www.ietf.org/mail-archive/web/i2rs/current/msg01794.html where he talks of two different RIBs but has yet to say which they are; for me, it is the one I tagged A that is a RIB. Lada would I think be closer to C, but Lada's definition allows multiple RIBs per address family as, sort of, does draft-ietf-i2rs-rib-info-model, which Russ does not yet mention. Then again the BGP RFC have a clear view of a RIB which for me is A. So, I think that achieving consensus on what a RIB is and is not is the biggest challenge facing I2RS and that understanding I-Ds will be more difficult without it. Tom Petch > Sue > > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Tuesday, June 17, 2014 11:33 AM > To: Susan Hares; 'Ladislav Lhotka' > Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Edward Crabbe' > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > Sue > > Probably best to do it yourself. I did offer a reprise of previous IETF > work in > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > but it did not gain traction in NETMOD, so I would not expect it to here. > > Tom Petch > > ----- Original Message ----- > From: "Susan Hares" > To: "'t.petch'" ; "'Ladislav Lhotka'" > > Cc: "'Jeffrey Haas'" ; ; "'Edward Crabbe'" > > Sent: Tuesday, June 17, 2014 4:23 PM > Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > > > Lada and Tom: > > > > You've convinced me that I should define the term RIB and FIB in the > > draft-white-i2rs-use-case-05. Would you like to suggest any text? > > Otherwise give me a day or so to come up with text for this draft. > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > > Sent: Tuesday, June 17, 2014 4:55 AM > > To: Ladislav Lhotka > > Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares > > Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted > > > > ----- Original Message ----- > > From: "Ladislav Lhotka" > > To: "t.petch" > > Sent: Friday, June 13, 2014 1:11 PM > > > > > > On 13 Jun 2014, at 13:49, t.petch wrote: > > > > ---- Original Message ----- > > > > From: "Susan Hares" > > > Sent: Thursday, June 12, 2014 11:26 PM > > > > > > > >> I've posted a version of white-i2rs-use-case-05 with the > > > > recommendations at the front of the document. I look forward to > > > > additional comments. I appreciate Tom Petch and Dean B.'s > comments > > on > > > > these drafts. > > > > > > > > Sue > > > > > > > > I am flattered; I am not sure that I deserve such mention. > > > > > > > > I am more interested in the use cases part of the I-D, seeing > > > > requirements and info-model as the next stage when use cases are > > agreed, > > > > and they look fine (perhaps /may Data Centers/many Data Centers/). > > > > > > > > I note the reference to ISIS which I find significant. My > > experience is > > > > more of OSPF but appreciate that that is rare with Operators. > > However, > > > > both are Link State and so very different to BGP which makes me > > think > > > > about the use of RIB. The NETMOD routing-cfg started with RIBs, > > dropped > > > > them and then reinstated them (after consulting with I2RS), > whereas > > for > > > > me, RIBs are BGP (as defined in RFC4271) and OSPF has an > equivalent > > in > > > > LSDB, which is very different in detail (as much research as Lada > > has > > > > done across three differing platforms, I am not certain that the > > NETMOD > > > > has sufficient routing expertise to get this perfect:-(. > > > > > > > > I think you need a definition of RIB, perhaps by a Normative > > reference > > > > to rib-info-model, but for me that leaves unclear the relationship > > > > between routing instance, routing protocol and RIB, at least when > > you > > > > get into requirements. > > > > > > Sounds like recurring deja vu: > > > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html > > > > > > - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html > > > > > > or, once again with feeling, > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html > > > > Tom Petch > > > > > > > > Lada > > > > > > > > > > > Likewise, this I-D is cast in terms of a table identifier and a > > route > > > > process identifier, whereas routing-cfg has routing-instance > [name] > > > > with router-id, ribs, interfaces, routing-protocols etc I have a > > sense > > > > of two divergent models of what a router is for all the > discussions. > > > > > > > > REQ1 last sentence should probably include removing process > > > > > > > > REQ2 I think is about source-based routing but it does not quite > say > > > > that, rather reading as if source or destination routing were > > equally > > > > valid options > > > > > > > > REQ3 again the wording seems odd - I think you mean that traffic > > with a > > > > given destination (or source?) prefix should be discarded, but > that > > is > > > > not what it says > > > > > > > > REQ4 I find vague, as I do anything with the word policy in it:-( > > > > Something concrete (communities, MED, ...) would help > > > > > > > > REQ6 makes me wonder what is a RIB when it is not local > > > > > > > > REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like > > > > something more concrete. Again, I wonder if it is technically > > possible > > > > to present information in a consistent manner given the difference > > in > > > > underlying concepts of protocols. > > > > > > > > REQ9 - again all embracing and as such, probably impossible, at > > least as > > > > written. Limiting it just to BGP and a link-state protocol, again > > that > > > > seems challenging. > > > > > > > > REQ10 - policies again, and it is unclear who is doing the time > > > > management. Some configuration protocols do have timer-based > > > > facilities, but not NETCONF; do you mean here that I2RS must have > > > > functionality based on timers (e.g. between 08:00 and 17:00 EDT, > > route > > > > this via Europe and Japan?) > > > > > > > > Tom Petch > > > > > > > >> > > > >> URL: > > > > > http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt > > > >> > > > >> Sue Hares > > > >> > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > > > > > > > > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > > From nobody Thu Jun 19 02:53:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87221A00EC for ; Thu, 19 Jun 2014 02:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FffcyjwEbGxa for ; Thu, 19 Jun 2014 02:53:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D92C1A00D4 for ; Thu, 19 Jun 2014 02:53:15 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 99C8013F9D0; Thu, 19 Jun 2014 11:53:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1403171594; bh=i7l8TvBErqx0PKGHVmarAJlTiYUGe1nOKxOfd6sD9iQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zig7V9fnPQspqzGxFEivsEm8Fr0eK+d50FpvIlf0I9FS+C4A3GgQbwZ2jUBwJdVpN wY3FUpIIMXfZtXpJW+/CYKJ0EKV2qGa3/lLhVlK3vkovVQR97M9614kVnvUx0/RiNh GMY4oBJ7GH3h4tchtwc3LXOrZJm5hZp8GRKnuE98= Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <021301cf8b9f$883b91e0$4001a8c0@gateway.2wire.net> Date: Thu, 19 Jun 2014 11:53:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <789A1CC6-6171-4800-91B1-0B70317BD10A@nic.cz> References: <000901cf868d$4afbcb40$e0f361c0$@ndzh.com> <02a201cf86fd$bdeff020$4001a8c0@gateway.2wire.net> <4710247C-558D-4F77-9EE3-31B23483792B@nic.cz> <01bf01cf8a09$dc1f20c0$4001a8c0@gateway.2wire.net> <009201cf8a40$1fb920c0$5f2b6240$@ndzh.com> <011901cf8a41$69162500$4001a8c0@gateway.2wire.net> <000501cf8a44$38d07af0$aa7170d0$@ndzh.com> <021301cf8b9f$883b91e0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/dwsKc_GGGARioJhJztD-dQLy3WU Cc: Jeffrey Haas , i2rs@ietf.org, Edward Crabbe , Susan Hares Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 09:53:18 -0000 On 19 Jun 2014, at 11:19, t.petch wrote: > ----- Original Message ----- > From: "Susan Hares" > To: "'t.petch'" ; "'Ladislav Lhotka'" > > Cc: "'Jeffrey Haas'" ; ; "'Edward > Crabbe'" > Sent: Tuesday, June 17, 2014 4:53 PM >=20 >> Tom: >>=20 >> Thank you for the pointer to your earlier message. What do you think > of >> Lada's suggestion of >> "draft-ietf-netmod-routing-cfg-15, section 5.3 (and 5.2)"? >=20 > Sue >=20 > I lost the argument against that definition on the NETMOD list so I > expect I would lose it again on the I2RS list:-( Actually, you didn=92t lose that argument in NETMOD! As you know, the = routing-cfg draft then had been using the term =93routing table=94 for = some time. However, an action item from IETF 87 was "to harmonize things = with the information model defined by the I2RS working group=94 [1]. One = of the results of this harmonisation was the change =93routing table=94 = -> =93RIB=94. IMO, whatever names are chosen, it is important to define the terms = properly. I understand Sue=92s proposal aims at this direction, and I = certainly hope it won=92t lead to a de-harmonisation with NETMOD terms. Lada [1] http://www.ietf.org/proceedings/87/minutes/minutes-87-netmod >=20 > But I would commend to you the taxonomy of Russ as in > http://www.ietf.org/mail-archive/web/i2rs/current/msg01794.html > where he talks of two different RIBs but has yet to say which they = are; > for me, it is the one I tagged A that is a RIB. >=20 > Lada would I think be closer to C, but Lada's definition allows = multiple > RIBs per address family as, sort of, does > draft-ietf-i2rs-rib-info-model, which Russ does not yet mention. >=20 > Then again the BGP RFC have a clear view of a RIB which for me is A. >=20 > So, I think that achieving consensus on what a RIB is and is not is = the > biggest challenge facing I2RS and that understanding I-Ds will be more > difficult without it. >=20 > Tom Petch >=20 >> Sue >>=20 >> -----Original Message----- >> From: t.petch [mailto:ietfc@btconnect.com] >> Sent: Tuesday, June 17, 2014 11:33 AM >> To: Susan Hares; 'Ladislav Lhotka' >> Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Edward Crabbe' >> Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted >>=20 >> Sue >>=20 >> Probably best to do it yourself. I did offer a reprise of previous > IETF >> work in >>=20 >> http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html >>=20 >> but it did not gain traction in NETMOD, so I would not expect it to > here. >>=20 >> Tom Petch >>=20 >> ----- Original Message ----- >> From: "Susan Hares" >> To: "'t.petch'" ; "'Ladislav Lhotka'" >> >> Cc: "'Jeffrey Haas'" ; ; "'Edward > Crabbe'" >> >> Sent: Tuesday, June 17, 2014 4:23 PM >> Subject: RE: [i2rs] draft-white-i2rs-use-case-05.txt has been posted >>=20 >>=20 >>> Lada and Tom: >>>=20 >>> You've convinced me that I should define the term RIB and FIB in the >>> draft-white-i2rs-use-case-05. Would you like to suggest any text? >>> Otherwise give me a day or so to come up with text for this draft. >>>=20 >>> Sue >>>=20 >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch >>> Sent: Tuesday, June 17, 2014 4:55 AM >>> To: Ladislav Lhotka >>> Cc: Jeffrey Haas; i2rs@ietf.org; Edward Crabbe; Susan Hares >>> Subject: Re: [i2rs] draft-white-i2rs-use-case-05.txt has been posted >>>=20 >>> ----- Original Message ----- >>> From: "Ladislav Lhotka" >>> To: "t.petch" >>> Sent: Friday, June 13, 2014 1:11 PM >>>>=20 >>>> On 13 Jun 2014, at 13:49, t.petch wrote: >>>>> ---- Original Message ----- >>>>> From: "Susan Hares" >>>> Sent: Thursday, June 12, 2014 11:26 PM >>>>>=20 >>>>>> I've posted a version of white-i2rs-use-case-05 with the >>>>> recommendations at the front of the document. I look forward to >>>>> additional comments. I appreciate Tom Petch and Dean B.'s >> comments >>> on >>>>> these drafts. >>>>>=20 >>>>> Sue >>>>>=20 >>>>> I am flattered; I am not sure that I deserve such mention. >>>>>=20 >>>>> I am more interested in the use cases part of the I-D, seeing >>>>> requirements and info-model as the next stage when use cases are >>> agreed, >>>>> and they look fine (perhaps /may Data Centers/many Data > Centers/). >>>>>=20 >>>>> I note the reference to ISIS which I find significant. My >>> experience is >>>>> more of OSPF but appreciate that that is rare with Operators. >>> However, >>>>> both are Link State and so very different to BGP which makes me >>> think >>>>> about the use of RIB. The NETMOD routing-cfg started with RIBs, >>> dropped >>>>> them and then reinstated them (after consulting with I2RS), >> whereas >>> for >>>>> me, RIBs are BGP (as defined in RFC4271) and OSPF has an >> equivalent >>> in >>>>> LSDB, which is very different in detail (as much research as > Lada >>> has >>>>> done across three differing platforms, I am not certain that the >>> NETMOD >>>>> has sufficient routing expertise to get this perfect:-(. >>>>>=20 >>>>> I think you need a definition of RIB, perhaps by a Normative >>> reference >>>>> to rib-info-model, but for me that leaves unclear the > relationship >>>>> between routing instance, routing protocol and RIB, at least > when >>> you >>>>> get into requirements. >>>>=20 >>>> Sounds like recurring deja vu: >>>>=20 >>>> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html >>>>=20 >>>> - http://www.ietf.org/mail-archive/web/i2rs/current/msg00586.html >>>=20 >>>=20 >>> or, once again with feeling, >>>=20 >>> http://www.ietf.org/mail-archive/web/netmod/current/msg07022.html >>>=20 >>> Tom Petch >>>=20 >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> Likewise, this I-D is cast in terms of a table identifier and a >>> route >>>>> process identifier, whereas routing-cfg has routing-instance >> [name] >>>>> with router-id, ribs, interfaces, routing-protocols etc I have > a >>> sense >>>>> of two divergent models of what a router is for all the >> discussions. >>>>>=20 >>>>> REQ1 last sentence should probably include removing process >>>>>=20 >>>>> REQ2 I think is about source-based routing but it does not quite >> say >>>>> that, rather reading as if source or destination routing were >>> equally >>>>> valid options >>>>>=20 >>>>> REQ3 again the wording seems odd - I think you mean that traffic >>> with a >>>>> given destination (or source?) prefix should be discarded, but >> that >>> is >>>>> not what it says >>>>>=20 >>>>> REQ4 I find vague, as I do anything with the word policy in > it:-( >>>>> Something concrete (communities, MED, ...) would help >>>>>=20 >>>>> REQ6 makes me wonder what is a RIB when it is not local >>>>>=20 >>>>> REQ8 seems all embracing (SNMP, DHCP, NTP ...?:-) - I would like >>>>> something more concrete. Again, I wonder if it is technically >>> possible >>>>> to present information in a consistent manner given the > difference >>> in >>>>> underlying concepts of protocols. >>>>>=20 >>>>> REQ9 - again all embracing and as such, probably impossible, at >>> least as >>>>> written. Limiting it just to BGP and a link-state protocol, > again >>> that >>>>> seems challenging. >>>>>=20 >>>>> REQ10 - policies again, and it is unclear who is doing the time >>>>> management. Some configuration protocols do have timer-based >>>>> facilities, but not NETCONF; do you mean here that I2RS must > have >>>>> functionality based on timers (e.g. between 08:00 and 17:00 EDT, >>> route >>>>> this via Europe and Japan?) >>>>>=20 >>>>> Tom Petch >>>>>=20 >>>>>>=20 >>>>>> URL: >>>>>=20 >> http://www.ietf.org/internet-drafts/draft-white-i2rs-use-case-05.txt >>>>>>=20 >>>>>> Sue Hares >>>>>>=20 >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Jun 21 00:54:15 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5B21A0657 for ; Sat, 21 Jun 2014 00:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uviW94OYm17p for ; Sat, 21 Jun 2014 00:54:13 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6688C1A0409 for ; Sat, 21 Jun 2014 00:54:13 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id c1so1279771igq.3 for ; Sat, 21 Jun 2014 00:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kan07JC0W7zYDT5tTF49yXd2v8+6ut+nqp46KitoO2A=; b=csCdkOuffqirkwQTni/wKvOwJMBtzJIjQtZsKspKYUGCYuNxnkLVXgBab8b88iOOtD 0WVtWtHhMERm1kGOqbXOTRxjU6CqeLzu34g2uKFqaUWVGZA/c7vC9lavfjCbc8rBa6Vp 5/hVCz1MnQS5wOv/Ajd2xyKICpQkN8OKban8TQO7Ar5Nj5gNHXsN027ENOhYKlzWpkKc cNsXL9xqa29akQHlArttJKQUq+P9lMPRS6r2+gGyUOl6YSPOgHGiwFgz7PBskRtF3Lpo sV8EmBQbCKU5vRRdBBEAjof6DysilI3FBw/ZPqeXrkfPvYrXkkDtGxsg2Fl33LYmgWM2 l/Wg== MIME-Version: 1.0 X-Received: by 10.50.143.8 with SMTP id sa8mr10129538igb.29.1403337252719; Sat, 21 Jun 2014 00:54:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.242.198 with HTTP; Sat, 21 Jun 2014 00:54:12 -0700 (PDT) In-Reply-To: <022e01cf86f8$e4b2fae0$ae18f0a0$@riw.us> References: <08d801cf5f0e$3d65db20$4001a8c0@gateway.2wire.net> <20140423.190851.213360502.mbj@tail-f.com> <008e01cf5f9e$137f1200$4001a8c0@gateway.2wire.net> <20140424.131244.180603940339430480.mbj@tail-f.com> <20140501002451.GY1256@pfrc> <032e01cf6524$713d3b20$4001a8c0@gateway.2wire.net> <20140610183506.GK20397@pfrc> <022e01cf86f8$e4b2fae0$ae18f0a0$@riw.us> Date: Sat, 21 Jun 2014 09:54:12 +0200 X-Google-Sender-Auth: 3vdbPxFfrNzJpy6M8JuD9jdSE9Q Message-ID: From: Robert Raszuk To: Russ White Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/a1pixH-P4CL5mkp9oJGAJxEqnMA Cc: "i2rs@ietf.org" , Edward Crabbe , "t.petch" , Dean Bogdanovic , Jeffrey Haas , Sriganesh Kini Subject: Re: [i2rs] Updating routes wa Re: consensus on I2RS protocol and model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 07:54:14 -0000 Hi Russ, > We are injecting routing information into a local RIB > which is then distributed through normal routing You mean that such "distribution" will be based on common protocol to protocol redistribution rules and filters right (I2RS being here one of the src or dst protocol) ? If so I agree, if not how do you imagine this to be accomplished ? Normally RIB does not "push" routes up to producers in fact it has no clue who would even want it :-) Thx, R. From nobody Mon Jun 23 14:22:03 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B927F1B2BD4 for ; Mon, 23 Jun 2014 14:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmQwsel2Tjl4 for ; Mon, 23 Jun 2014 14:21:58 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB9E1B2BB2 for ; Mon, 23 Jun 2014 14:21:58 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so5520494yha.40 for ; Mon, 23 Jun 2014 14:21:57 -0700 (PDT) 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=E+qBxUwApZBmJoIDMb4LOKcAu+3NZG7mUloE2puhG3M=; b=SekZjmbd3jOLZUBBFw4X6beJipCHmncFkymD4P2tjxir/6mGdHKVW1Mx/0+oIhGJPH WSR3L1dDPbYnBkqNqqwXcGw0vTSgRIeE2GQKUWiPwBXAEZev0sK6bzhsGqBXLF7z/bfw lZmp3PY8+9wLuUp3L1Eb2YtCzZGWkIizJ5Jss4RIhvKLprnhbiMUc1o4rzW+OCJdN/Q5 CZlwuMFrpE/VU4cJ8eaiA3RWP1Nd/4N/mxfeyOMlURkI/CGc72/4zf2R5Qy9jIHBsz66 KdQXAHjS8Q1HhmrXyTQP0desE2sqc5B4HfLGah15Whskv9u8l+aiELsPSwv/TTvDbmga g53A== MIME-Version: 1.0 X-Received: by 10.236.132.139 with SMTP id o11mr39194869yhi.101.1403558517364; Mon, 23 Jun 2014 14:21:57 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 14:21:57 -0700 (PDT) In-Reply-To: <539233C5.2070700@cisco.com> References: <20140605202938.GP13606@pfrc> <539233C5.2070700@cisco.com> Date: Mon, 23 Jun 2014 17:21:57 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=20cf3005de28d95d4b04fc876ecc Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/oGxglH3Sy2m6nsYuO-RxvuctIAI Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:22:01 -0000 --20cf3005de28d95d4b04fc876ecc Content-Type: text/plain; charset=UTF-8 Hi Joe, I'm sorry I missed this set of comments earlier. Responses in-line. Alia On Fri, Jun 6, 2014 at 5:33 PM, Joe Marcus Clarke wrote: > On 6/5/14, 4:29 PM, Jeffrey Haas wrote: > >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ >> Have you read the architecture draft? >> Do you think it is ready to be published as a RFC? >> (Ditto.) >> > > Here is a list of my previous comments that didn't get addressed in the > text or on the list. > > In section 1.1, the first paragraph states: > > ...Second is the access to structured information and state that is > frequently not directly configurable... > > Then in paragraph four: > > ...I2RS will only permit modification of state that would be safe, > conceptually, to modify via local configuration... > > While you do use the word "conceptually," it's hard to conceive of > something that is at the same time safe to modify via the configuration but > is not exposed via the configuration. That is, how would one know what is > safe? This might benefit from an early example to clarify what is meant > and perhaps it is good enough to drop the bit about modifiable via local > configuration and just say that modification of protocol internal state is > out of scope. > [Alia] Many of the aspects of the RIB information model aren't generally exposed via configuration but are safe to expose. The full sentence is: "I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned." I like the first part because it helps scope what I2RS can do; the second part is more specific. I really don't think an example is useful here; it'd derail the document. > === > > In section 1.2, the new text helps to show how App, Client, and Agent fit > together, but I wonder if this same new text wouldn't benefit from a > statement that App to Client communication is out of scope. That is, you > state that the Client and Agent communicate via an asynchronous protocol, > but nothing is said about, for example, how apps C, D, E communicate with > Client P. You do mention this further down in the doc, so it's a minor > thing, but perhaps worth a sentence here. > [Alia] I've added in " The details of how applications communicate with a remote client is out of scope for I2RS." to the second paragraph in 1.2. > > === > > Section 2, in the I2RS Client paragraph, I can't get my head around this > text: > > Based on the information and the policy oriented interactions, the I2RS > client may also interact with I2RS agents to modify the state > of the routing system the client interacts with to achieve > operational goals. > > The first part makes sense, but then it starts to sound muddled, at least > to me. Maybe you want to say: > > Based on the information and the policy oriented interactions, the I2RS > client may also interact with I2RS agents to modify the state > of the routing system in order to achieve operational goals. > [Alia] Agreed it was awkwardly worded. Changed to "Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of their associated routing systems to achieve operational goals. " > === > > Section 4. While streaming OSPF prefix announcements MAY NOT require > confidentiality, some users may want it. Paragraph 4 starts out, Other > communications via I2RS will not... I think this should say may not just > to make it clear that this can be optional based on specific environmental > requirements. > [Alia] Sure - changed to "may not" from "will not". The point of the paragraph is to point out different security requirements on the transport may apply - not to target what they are or which information may be targeted. > === > > Section 7.1. This is mainly an editorial, but in looking back at things > like NETCONF over BEEP, one goal might be to make sure the transport chosen > is both operator and implementor friendly in terms of ease of adoption. > [Alia] Sure - added to the end of the paragraph "The transports chosen should be operator and implementor friendly to ease adoption." [Alia] I also updated this paragraph to refer to the WG's decision to base I2RS on NETCONF and RESTCONF. > === > > Section 7.5. Would a supervisory application work in this case? I > suppose it could if it shared the same ID, but that wouldn't work for > multiple applications. Likely a better approach would be to allow the > Client to accept some meta-instructions at the beginning of a session as to > what to do if the app goes away (as you state in paragraph 4). > [Alia] Yes, a supervisory application could work. This section changed in -03, but please wait until I publish -04 and then comment on that. Thanks for the review! I really do appreciate your careful and thoughtful work. Alia > > Thanks. > > Joe > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf3005de28d95d4b04fc876ecc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

I'm sorry I missed this set= of comments earlier. =C2=A0Responses in-line.

Ali= a


On Fri= , Jun 6, 2014 at 5:33 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote:
On 6/5/14, 4:29 PM, Jeffrey Haas wrote:
http://datatracker.ietf.org/doc/draft-ietf-i2rs-= architecture/
Have you read the architecture draft?
Do you think it is ready to be published as a RFC?
(Ditto.)

Here is a list of my previous comments that didn't get addressed in the= text or on the list.

In section 1.1, the first paragraph states:

...Second is the access to structured information and state that is frequen= tly not directly configurable...

Then in paragraph four:

...I2RS will only permit modification of state that would be safe, conceptu= ally, to modify via local configuration...

While you do use the word "conceptually," it's hard to concei= ve of something that is at the same time safe to modify via the configurati= on but is not exposed via the configuration. =C2=A0That is, how would one k= now what is safe? =C2=A0This might benefit from an early example to clarify= what is meant and perhaps it is good enough to drop the bit about modifiab= le via local configuration and just say that modification of protocol inter= nal state is out of scope.

[Alia] Many of the aspects of the RIB info= rmation model aren't generally exposed via configuration but are safe t= o expose. =C2=A0The full sentence is:=C2=A0
"I2RS will only = permit modification of state that would be safe, conceptually, to modify vi= a local configuration; no direct manipulation of protocol-internal dynamica= lly determined data is envisioned."
=C2=A0
I like the first part because it helps scope what I2R= S can do; the second part is more specific. =C2=A0I really don't think = an example is useful here; it'd derail the document.


=3D=3D=3D

In section 1.2, the new text helps to show how App, Client, and Agent fit t= ogether, but I wonder if this same new text wouldn't benefit from a sta= tement that App to Client communication is out of scope. =C2=A0That is, you= state that the Client and Agent communicate via an asynchronous protocol, = but nothing is said about, for example, how apps C, D, E communicate with C= lient P. =C2=A0You do mention this further down in the doc, so it's a m= inor thing, but perhaps worth a sentence here.

[Alia] =C2=A0I've added in " The = details of how applications communicate with a remote client is out of scop= e for I2RS." to the second paragraph in 1.2.
=C2=A0

=3D=3D=3D

Section 2, in the I2RS Client paragraph, I can't get my head around thi= s text:

Based on the information and the policy oriented interactions, the I2RS cli= ent may also interact with I2RS agents to modify the state
of the routing system the client interacts with to achieve
operational goals.

The first part makes sense, but then it starts to sound muddled, at least t= o me. =C2=A0Maybe you want to say:

Based on the information and the policy oriented interactions, the I2RS cli= ent may also interact with I2RS agents to modify the state
of the routing system in order to achieve operational goals.

[Alia] Agreed it was awkwardly worded. =C2=A0Changed = to=C2=A0
"Based on the information and the policy oriented i= nteractions, the I2RS client
may also interact with I2RS agents to modify the state of their associ= ated routing
systems to achieve operational goals.=C2=A0"

=C2=A0
=3D=3D=3D

Section 4. =C2=A0While streaming OSPF prefix announcements MAY NOT require = confidentiality, some users may want it. =C2=A0Paragraph 4 starts out, Othe= r communications via I2RS will not... =C2=A0I think this should say may not= just to make it clear that this can be optional based on specific environm= ental requirements.

[Alia] Sure - changed to "may not&quo= t; from "will not". =C2=A0The point of the paragraph is to point = out different security requirements on the transport may apply - not to tar= get what they are or which information may be targeted.=C2=A0
=C2=A0
=3D=3D=3D

Section 7.1. =C2=A0This is mainly an editorial, but in looking back at thin= gs like NETCONF over BEEP, one goal might be to make sure the transport cho= sen is both operator and implementor friendly in terms of ease of adoption.=

=C2=A0[Alia] Sure - added to the end of th= e paragraph=C2=A0
"The transports chosen should be operator = and
implementor friendly to ease adoption."=C2=A0
=
[Alia] I also updated this paragraph to refer to the WG's decision to b= ase I2RS on NETCONF and RESTCONF.

=C2=A0
=3D=3D=3D

Section 7.5. =C2=A0Would a supervisory application work in this case? =C2= =A0I suppose it could if it shared the same ID, but that wouldn't work = for multiple applications. =C2=A0Likely a better approach would be to allow= the Client to accept some meta-instructions at the beginning of a session = as to what to do if the app goes away (as you state in paragraph 4).

[Alia] Yes, a supervisory application coul= d work. =C2=A0This section changed in -03, but please wait until I publish = -04 and then comment on that.

Thanks for the revie= w! =C2=A0I really do appreciate your careful and thoughtful work.

Alia
=C2=A0

Thanks.

Joe


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

--20cf3005de28d95d4b04fc876ecc-- From nobody Mon Jun 23 14:34:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5451B2CDE for ; Mon, 23 Jun 2014 14:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSLrogK9wrbR for ; Mon, 23 Jun 2014 14:34:18 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602EA1B2CEC for ; Mon, 23 Jun 2014 14:34:18 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so5545055yha.36 for ; Mon, 23 Jun 2014 14:34:17 -0700 (PDT) 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=F+lS6Szi5G2vefReM5WXTWQvcLVKiGN1Wu4N3Y/u+hU=; b=Kj+bR5Ifd6nFTy04PjxclfLakEa2o/y13QY3hBIgtRuDwJy2bPu44/CNOTBjSllCKR w4vczVuetolQwZORJ+UQUQaKSGhZT2dWQe/0UKg6EM5uNzddDNrGyis8722CV/dKh5yA YTxjsTuS0Wz406ZZUqf9QdALEn/7whI0kkKJZB6rzPpw589XBpeU7GQCVRZcUzbdtfNR BeYQrVWcaJFmWgwMIRxsv+15L/OHOUdSYEkA+29Y3acWSwpX1bay+Gi7TPoP0HO9vFc9 5bzfg4bBBwpya/L2p6pQf2ISKbRHwCg/GGAGtWy/Ei2FQ24CDCM5kpqY1lj3sZmd7KjE vM/w== MIME-Version: 1.0 X-Received: by 10.236.54.166 with SMTP id i26mr38764024yhc.109.1403559257742; Mon, 23 Jun 2014 14:34:17 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 14:34:17 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> Date: Mon, 23 Jun 2014 17:34:17 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=bcaec50b5112faa36b04fc879a44 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/01XjMYWT9jIb0IT5UMUWMUSR0xk Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:34:21 -0000 --bcaec50b5112faa36b04fc879a44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robert, Thanks for the review. Comments in-line. On Mon, Jun 9, 2014 at 11:19 AM, Robert Raszuk wrote: > Hi Jeff, > > Late but still few comments on the draft-ietf-i2rs-architecture-03: > > > 1. > > This I2RS architecture recognizes that the routing > > system and a router=E2=80=99s OS provide useful mechanisms > > that applications could harness to accomplish > > application-level goals. > > What happens if multiple applications have mutually exclusive needs ? > It is not really an error as applications and clients by design are > independent. Where is the arbitration to take place ? In I2RS Client, > in I2RS Agent or in global router's RIB ? > [Alia] Well, each I2RS Client will have a priority that the I2RS Agent uses to determine who wins - but we agreed to set the multiple writers of the same state as an "error". [Alia] I'd argue that the applications are set up by network operators to d= o something and having them collide is something that an operator would need to investigate. In the meantime, the I2RS system would just assure predictability and avoid oscillation. > 2. > Fundamental question ... > > Is the I2RS protocol communication to take place in-band, out-of-band > or both of the data plane ? If we are including in-band I presume > there is serious risk that the information carried within the protocol > may cause in-band channels to stop working hence the device becomes > unreachable (at least for the I2RS system). > > It may be good for architecture document to be able to comment on it. > [Alia] Good point. In Sec 7.2 on Communication Channels, I've added: "I2RS protocol communication can be delivered in-band via the routing system's data plane. I2RS protocol communication might be delivered out-of-band via a management interface. Depending on what operations are requested, it is possible for the I2RS protocol communication to cause the in-band communication channels to stop working; this could cause the I2RS agent to become unreachable across that communication channel." > 3. > > Anticipated I2RS Services > > Is OEM hidden within the "Dynamic Data & Statistics" or is it just > plain missing ? ;) > [Alia] Hiding - if you have text that you'd suggest, please do. Thanks for the careful review, Alia > Many thx, > R. > > > On Thu, Jun 5, 2014 at 10:29 PM, Jeffrey Haas wrote: > > Working Group, > > > > The original deadline for comments on WGLC for the problem statement an= d > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on with > regard > > to these drafts, they are a bit of process we simply must get done in > order > > to fully move forward with our agenda of putting together data models. > > > > We are *NOT* going to hold that work up further - it is clear that ther= e > is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > 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 > --bcaec50b5112faa36b04fc879a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Thanks for the review. =C2= =A0Comments in-line.


On Mon, Jun 9, 2014 at 11:19 AM, Robert Raszuk <robert@raszuk= .net> wrote:
Hi Jeff,

Late but still few comments on the draft-ietf-i2rs-architecture-03:


1.
> This I2RS architecture recognizes that the routing
> system and a router=E2=80=99s OS provide useful mechanisms
> that applications could harness to accomplish
> application-level goals.

What happens if multiple applications have mutually exclusive needs ?
It is not really an error as applications and clients by design are
independent. Where is the arbitration to take place ? In I2RS Client,
in I2RS Agent or in global router's RIB ?

[Alia] Well, each I2RS Client will have a priority that the I2RS Age= nt uses to
determine who wins - but we agreed to set the multiple= writers of the same
state as an "error". =C2=A0

[Alia] = I'd argue that the applications are set up by network operators to do
something and having them collide is something that an operator wo= uld need
to investigate. =C2=A0 In the meantime, the I2RS system would just ass= ure predictability
and avoid oscillation.
=C2=A0
2.
Fundamental question ...

Is the I2RS protocol communication to take place in-band, out-of-band
or both of the data plane ? If we are including in-band I presume
there is serious risk that the information carried within the protocol
may cause in-band channels to stop working hence the device becomes
unreachable (at least for the I2RS system).

It may be good for architecture document to be able to comment on it.

[Alia] Good point. =C2=A0In Sec 7.2 on Commu= nication Channels, I've added:

"I2RS = protocol communication can be delivered in-band via the
routing system's data plane. =C2=A0I2RS protocol communication mig= ht be
delivered out-of-band via a management interface. =C2=A0Dep= ending on what
operations are requested, it is possible for the I= 2RS protocol
communication to cause the in-band communication channels to stop
working; this could cause the I2RS agent to become unreachable across=
that communication channel."

=C2= =A0
3.
> Anticipated I2RS Services

Is OEM hidden within the "Dynamic Data & Statistics" or is it= just
plain missing ? ;)

[Alia] Hiding - if y= ou have text that you'd suggest, please do.

Th= anks for the careful review,
Alia=C2=A0

=C2=A0
Many thx,
R.


On Thu, Jun 5, 2014 at 10:29 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> Working Group,
>
> The original deadline for comments on WGLC for the problem statement a= nd
> architecture drafts of May 30 has passed with no comment whatsoever. >
> While we all realize that there's a bit of exhaustion going on wit= h regard
> to these drafts, they are a bit of process we simply must get done in = order
> to fully move forward with our agenda of putting together data models.=
>
> We are *NOT* going to hold that work up further - it is clear that the= re is
> consenus to start making that progress.
>
> To assist us with putting this work behind us, please respond to the > following questions:
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-= problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-archi= tecture/
> Have you read the architecture draft?
> Do you think it is ready to be published as a RFC?
> (Ditto.)
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--bcaec50b5112faa36b04fc879a44-- From nobody Mon Jun 23 14:46:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF56C1B2D05 for ; Mon, 23 Jun 2014 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxFdT6yw5IHi for ; Mon, 23 Jun 2014 14:45:58 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEB11B2D02 for ; Mon, 23 Jun 2014 14:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=408; q=dns/txt; s=iport; t=1403559958; x=1404769558; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=X9m/0xE94pNGKgRSSCWnT4J5BXeCFLBVzfd2Jo4D0oI=; b=GUfUotYaYfb8Soy9YmD2dZyMT/31RBqugdBDYKEOi4dRIx1tZ0kLbXAb 72NKbAByB/RIbwNy6R9c+iZy6j3vXbsN2n8dOZYHYG7N2lcblGuq9kt46 6EIQYqvQrxSJYfMu0R4+m8W9Xe4Ryeh8+Uc6hu/6CnUemKSMBrGK8F6uA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAECfqFOtJssW/2dsb2JhbABZhyanVgEBAQEBAQUBmTUBgSd1hAMBAQEEIxVAARALDgQGAgIFFgsCAgkDAgECATcOBg0BBwEBiD6le511F4EqhDmJGQeCd4FMAQOaTJNjggCBXiE X-IronPort-AV: E=Sophos;i="5.01,533,1400025600"; d="scan'208";a="92100514" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 23 Jun 2014 21:45:56 +0000 Received: from JCLARKE-M-32CH.CISCO.COM (rtp-jclarke-8915.cisco.com [10.117.46.166]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5NLjt42007134; Mon, 23 Jun 2014 21:45:55 GMT Message-ID: <53A8A014.5030508@cisco.com> Date: Mon, 23 Jun 2014 17:45:56 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <20140605202938.GP13606@pfrc> <539233C5.2070700@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/E72SekTOMuTB5IdcNnokvuwLz14 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 21:45:59 -0000 On 6/23/14, 5:21 PM, Alia Atlas wrote: > [Alia] Yes, a supervisory application could work. This section changed > in -03, but please wait until I publish -04 and then comment on that. > > Thanks for the review! I really do appreciate your careful and > thoughtful work. Thanks, Alia. I agree with your changes and comments. I appreciate the follow-up. I will definitely look over -04. Joe From nobody Mon Jun 23 15:11:32 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436F01B2D0F for ; Mon, 23 Jun 2014 15:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDBVw5mqJ1aO for ; Mon, 23 Jun 2014 15:11:22 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931101B2B23 for ; Mon, 23 Jun 2014 15:11:22 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 131so5080941ykp.7 for ; Mon, 23 Jun 2014 15:11:21 -0700 (PDT) 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=Frudvi7dlNodxREpSoB961YqhxHQAMlSjtuzOji7LIo=; b=jYPaIkjxN1Uki6OwjXbyfjUWQ5/Ufsp+MpvwSbBJ0Cka1Fjutvbtw5s68sMNSg12Mm /0WqDVmLdcK7VHsL4R6XyD0YsXOCq7ge/2zDv9dvOYpzykp+oEvt46PGrgcPZQXEp3Kn k2GeWLauR4mfmErvvieINawSsDRqky/1Xq9StCgOt4Ckclf/BSl3JDf3alcjSDFiG26M I42/rq/vD5KmHVNvwLwdOI8wVIO6GLiGemxkrgVWblw929iN3zxhjGEJicbR1stpaOm+ M9dYGD5v1su8v3U3Qj29tm7QuU26P6O2JNze/jJ84ISYZvu3B51LrEr6u3O/78VLqhW/ kSWg== MIME-Version: 1.0 X-Received: by 10.236.135.228 with SMTP id u64mr40047018yhi.18.1403561481844; Mon, 23 Jun 2014 15:11:21 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:11:21 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> Date: Mon, 23 Jun 2014 18:11:21 -0400 Message-ID: From: Alia Atlas To: "George, Wes" Content-Type: multipart/alternative; boundary=20cf301af3f58bbdad04fc881faa Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/0mL9VKqwYoH5x4gKNrpW1iayUQI Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:11:30 -0000 --20cf301af3f58bbdad04fc881faa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wes, Thanks for your thoughtful review. Responses in-line. Alia On Mon, Jun 9, 2014 at 1:19 PM, George, Wes wrote: > > > >To assist us with putting this work behind us, please respond to the > >following questions: > > > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > >Have you read the problem statement draft? yes > >Do you think it is ready to be published as a RFC? > > Yes, but with two relatively minor comments: > Section 2: It would be useful to clarify the scope of the proposed data > model. I realize there=E2=80=99s a separate draft for data model, but sin= ce this > is the primary draft that one should read before diving into the gory > details, some clarity would be helpful. The big diagram includes a lot of > interfaces and objects that are "out of scope for I2RS", but it=E2=80=99s= unclear > to me whether you also mean that all of those would be out of scope when > it comes to the data model, or if you actually mean that they are simply > out of scope when referring to which interface we=E2=80=99re trying to bu= ild > between which objects. I think it=E2=80=99s the latter, since you need to > represent a much larger range of things in the data model than in the > interface, but you may want to be more explicit in the latter half of > section 2, as well as replacing =E2=80=9CI2RS" with something more descri= ptive in > the diagram to avoid naming confusion since =E2=80=9CI2RS=E2=80=9D can me= an IETF WG/effort > OR the actual interface to the routing system and related protocol. > [Alia] Before the diagram at the end of the paragraph, I've added: " The scope of the data-models used by I2RS extends across the entire routing system and I2RS protocol." and updated the text inside the figure under the block-diagram to say " <--> interfaces inside the scope of I2RS Protocol +--+ objects inside the scope of I2RS-defined behavior <**> interfaces NOT within the scope of I2RS Protocol +**+ objects NOT within the scope of I2RS-defined behavior .... boundary of a router supporting I2RS " > Since section 3 discusses MIBs and configuration, a reference to the > recent statement about writeable MIBs might also be appropriate here as > one more bolster to the need for a different protocol to do this work. > [Alia] Ok - I added to the end of that paragraph: " Additionally, on March 2, 2014, the IESG issued a statement about Writeable MIB Modules which is expected to limit creation of future writeable MIB modules." > > > > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > >Have you read the architecture draft? yes > >Do you think it is ready to be published as a RFC? > Yes, again with a couple of comments: > > 1.2 - are we considering flow data as a part of dynamic system state and > available to I2RS, or not? Would be useful to clarify, especially since > availability of flow data is often limited (not typically stored in large > amounts on-box), and similarly to the other stats mentioned, may be > available via other sources. > [Alia] Good catch - added in "flow data" to the "Dynamic System State:" description so that the sentence now reads: "Such state may include various counters, statistics, flow data, and local events. " 6.2 - I recommend that you explicitly call out the need to be able to > review (e.g. via CLI) the changes made by the I2RS agent and its state > data without a dependency on the client itself. The simplest > implementation case for making onboard CLI and I2RS agents play together > is that the router CLI is simply another application that uses the I2RS > agent in order to represent the necessary information, but I think that > dependency might be problematic. I think what is needed here is a way to > verify what is going on with the I2RS agent via separate means, such that > if the I2RS agent goes insane, I can use another method to figure out wha= t > its particular psychosis might be. It may not be practical to assume that > making the onboard CLI a client of the same agent will produce valid > results. i.e. I may not get a useful answer if I query the I2RS agent > =E2=80=9Ctell me why you=E2=80=99re insane=E2=80=9D but I might be able t= o figure out what the > agent was doing when it went insane if I can get access to the info about > what actions it took/what data it manipulated once it went insane, or loo= k > directly at its underlying state database without its =E2=80=9Chelp". I t= hink this > is a pretty important thing from a traceability and failure management > perspective. > [Alia] At the end of Section 6.3, I added "On a routing element, it is critical that there is a way of reviewing (e.g. via the CLI) the changes made by each associated I2RS Agent and its state data. Preferably, this mechanism should use a different priveleged mechanism other than simply connecting as an I2RS client to learn the data. Using a different mechanism should improve traceability and failure management." Thanks again, Alia > Thanks > > Wes George > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright 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 the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf301af3f58bbdad04fc881faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wes,

Thanks for your thoughtful revi= ew. =C2=A0Responses in-line.

Alia


On Mon, Jun 9, 2014 at 1:1= 9 PM, George, Wes <wesley.george@twcable.com> wrote:=
>
>To assist us with putting this work behind us, please respond to the >following questions:
>
>http://datatracker.ietf.org/doc/draft-ietf-i2rs-p= roblem-statement/
>Have you read the problem statement draft? yes
>Do you think it is ready to be published as a RFC?

Yes, but with two relatively minor comments:
Section 2: It would be useful to clarify the scope of the proposed data
model. I realize there=E2=80=99s a separate draft for data model, but since= this
is the primary draft that one should read before diving into the gory
details, some clarity would be helpful. The big diagram includes a lot of interfaces and objects that are "out of scope for I2RS", but it= =E2=80=99s unclear
to me whether you also mean that all of those would be out of scope when it comes to the data model, or if you actually mean that they are simply out of scope when referring to which interface we=E2=80=99re trying to buil= d
between which objects. I think it=E2=80=99s the latter, since you need to represent a much larger range of things in the data model than in the
interface, but you may want to be more explicit in the latter half of
section 2, as well as replacing =E2=80=9CI2RS" with something more des= criptive in
the diagram to avoid naming confusion since =E2=80=9CI2RS=E2=80=9D can mean= IETF WG/effort
OR the actual interface to the routing system and related protocol.

[Alia] Before the diagram at the end of the pa= ragraph, I've added:
" The scope of the data-models used= by I2RS extends across the entire
=C2=A0 =C2=A0 =C2=A0 routing system and I2RS protocol."
and updated the text inside the figure under the block-diagram to say

"
=C2=A0 <--> =C2=A0interfac= es inside the scope of I2RS Protocol
=C2=A0 +--+ =C2=A0objects inside the scope of I2RS-defined behavior

=C2=A0 <**> =C2=A0interfaces NOT within the sc= ope of I2RS Protocol
=C2=A0 +**+ =C2=A0objects NOT within the sco= pe of I2RS-defined behavior

=C2=A0 .... =C2=A0boundary of a router supporting I2RS<= /div>
"

=C2=A0
Since section 3 discusses MIBs and configuration, a reference to the
recent statement about writeable MIBs might also be appropriate here as
one more bolster to the need for a different protocol to do this work.
<= /blockquote>

[Alia] =C2=A0Ok - I added to the end of tha= t paragraph:

" Additionally, on March 2, 2014= , the IESG issued a statement about Writeable MIB Modules which is expected= =C2=A0to limit creation of future writeable MIB modules."
=C2=A0

>
>http://datatracker.ietf.org/doc/draft-ietf-i2rs-archit= ecture/
>Have you read the architecture draft? yes
>Do you think it is ready to be published as a RFC?
Yes, again with a couple of comments:

1.2 - are we considering flow data as a part of dynamic system state and available to I2RS, or not? Would be useful to clarify, especially since
availability of flow data is often limited (not typically stored in large amounts on-box), and similarly to the other stats mentioned, may be
available via other sources.

[Alia] =C2= =A0Good catch - added in "flow data" to the "Dynamic System = State:" description
so that the sentence now reads:

"Such state may include various counters, statistics, f= low
data, and local events.
"

6.2 - I recommend that you explicitly call out the need to be able to
review (e.g. via CLI) the changes made by the I2RS agent and its state
data without a dependency on the client itself. The simplest
implementation case for making onboard CLI and I2RS agents play together is that the router CLI is simply another application that uses the I2RS
agent in order to represent the necessary information, but I think that
dependency might be problematic. I think what is needed here is a way to verify what is going on with the I2RS agent via separate means, such that if the I2RS agent goes insane, I can use another method to figure out what<= br> its particular psychosis might be. It may not be practical to assume that making the onboard CLI a client of the same agent will produce valid
results. i.e. I may not get a useful answer if I query the I2RS agent
=E2=80=9Ctell me why you=E2=80=99re insane=E2=80=9D but I might be able to = figure out what the
agent was doing when it went insane if I can get access to the info about what actions it took/what data it manipulated once it went insane, or look<= br> directly at its underlying state database without its =E2=80=9Chelp". = I think this
is a pretty important thing from a traceability and failure management
perspective.

[Alia] =C2=A0At the end of= Section 6.3, I added

"On a routing element, = it is critical that there is a way of
reviewing (e.g. via the CLI= ) the changes made by each associated I2RS
Agent and its state data. =C2=A0Preferably, this mechanism should use = a
different priveleged mechanism other than simply connecting as = an I2RS
client to learn the data. =C2=A0Using a different mechani= sm should improve
traceability and failure management."

Th= anks again,
Alia
=C2=A0
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.
_________________________________________= ______
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--20cf301af3f58bbdad04fc881faa-- From nobody Mon Jun 23 15:22:07 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0D1B2D27 for ; Mon, 23 Jun 2014 15:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq-2zJzGUNCF for ; Mon, 23 Jun 2014 15:22:04 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7EE1B2D0E for ; Mon, 23 Jun 2014 15:22:03 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so5554523yha.26 for ; Mon, 23 Jun 2014 15:22:03 -0700 (PDT) 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=25gzFLh6tDhjbK3N4fEmAF7Xi/5AabSjyzAwLXLLQ2I=; b=Y+Bsb1AN983IAQuZgx4rpEcLGlsrmI8QpxgiWM9QmaGGA914E6nRDq7lJr/srhhNFe KJ1MjLxt0o2WLFXjz/N9LVCH12HdZqCB4ulqvUsgN7h7MBaik9SqIPlkP6J3RY234GcO B0YgN4ehoY/SxiZa446iUonjpBx+c1ZLj0BVw7BYfR6mQwVAKw7fXnwinYzzk1irRWxu M7DKcSXIXS8mjR9ojehPuliFqSkKJ53vlG5WX2NArjYuyKrBhGEZSRJTzb48l7gHLzKA jbQmh6LLplKRnuOKZVIjd+eBtYe6TKaUuK8xd5aDHi+jo16Yr/3zHmjhJhm2OGryTxRA GrXQ== MIME-Version: 1.0 X-Received: by 10.236.103.135 with SMTP id f7mr40528299yhg.102.1403562123196; Mon, 23 Jun 2014 15:22:03 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:22:02 -0700 (PDT) In-Reply-To: <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> Date: Mon, 23 Jun 2014 18:22:02 -0400 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=001a11332a2ec600b804fc884508 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5eiOMGAj7q0GR6E_-I5tMiol-Ck Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:22:06 -0000 --001a11332a2ec600b804fc884508 Content-Type: text/plain; charset=UTF-8 Hi Tom, On Tue, Jun 10, 2014 at 7:12 AM, t.petch wrote: > Architecture > > After reading this, I struggle to see the point of I2RS:-( As was said > two months ago, > "And the basic premise of I2RS is that there are requirements for the > work that were not addressed properly by the existing configuration > protocols. " > but reading Architecture, the examples I see are ones that seem to fall > within the remit of NETCONF (being config) as and when a suitable data > model has been defined (e.g. for OSPF or BGP). Initially I had thought > of several things that I2RS might do but these have been ruled out, > either on the list or in this I-D, so I am left wondering what it is > that I2RS will do that NETCONF potentially cannot. > [Alia] Partly, it is a different system model - where the agent can preempt a written operation or refuse a request - whether there is the idea and support for multi-headed control. I do think that there will be a lot of similarities with what RESTCONF can support - but also that there are gaps. > I do find the I-D quite hard to follow as the terminology seems > inconsistent - the word 'state' is much used but it is unclear to me if > the term can be given a single definition in this context; and even if > it can, the word seems an unfortunate choice since the IETF Ops Area has > given it a precise definition which is at odds with its use here. > [Alia] As I understand it, state is the operational state in the router - and that is what is being discussed in general in this document. A while ago, I did go over the different terminology with Ron Bonica and Dean - when I realized that my perspective of "configuration state" was from inside a protocol implementation and so what was considered "operational state" different from the "configuration data-stores". In this case, I think that the document can be understood without a precise definition of state - or having it match that in the Ops Area and differ from that commonly used in Routing. [Alia] I do appreciate your review and different perspective. Thanks for taking the time and interest! Alia > Tom Petch > > ----- Original Message ----- > From: "Jeffrey Haas" > To: > Sent: Thursday, June 05, 2014 9:29 PM > > > Working Group, > > > > The original deadline for comments on WGLC for the problem statement > and > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on with > regard > > to these drafts, they are a bit of process we simply must get done in > order > > to fully move forward with our agenda of putting together data models. > > > > We are *NOT* going to hold that work up further - it is clear that > there is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > 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 > --001a11332a2ec600b804fc884508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

On Tue, Jun 10, 2014 at 7:12 AM, t.petch <<= a href=3D"mailto:ietfc@btconnect.com" target=3D"_blank">ietfc@btconnect.com= > wrote:
Architecture

After reading this, I struggle to see the point of I2RS:-( =C2=A0As was sai= d
two months ago,
"And the basic premise of I2RS is that there are requirements for the<= br> work that were not addressed properly by the existing configuration
protocols. "
but reading Architecture, the examples I see are ones that seem to fall
within the remit of NETCONF (being config) as and when a suitable data
model has been defined (e.g. for OSPF or BGP). =C2=A0Initially I had though= t
of several things that I2RS might do but these have been ruled out,
either on the =C2=A0list or in this I-D, so I am left wondering what it is<= br> that I2RS will do that NETCONF potentially cannot.
[Alia] Partly, it is a different system model - where the agent= can preempt a written
operation or refuse a request - whether th= ere is the idea and support for multi-headed
control. =C2=A0 I do think that there will be a lot of similarities wi= th what RESTCONF can
support - but also that there are gaps. =C2= =A0
=C2=A0
I do find the I-D quite hard to follow as the terminology seems
inconsistent - the word 'state' is much used but it is unclear to m= e if
the term can be given a single definition in this context; and even if
it can, the word seems an unfortunate choice since the IETF Ops Area has given it a precise definition which is at odds with its use here.

[Alia] =C2=A0As I understand it, state is the op= erational state in the router - and that is
what is being discuss= ed in general in this document. =C2=A0A while ago, I did go over the
different terminology with Ron Bonica and Dean - when I realized that = my perspective
of "configuration state" was from inside= a protocol implementation and so what was=C2=A0
considered "= ;operational state" different from the "configuration data-stores= ". =C2=A0 In this case,
I think that the document can be understood without a precise definiti= on of state - or having
it match that in the Ops Area and differ = from that commonly used in Routing.

[Alia] I do ap= preciate your review and different perspective. =C2=A0Thanks for taking the= time and interest!

Alia
=C2=A0
Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <jhaas@= pfrc.org>
To: <i2rs@ietf.org>
Sent: Thursday, June 05, 2014 9:29 PM

> Working Group,
>
> The original deadline for comments on WGLC for the problem statement and
> architecture drafts of May 30 has passed with no comment whatsoever. >
> While we all realize that there's a bit of exhaustion going on wit= h
regard
> to these drafts, they are a bit of process we simply must get done in<= br> order
> to fully move forward with our agenda of putting together data models.=
>
> We are *NOT* going to hold that work up further - it is clear that
there is
> consenus to start making that progress.
>
> To assist us with putting this work behind us, please respond to the > following questions:
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-= problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-archi= tecture/
> Have you read the architecture draft?
> Do you think it is ready to be published as a RFC?
> (Ditto.)
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--001a11332a2ec600b804fc884508-- From nobody Mon Jun 23 15:23:14 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042391B2D29 for ; Mon, 23 Jun 2014 15:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldXr7JYqEier for ; Mon, 23 Jun 2014 15:23:09 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432B91B2D27 for ; Mon, 23 Jun 2014 15:23:08 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so5551850yha.41 for ; Mon, 23 Jun 2014 15:23:07 -0700 (PDT) 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=HJphABr+Q4A3iWe8ldNN1UA/pQTim9ahupQ6p4jZ7MY=; b=cDxaLliJusA2iri3vdZdpKULYtchNAcPfX7BkdgKiPWECLWYX8KPvdXVmRp63FWHKa q7G+gikvW0UHsLVZLtO9vR1ObHXX0mCzpM9rU672mGt2Se7qR71PJJP0+AenIm4Pe02T CUrYgP2dRihEbu2+kOjLceoIHYJUezhaNlhFP/UDw/cAidGchjZ05BN5CTpBzfOHASu8 TbIrSgof1ZO+CBw6FTfES5iUWPTtzu4POEv6Z1f6KhGlhS4/nYLDIHVyOxDknFXuts1N 6ozjM5PqKqI7H24NivlfQQHc8L8ALQEBXHozLwmIBOZ7nCcwRBWKEIXfGa9SO1wtIZV3 m4fg== MIME-Version: 1.0 X-Received: by 10.236.137.242 with SMTP id y78mr7110753yhi.152.1403562187662; Mon, 23 Jun 2014 15:23:07 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:23:07 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> Date: Mon, 23 Jun 2014 18:23:07 -0400 Message-ID: From: Alia Atlas To: "UTTARO, JAMES" Content-Type: multipart/alternative; boundary=20cf303a2f8d9dacff04fc884955 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/s91ASco1WrK8Yqi0h5mP_7j_Suo Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:23:11 -0000 --20cf303a2f8d9dacff04fc884955 Content-Type: text/plain; charset=UTF-8 Hi Jim, I would request that you take a look at the various use-cases drafts. We did try and pull from those use-cases to motivate the architecture as well. I'd be happy to discuss off-line. Thanks, Alia On Tue, Jun 10, 2014 at 8:35 AM, UTTARO, JAMES wrote: > A document clearly stating the reqs would help me understand the need I2RS > is addressing. I would suggest writing the reqs info doc first > > Jim Uttaro > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of t.petch > Sent: Tuesday, June 10, 2014 7:13 AM > To: Jeffrey Haas; i2rs@ietf.org > Subject: Re: [i2rs] Working Group Last Call on architecture and problem > statement drafts (redux) > > Architecture > > After reading this, I struggle to see the point of I2RS:-( As was said > two months ago, > "And the basic premise of I2RS is that there are requirements for the > work that were not addressed properly by the existing configuration > protocols. " > but reading Architecture, the examples I see are ones that seem to fall > within the remit of NETCONF (being config) as and when a suitable data > model has been defined (e.g. for OSPF or BGP). Initially I had thought > of several things that I2RS might do but these have been ruled out, > either on the list or in this I-D, so I am left wondering what it is > that I2RS will do that NETCONF potentially cannot. > > I do find the I-D quite hard to follow as the terminology seems > inconsistent - the word 'state' is much used but it is unclear to me if > the term can be given a single definition in this context; and even if > it can, the word seems an unfortunate choice since the IETF Ops Area has > given it a precise definition which is at odds with its use here. > > Tom Petch > > ----- Original Message ----- > From: "Jeffrey Haas" > To: > Sent: Thursday, June 05, 2014 9:29 PM > > > Working Group, > > > > The original deadline for comments on WGLC for the problem statement > and > > architecture drafts of May 30 has passed with no comment whatsoever. > > > > While we all realize that there's a bit of exhaustion going on with > regard > > to these drafts, they are a bit of process we simply must get done in > order > > to fully move forward with our agenda of putting together data models. > > > > We are *NOT* going to hold that work up further - it is clear that > there is > > consenus to start making that progress. > > > > To assist us with putting this work behind us, please respond to the > > following questions: > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ > > Have you read the problem statement draft? > > Do you think it is ready to be published as a RFC? > > (If no, please respond to the list with issues.) > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ > > Have you read the architecture draft? > > Do you think it is ready to be published as a RFC? > > (Ditto.) > > > > -- Jeff > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf303a2f8d9dacff04fc884955 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jim,

I would request that you take a= look at the various use-cases drafts. =C2=A0We did try and pull from those= use-cases to motivate the architecture as well. =C2=A0I'd be happy to = discuss off-line.

Thanks,
Alia


On Tue, Jun 10, 2014 at 8:35 AM, U= TTARO, JAMES <ju1738@att.com> wrote:
A document clearly stating the reqs would he= lp me understand the need I2RS is addressing. I would suggest writing the r= eqs info doc first

Jim Uttaro

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of t.petch
Sent: Tuesday, June 10, 2014 7:13 AM
To: Jeffrey Haas; i2rs@ietf.org
Subject: Re: [i2rs] Working Group Last Call on architecture and problem sta= tement drafts (redux)

Architecture

After reading this, I struggle to see the point of I2RS:-( =C2=A0As was sai= d
two months ago,
"And the basic premise of I2RS is that there are requirements for the<= br> work that were not addressed properly by the existing configuration
protocols. "
but reading Architecture, the examples I see are ones that seem to fall
within the remit of NETCONF (being config) as and when a suitable data
model has been defined (e.g. for OSPF or BGP). =C2=A0Initially I had though= t
of several things that I2RS might do but these have been ruled out,
either on the =C2=A0list or in this I-D, so I am left wondering what it is<= br> that I2RS will do that NETCONF potentially cannot.

I do find the I-D quite hard to follow as the terminology seems
inconsistent - the word 'state' is much used but it is unclear to m= e if
the term can be given a single definition in this context; and even if
it can, the word seems an unfortunate choice since the IETF Ops Area has given it a precise definition which is at odds with its use here.

Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <jhaas@= pfrc.org>
To: <i2rs@ietf.org>
Sent: Thursday, June 05, 2014 9:29 PM

> Working Group,
>
> The original deadline for comments on WGLC for the problem statement and
> architecture drafts of May 30 has passed with no comment whatsoever. >
> While we all realize that there's a bit of exhaustion going on wit= h
regard
> to these drafts, they are a bit of process we simply must get done in<= br> order
> to fully move forward with our agenda of putting together data models.=
>
> We are *NOT* going to hold that work up further - it is clear that
there is
> consenus to start making that progress.
>
> To assist us with putting this work behind us, please respond to the > following questions:
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-= problem-statement/
> Have you read the problem statement draft?
> Do you think it is ready to be published as a RFC?
> (If no, please respond to the list with issues.)
>
> http://datatracker.ietf.org/doc/draft-ietf-i2rs-archi= tecture/
> Have you read the architecture draft?
> Do you think it is ready to be published as a RFC?
> (Ditto.)
>
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

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

--20cf303a2f8d9dacff04fc884955-- From nobody Mon Jun 23 15:40:48 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7341B1A03A4 for ; Mon, 23 Jun 2014 15:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id px8cL9zpCG74 for ; Mon, 23 Jun 2014 15:40:43 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380F31A030C for ; Mon, 23 Jun 2014 15:40:43 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 9so5115052ykp.12 for ; Mon, 23 Jun 2014 15:40:42 -0700 (PDT) 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=3E8qenFbiBsl1EF5hSXlMLxpzsXRw769L9UkVyHMYWA=; b=RZV/IB0uY28hATq3G1zyzCvFiskiQCvsI4inkI6Tj+peUf3uX/G4mBxShERQPtTk8G Ls/PBNQGpMfE/n+SjyzWueBwtlxdOaUkXDgXnIZI37CHK6YmGoYmFIe5SjqI56FDtpHQ 3LnUrSxqEG8HR3IQ1QGPEIQ71TnFXN9MFiHp4a0dBM2c4Q5ggA073UkMFL/Jru6mvPgp X8B93Qff/O3NvoFwW5gq8VPyU1rLoRgVSAtWJccji5CInq/cUQixKhy+9dy1kZUbNOx1 kLqWz8HosuRQNUZRvCr/BXowMHv/yW45JNNycCcVXSzbgImWby3sps2l5wmE3vA4xDUw f41Q== MIME-Version: 1.0 X-Received: by 10.236.137.242 with SMTP id y78mr7223161yhi.152.1403563242384; Mon, 23 Jun 2014 15:40:42 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:40:42 -0700 (PDT) In-Reply-To: <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> Date: Mon, 23 Jun 2014 18:40:42 -0400 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=20cf303a2f8d7b73b704fc888841 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/GCsHKLWFzbFVZXjiQNXeWSjx33U Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:40:46 -0000 --20cf303a2f8d7b73b704fc888841 Content-Type: text/plain; charset=UTF-8 Hi Tom, On Tue, Jun 10, 2014 at 11:25 AM, t.petch wrote: > ---- Original Message ----- > From: "Jeffrey Haas" > To: "t.petch" > Cc: "Jeffrey Haas" ; > Sent: Tuesday, June 10, 2014 2:41 PM > > > Tom, > > > > Thanks for the comments. > > > > On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote: > > > but reading Architecture, the examples I see are ones that seem to > fall > > > within the remit of NETCONF (being config) as and when a suitable > data > > > model has been defined (e.g. for OSPF or BGP). Initially I had > thought > > > of several things that I2RS might do but these have been ruled out, > > > > It'd help if you listed the ones in question. Some of these things > may be > > part of the work that is left currently out of scope to attempt to > constrain > > the WG to things we have decided to get done first. (Don't bite off > more > > than you can chew.) > > e.g. > 6.2.3. Reversion "In all such cases, the state will revert to what it > would have been without the I2RS; that state is generally whatever was > specified via the CLI, NETCONF, SNMP, etc." > which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it > to Y then disappears so it reverts to X, for all values of 'it' - i.e. > 'it' is what NETCONF would call config and so could have been set by > NETCONF, no need for I2RS! > [Alia] If the state couldn't be set via CLI/NETCONF/SNMP etc, then the state will revert to the system default or what was dynamically learned (if that was something safe to be overwritten). This is describing what the behavior should be when written state is deleted by I2RS - not making a statement on what the scope of the models are. > 6.3. Interactions with Local Config "Changes may originate from either > Local Config or from I2RS." > Taking Local Config to be what NETCONF/YANG calls 'config' then again, > nothing there it seems that C/N/S cannot do > [Alia] Again - generically changes can originate - but that doesn't mean that the full scope will originate from either. Collisions and interactions are of interest when they both can. > > 6.4.2" o writing policy information such as interface attributes that > are > specific to the routing protocol or BGP policy that may indirectly > manipulate attributes of routes carried in BGP. > > o writing routes or prefixes to be advertised via the protocol" > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the > I-D goes on to say > " direct modification of the link-state database MUST NOT be allowed" > (which I have seen on the list w.r.t. the BGP RIB). > [Alia] Right - because doing so seriously risks breaking the routing protocol and leading to incorrect behavior. Let's crawl before we run a marathon! > or > > 8" The interaction of state installed via the I2RS and via a router's > configuration needs to be clearly defined." > which again implies that I2RS and C/N/S are writing to the same data. > [Alia] If C/N/S write to the config which then writes to the operational data and I2RS writes to the operational data, what is the final content of the operational data? If I2RS can write set A and C/N/S can write set B, saying that A & B overlap doesn't imply that A == B. > > The examples of data that can be changed are few, such as > "For example, the interaction with OSPF might include modifying the > local routing element's link metrics, announcing a locally-attached > prefix, .." > which leaves me wondering, do you expect an OSPF YANG model to be unable > to change a link metric:-) > [Alia] Remember that low latency, high throughput, and asynchronous operations are all aspects of what I2RS is facilitating. There's a big difference between change one and change 1000+ in less than a second. Whereever I look, I struggle to see what I2RS will write that C/N/S will > not. > [Alia] Personally, I think that I2RS will write lower-level abstractions (all the details for the RIB info-model which aren't a standard part of configuration) and subsets of data that need to change fast - plus being a good interface for push notifications and event streams. If you are looking for examples, I'd look at the use-cases. > If I2RS were aiming at a higher level, say specifying policy and have > the system translate that into actual config changes I would understand > that, but I do not see I2RS going that far, rather when I2RS says > policy, I think it means changing a community (config again) or some > such ie more of an implementation detail than a high level strategy. > [Alia] True - and if I2RS is designed and implemented well, possibly higher-level abstractions will also be possible. We see the start of that at the desire to have a single abstract link-state topology for reading, for instance. The WG is chartered to crawl first and see what's feasible. Getting the problem-statement and architecture out of the way, along with the language and protocol base selection that has happened, is likely to open up the ability to seriously discuss detailed models. Regards, Alia > > Tom Petch > > > > > > > either on the list or in this I-D, so I am left wondering what it > is > > > that I2RS will do that NETCONF potentially cannot. > > > > The longer term question and netconf/yang continue to evolve (perhaps > with > > impetus from our use cases) will generally be what work belongs in > various > > groups. Yang modules are being proposed in the various working groups > to > > cover protocol specific configuration and general management. This is > > great! The question then becomes, where does I2RS fit into that sort > of > > picture. > > > > One of the reasons I think nailing down specific requirements (as Jim > Uttaro > > raised in a separete response) has come down to the somewhat nebulous > > ability to interact with functionality that is either not quite a fit > for > > standard config/query or interact with models that are one or more > levels of > > abstraction above a given protocol component. > > > > The degenerate case - the ability to ephemerally inject static routing > > information - certainly seems like work that could be done outside of > I2RS. > > Definitely so if it is decided that the ephemeral model is something > that > > becomes core to netconf/restconf. (The question of how this is > represented > > in the data model is the longer question.) > > > > Where the use cases start getting more substance are when we get > somewhat > > more abstract: > > - An API to the traffic engineering state in a routing system. This > is not > > just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. Which > working > > group produces that model if done on a per-protocol basis? > > - A policy layer on top of BGP. That's perhaps in-scope for IDR or > GROW. > > As you definitely know (:-) ) such a policy layer will interact with > a lot > > of non-BGP components and potentially other databases. > > - A management layer to provision VPN instances (service layer > routing). > > Does that work get done in IDR? MPLS? L2/L3VPN? > > > > And of course, there's the whole matter of how do you bring together > > contributors with expertise in modeling, operations and the mix of > routing > > and other protocols in question and where do you do it? From the > first BoF, > > it was clear there are a lot of people who want to work on the things > that > > fall in these nebulous gaps between working groups. > > > > I2RS is here to be the big tent to let us gather people under to do > that > > sort of work. Maintaining enough focus to make progress on a > constrained > > number of items is the main early challenge. A survey of the use case > > documents should definitely suggest there's a lot more that people > would > > like to work on. > > > > > > > I do find the I-D quite hard to follow as the terminology seems > > > inconsistent - the word 'state' is much used but it is unclear to me > if > > > the term can be given a single definition in this context; and even > if > > > it can, the word seems an unfortunate choice since the IETF Ops Area > has > > > given it a precise definition which is at odds with its use here. > > > > Are there specific edits you would suggest to clarify the document? > > > > -- Jeff > > > > _______________________________________________ > > 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 > --20cf303a2f8d7b73b704fc888841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,

On Tue, Jun 10, 2014 at 11:25 AM, t.petch <= ietfc@btconnect.co= m> wrote:
---- Original Message -----<= br> From: "Jeffrey Haas" <jhaas@= pfrc.org>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Jeffrey Haas" <jhaas@pf= rc.org>; <i2rs@ietf.org><= br> Sent: Tuesday, June 10, 2014 2:41 PM

> Tom,
>
> Thanks for the comments.
>
> On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote:
> > but reading Architecture, the examples I see are ones that seem t= o
fall
> > within the remit of NETCONF (being config) as and when a suitable=
data
> > model has been defined (e.g. for OSPF or BGP). =C2=A0Initially I = had
thought
> > of several things that I2RS might do but these have been ruled ou= t,
>
> It'd help if you listed the ones in question. =C2=A0Some of these = things
may be
> part of the work that is left currently out of scope to attempt to
constrain
> the WG to things we have decided to get done first. =C2=A0(Don't b= ite off
more
> than you can chew.)

e.g.
6.2.3. =C2=A0Reversion "In all such cases, the state will revert to wh= at it
would have been without the I2RS; that state is generally whatever was
specified via the CLI, NETCONF, SNMP, etc."
which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it to Y then disappears so it reverts to X, for all values of 'it' - i= .e.
'it' is what NETCONF would call config and so could have been set b= y
NETCONF, no need for I2RS!

[Alia] If th= e state couldn't be set via CLI/NETCONF/SNMP etc, then the state will r= evert
to the system default or what was dynamically learned (if t= hat was something safe to
be overwritten). =C2=A0This is describing what the behavior should be = when written state is
deleted by I2RS - not making a statement on= what the scope of the models are.=C2=A0
=C2=A0
6.3. =C2=A0Interactions with Local Config "Changes may originate from = either
Local Config or from I2RS."
Taking Local Config to be what NETCONF/YANG calls 'config' then aga= in,
nothing there it seems that C/N/S cannot do

=
[Alia] Again - generically changes can originate - but that doesn'= t mean that the full scope
will originate from either. =C2=A0Coll= isions and interactions are of interest when they both can.
=C2=A0

6.4.2" =C2=A0o =C2=A0writing policy information such as interface attr= ibutes that
are
=C2=A0 =C2=A0 =C2=A0 specific to the routing protocol or BGP policy that ma= y indirectly
=C2=A0 =C2=A0 =C2=A0 manipulate attributes of routes carried in BGP.

=C2=A0 =C2=A0o =C2=A0writing routes or prefixes to be advertised via the pr= otocol"
I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the I-D goes on to say
" direct modification of the link-state database MUST NOT be allowed&q= uot;
(which I have seen on the list w.r.t. the BGP RIB).
[Alia] Right - because doing so seriously risks breaking the r= outing protocol and leading
to incorrect behavior. =C2=A0Let'= s crawl before we run a marathon!
=C2=A0
or

8" The interaction of state installed via the I2RS and via a router= 9;s
configuration needs to be clearly defined."
which again implies that I2RS and C/N/S are writing to the same data.

[Alia] If C/N/S write to the config which th= en writes to the operational data and
I2RS writes to the operatio= nal data, what is the final content of the operational data?
If I2RS can write set A and C/N/S can write set B, saying that A &= B overlap
doesn't imply that A =3D=3D B.
=C2=A0

The examples of data that can be changed are few, such as
"For example, the interaction with OSPF might include modifying the =C2=A0 =C2=A0local routing element's link metrics, announcing a locally= -attached
=C2=A0 =C2=A0prefix, .."
which leaves me wondering, do you expect an OSPF YANG model to be unable to change a link metric:-)

[Alia] Remem= ber that low latency, high throughput, and asynchronous operations are
all aspects of what I2RS is facilitating. =C2=A0There's a big dif= ference between change one and
change 1000+ in less than a second.=C2=A0

Whereever I look, I struggle to see what I2RS will write that C/N/S will not.

[Alia] Personally, I think that I2= RS will write lower-level abstractions (all the details for the
R= IB info-model which aren't a standard part of configuration) and subset= s of data that need
to change fast - plus being a good interface for push notifications an= d event streams. =C2=A0If you
are looking for examples, I'd l= ook at the use-cases.
=C2=A0
If I2RS were aiming at a higher level, say specifying policy and have
the system translate that into actual config changes I would understand
that, but I do not see I2RS going that far, rather when I2RS says
policy, I think it means changing a community (config again) or some
such ie more of an implementation detail than a high level strategy.

[Alia] True - and if I2RS is designed and imp= lemented well, possibly higher-level abstractions will also
be possible. =C2=A0We see the start of that at the desire to have a single = abstract link-state topology for reading,
for instance. =C2=A0The= WG is chartered to crawl first and see what's feasible. =C2=A0Getting = the problem-statement and
architecture out of the way, along with the language and protocol base= selection that has happened, is=C2=A0
likely to open up the abil= ity to seriously discuss detailed models.

Regards,=
Alia
=C2=A0

Tom Petch


>
> > either on the =C2=A0list or in this I-D, so I am left wondering w= hat it
is
> > that I2RS will do that NETCONF potentially cannot.
>
> The longer term question and netconf/yang continue to evolve (perhaps<= br> with
> impetus from our use cases) will generally be what work belongs in
various
> groups. =C2=A0Yang modules are being proposed in the various working g= roups
to
> cover protocol specific configuration and general management. =C2=A0Th= is is
> great! =C2=A0The question then becomes, where does I2RS fit into that = sort
of
> picture.
>
> One of the reasons I think nailing down specific requirements (as Jim<= br> Uttaro
> raised in a separete response) has come down to the somewhat nebulous<= br> > ability to interact with functionality that is either not quite a fit<= br> for
> standard config/query or interact with models that are one or more
levels of
> abstraction above a given protocol component.
>
> The degenerate case - the ability to ephemerally inject static routing=
> information - certainly seems like work that could be done outside of<= br> I2RS.
> Definitely so if it is decided that the ephemeral model is something that
> becomes core to netconf/restconf. =C2=A0(The question of how this is represented
> in the data model is the longer question.)
>
> Where the use cases start getting more substance are when we get
somewhat
> more abstract:
> - An API to the traffic engineering state in a routing system. =C2=A0T= his
is not
> =C2=A0 just the OSPF, IS-IS or BGP-LS TEDBs, it's a summary view. = =C2=A0Which
working
> =C2=A0 group produces that model if done on a per-protocol basis?
> - A policy layer on top of BGP. =C2=A0That's perhaps in-scope for = IDR or
GROW.
> =C2=A0 As you definitely know (:-) ) such a policy layer will interact= with
a lot
> =C2=A0 of non-BGP components and potentially other databases.
> - A management layer to provision VPN instances (service layer
routing).
> =C2=A0 Does that work get done in IDR? MPLS? L2/L3VPN?
>
> And of course, there's the whole matter of how do you bring togeth= er
> contributors with expertise in modeling, operations and the mix of
routing
> and other protocols in question and where do you do it? =C2=A0From the=
first BoF,
> it was clear there are a lot of people who want to work on the things<= br> that
> fall in these nebulous gaps between working groups.
>
> I2RS is here to be the big tent to let us gather people under to do that
> sort of work. =C2=A0Maintaining enough focus to make progress on a
constrained
> number of items is the main early challenge. =C2=A0A survey of the use= case
> documents should definitely suggest there's a lot more that people=
would
> like to work on.
>
>
> > I do find the I-D quite hard to follow as the terminology seems > > inconsistent - the word 'state' is much used but it is un= clear to me
if
> > the term can be given a single definition in this context; and ev= en
if
> > it can, the word seems an unfortunate choice since the IETF Ops A= rea
has
> > given it a precise definition which is at odds with its use here.=
>
> Are there specific edits you would suggest to clarify the document? >
> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

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

--20cf303a2f8d7b73b704fc888841-- From nobody Mon Jun 23 15:47:05 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD91B2D2A for ; Mon, 23 Jun 2014 15:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgdIU5J62JMw for ; Mon, 23 Jun 2014 15:46:56 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D5B1A03B1 for ; Mon, 23 Jun 2014 15:46:56 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so5590741yha.36 for ; Mon, 23 Jun 2014 15:46:56 -0700 (PDT) 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=1vPEXcQqIokDPzR97palU4TWV6KBgUZVOxgNXgBDt9w=; b=XKasbEXUNFHYbcHHpKbXBu1gYpkifPjFzhbE2P/IfMMHZdqBStfVyBJTVjZBlneQCA JBOTlvBxZHPeWZLwdN7fYlS3o7jnAUYDNMQNLKAx6p+s+ubat89zhV4iyVDgmBomjsiE dukliKsN3ukXHN6Co57g4gddPD7lTtLepYtP2Nrg8CvtCkkMJUiOm1XeUes4JIrKeUG3 EvZW5qOD7M8YeVG5oFg8Cz/CGpD81UWOdi1eyu9nMKVdEemGKPm0/Vus6WyPCFPUseum TqspgWrZzzPwkvbdd98Dkp1UrC6PanS6Yy5J00clHoBin9GIW/xRpxYrP9x/fUEumGq2 1NFg== MIME-Version: 1.0 X-Received: by 10.236.39.109 with SMTP id c73mr8847206yhb.139.1403563616028; Mon, 23 Jun 2014 15:46:56 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:46:55 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> Date: Mon, 23 Jun 2014 18:46:55 -0400 Message-ID: From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=001a1136bfcec0ce5a04fc889ee3 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Aitu3Gy99r2Hc4IU0CZTu8YN1oA Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:47:01 -0000 --001a1136bfcec0ce5a04fc889ee3 Content-Type: text/plain; charset=UTF-8 Hi Sri, Thanks for your thoughtful review! Responses in-line. On Tue, Jun 10, 2014 at 3:08 PM, Sriganesh Kini wrote: > > > > On Thu, Jun 5, 2014 at 1:29 PM, Jeffrey Haas wrote: > >> Working Group, >> >> The original deadline for comments on WGLC for the problem statement and >> architecture drafts of May 30 has passed with no comment whatsoever. >> >> While we all realize that there's a bit of exhaustion going on with regard >> to these drafts, they are a bit of process we simply must get done in >> order >> to fully move forward with our agenda of putting together data models. >> >> We are *NOT* going to hold that work up further - it is clear that there >> is >> consenus to start making that progress. >> >> To assist us with putting this work behind us, please respond to the >> following questions: >> >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ >> Have you read the problem statement draft? >> > > Yes. > > >> Do you think it is ready to be published as a RFC? >> (If no, please respond to the list with issues.) >> > > Yes. > > >> >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ >> Have you read the architecture draft? >> > > yes > > >> Do you think it is ready to be published as a RFC? >> (Ditto.) >> > > A question in sec 7.8. Second para. There is a sentence starting with "The > mechanism for this is to ..." and later it says "In order for this approach > to ...". The first sentence seems to imply that this is the only mechanism > allowed by this architecture whereas the second sentence seems to imply > that this is one possible mechanism and agents can choose other mechanisms > too. Which one is correct ? I would suggest that the language be updated to > reflect that. > [Alia] I think the confusion is that there are two mechanisms - one to ensure predictability that the I2RS Agent does and one for the I2RS Client to use to realize when its operations have been preempted. I've clarified the "The mechanism for this is to" to say "The mechanism for ensuring predictability is to have a simple priority associated with each I2RS clients, and the highest priority change remains in effect." Thanks, Alia > Otherwise the doc looks good to be published as a RFC. > > Sri > > >> >> -- Jeff >> >> _______________________________________________ >> 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 > > --001a1136bfcec0ce5a04fc889ee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sri,

Thanks for your = thoughtful review! =C2=A0Responses in-line.

On Tue, Jun 10, 2014 at 3:08 PM, Sriganesh Kini <sriganesh.ki= ni@ericsson.com> wrote:



On Thu, Jun 5, 2014 at 1:29 PM, Jeffrey Haas <jhaas@pfrc.org<= /a>> wrote:
Working Group,

The original deadline for comments on WGLC for the problem statement and architecture drafts of May 30 has passed with no comment whatsoever.

While we all realize that there's a bit of exhaustion going on with reg= ard
to these drafts, they are a bit of process we simply must get done in order=
to fully move forward with our agenda of putting together data models.

We are *NOT* going to hold that work up further - it is clear that there is=
consenus to start making that progress.

To assist us with putting this work behind us, please respond to the
following questions:

http://datatracker.ietf.org/doc/draft-ietf-i2rs-probl= em-statement/
Have you read the problem statement draft?

<= /div>
Yes.
=C2=A0
Do you think it is ready to be published as a RFC?
(If no, please respond to the list with issues.)

<= /div>
Yes.
=C2=A0

http://datatracker.ietf.org/doc/draft-ietf-i2rs-architectu= re/
Have you read the architecture draft?

=
yes
=C2=A0
Do you think it is ready to be published as a RFC?
(Ditto.)

A question in sec 7.8. S= econd para. There is a sentence starting with "The mechanism for this = is to ..." and later it says "In order for this approach to =C2= =A0...". The first sentence seems to imply that this is the only mecha= nism allowed by this architecture whereas the second sentence seems to impl= y that this is one possible mechanism and agents can choose other mechanism= s too. Which one is correct ? I would suggest that the language be updated = to reflect that.

[Alia] =C2=A0I think the= confusion is that there are two mechanisms - one to ensure predictability = that the I2RS Agent does and one for the I2RS Client to use to realize when= its operations have been preempted. =C2=A0I've clarified the "The= mechanism for this is to" to say
"The mechanism for ensuring predictability is to have a simple pr= iority associated with each I2RS clients, and the highest priority change r= emains in effect."

Thanks,
Alia=C2= =A0


Otherwise the doc looks good to be published as a RFC.<= /div>

Sri
=C2=A0

-- Jeff

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


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


--001a1136bfcec0ce5a04fc889ee3-- From nobody Mon Jun 23 15:53:51 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4A31A03B4 for ; Mon, 23 Jun 2014 15:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0hT0MkehdLr for ; Mon, 23 Jun 2014 15:53:47 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73D91A03B1 for ; Mon, 23 Jun 2014 15:53:46 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 10so5139666ykt.36 for ; Mon, 23 Jun 2014 15:53:46 -0700 (PDT) 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=+odn1bojDGbGN3V8lfFR++EhGqWwNmVw2Fe3R33elQc=; b=Gobp31FbO1qq80KKB+THetF5e7iU/OjEcPgtqA3BA/SRRvMFsTjEXiQk6xJyr0As1h 6fRpIpBZgxrPOU5XVVOnIxL12aTsY0bVPJC6jR51sk1w4Z62TR+tBDk3x3mcAqIRXsYm u0udzgxPGdxfcA9B5df3RMKpst6AIGCkZJpVhiRs3gWcZWQF5cgjSYTyafD2pq3PDDiZ xLGMOednVhHD//p1QuUPzeFT6WQZNwQGLhBzCKoNTYlWfzuS1Y1cYgya6MQyXDe7KH9V Hs9W6mXVL4wVQLGCQQYGao+HlDLfwrzURVOyaF5jusmqp4f475zc+AaeSpUl3Z4SyI9Z hmmg== MIME-Version: 1.0 X-Received: by 10.236.39.109 with SMTP id c73mr8891087yhb.139.1403564026255; Mon, 23 Jun 2014 15:53:46 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:53:46 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> <20140610201427.GF32305@pfrc> Date: Mon, 23 Jun 2014 18:53:46 -0400 Message-ID: From: Alia Atlas To: "George, Wes" Content-Type: multipart/alternative; boundary=001a1136bfce3461c604fc88b70f Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/HwwVWF_1wrDKaacK5yLQSYGBmVI Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:53:49 -0000 --001a1136bfce3461c604fc88b70f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Wes & Jeff, The problem with responding to email in order as I update the draft is finding useful nuggets like this. I've removed the previously suggested text from the "Interactions with Local Config" section and updated the "Manageability Considerations" section to be "Operational and Manageability Considerations" and plunked the following as the first paragraph. "In order to facilitate troubleshooting of routing elements implementing I2RS agents, those routing elements should provide for a mechanism to show actively provisioned I2RS state and other I2RS Agent internal information. Note that this information may contain highly sensitive material subject to the Security Considerations of any data models implemented by that Agent and thus must be protected according to those considerations. Preferably, this mechanism should use a different privileged means other than simply connecting as an I2RS client to learn the data. Using a different mechanism should improve traceability and failure management." Does that work for you both? Thanks, Alia On Thu, Jun 12, 2014 at 9:26 AM, George, Wes wrote: > > On 6/10/14, 4:14 PM, "Jeffrey Haas" wrote: > > >The traceability draft should hopefully give you the "what was requested= " > >end of the auditing spectrum. (Please comment in that thread, if > >otherwise.) > > I=E2=80=99ll read through the draft, at the latest when the adoption call= hits, > and make comments with this in mind. > > > > >What I believe you're asking is roughly something like the following tex= t > >in > >the architecture draft: > > > >X. Operational Considerations > > > >In order to facilitate troubleshooting of routing elements implementing > >I2RS > >agents, those routing elements should provide for a mechanism to show > >actively provisioned I2RS state. Note that this information may contain > >highly sensitive material subject to the Security Considerations of any > >data > >models implemented by that Agent and thus must be protected according to > >those considerations. > > Yes, I think the only thing that misses is the need for it to be > independent of the agent itself. > > Wes > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright 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 the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1136bfce3461c604fc88b70f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Wes & Jeff,

The problem with res= ponding to email in order as I update the draft is finding useful nuggets l= ike this.
I've removed the previously suggested text from the= "Interactions with Local Config" section and updated
the "Manageability Considerations" section to be "Opera= tional and Manageability Considerations" and plunked
the fol= lowing as the first paragraph. =C2=A0

"In ord= er to facilitate troubleshooting of routing elements
=C2=A0 implementing I2RS agents, those routing elements should provide= for
=C2=A0 a mechanism to show actively provisioned I2RS state a= nd other I2RS
=C2=A0 Agent internal information. =C2=A0Note that = this information may contain
=C2=A0 highly sensitive material subject to the Security Consideration= s of
=C2=A0 any data models implemented by that Agent and thus mu= st be protected
=C2=A0 according to those considerations. =C2=A0P= referably, this mechanism
=C2=A0 should use a different privileged means other than simply conne= cting
=C2=A0 as an I2RS client to learn the data. =C2=A0Using a d= ifferent mechanism
=C2=A0 should improve traceability and failure= management."

Does that work for you both?

T= hanks,
Alia




On Thu, Jun 12, 2014 at= 9:26 AM, George, Wes <wesley.george@twcable.com> wr= ote:

On 6/10/14, 4:14 PM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

>The traceability draft should hopefully give you the "what was req= uested"
>end of the auditing spectrum. =C2=A0(Please comment in that thread, if<= br> >otherwise.)

I=E2=80=99ll read through the draft, at the latest when the adoption = call hits,
and make comments with this in mind.

>
>What I believe you're asking is roughly something like the followin= g text
>in
>the architecture draft:
>
>X. Operational Considerations
>
>In order to facilitate troubleshooting of routing elements implementing=
>I2RS
>agents, those routing elements should provide for a mechanism to show >actively provisioned I2RS state. =C2=A0Note that this information may c= ontain
>highly sensitive material subject to the Security Considerations of any=
>data
>models implemented by that Agent and thus must be protected according t= o
>those considerations.

Yes, I think the only thing that misses is the need for it to be
independent of the agent itself.

Wes


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.
_____________________________= __________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--001a1136bfce3461c604fc88b70f-- From nobody Mon Jun 23 15:57:24 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826771A03B1 for ; Mon, 23 Jun 2014 15:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywczoMoPemLj for ; Mon, 23 Jun 2014 15:57:17 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4591A03A4 for ; Mon, 23 Jun 2014 15:57:16 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so5546689yha.8 for ; Mon, 23 Jun 2014 15:57:16 -0700 (PDT) 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=XDoGiiLbpI++Apg5Jwafk9aGDJkzwCdg1dhvfNQauUU=; b=tBxDMJ5ME+8Uy7mJZ6NHSPbvlLGG7y8PAlKH28GVSizCA19IP9A9qhVljV0g98sbGj 4MXGqfuqfywOu1XsdYv23W29JaM1vQ6zn5qdR/UI9rwBVPd3eWCAxXT/hMz3qrIUv9bR tGwF19YfL34sLLO+ZP7Io3CWUcc90/P0AaKW0WoPlF9wEGfphN4jh1eeqRbTfDp/No/N 4eDlc6BEVvbTp6gnS+UZtF79pZRnwSdpOQIY97iaKQdoZN3WJUGN9iBfzMVMm8eTd1B9 CznSEj7KI4PpPOd3Gt6Bde8IAK3dCLsK0BQ4cc0rhBuKbuGnZp4cXoKyJUMzfkbA2eIG s+mg== MIME-Version: 1.0 X-Received: by 10.236.132.139 with SMTP id o11mr39867547yhi.101.1403564236273; Mon, 23 Jun 2014 15:57:16 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 15:57:16 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> Date: Mon, 23 Jun 2014 18:57:16 -0400 Message-ID: From: Alia Atlas To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=20cf3005de28b8fcd604fc88c35a Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/wALNWUgU-mXuIo0ANuQEqDVYJrw Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 22:57:20 -0000 --20cf3005de28b8fcd604fc88c35a Content-Type: text/plain; charset=UTF-8 Hi Lada, On Thu, Jun 12, 2014 at 5:15 AM, Ladislav Lhotka wrote: > "t.petch" writes: > > > ----- Original Message ----- > > From: "Jeffrey Haas" > > To: "t.petch" > > Cc: "Jeffrey Haas" ; > > Sent: Tuesday, June 10, 2014 7:07 PM > >> Tom, > >> > >> [retaining lots of content for context] > > > > now elided as it is not so much about references to extracts of the > > architecture I-D > > > >> On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: > >> > ---- Original Message ----- > >> > From: "Jeffrey Haas" > >> > To: "t.petch" > >> > Cc: "Jeffrey Haas" ; > >> > Sent: Tuesday, June 10, 2014 2:41 PM > >> > > >> > > Tom, > >> > > > > > >> > >> This is much of what I had suggested about the semantics of > > introducing > >> ephemeral config into netconf. Our requirement is that these things > > are > >> ephemeral. (Although Tom Nadeau presents some nice cases as to why we > > may > >> want the equivalent of "write running-config" to permit persistence.) > >> > >> At this point, overlapping ephemeral configuration isn't something > > that > >> netconf supports. If you scan mail from the last month or so, you'll > > also > >> see some back and forth between Juergen and Andy and I about how we go > > about > >> representing such a thing in the yang model/modules. (And we never > > fully > >> converged.) > >> > >> From the config perspective, this ephemeral state wasn't something > > that I > >> believe was part of the config semantics of netconf/yang; it's an I2RS > >> requirement. Admittedly, once we have such a think then clearly > >> applications other than I2RS can make use of it. :-) > >> > >> Choosing a solution space will be the next challenge we have: > >> - Overlapping modules with i2rs context? > >> - Parallel modules? > >> - How to ensure maximum re-use of the yang modules for config in an > > i2rs > >> context if they are determined to have heavy overlap? > > > > Jeff > > > > Yes, I saw the thread - I think I started it and ended it! > > > > Leaving aside the question of just what objects I2RS wants to edit that > > NETCONF cannot (perhaps none:-), the rest of that thread seems clear to > > me. > > > > The architecture I-D talks of data store which I think unclear; I think > > that it should be datastore, as used in Ops Area (e.g. by NETCONF). > > > > The view that has evolved, and is reflected in the thread, is that > > NETCONF 'config true' is not really the configuration. The real > > configuration is the operational state, part learnt from protocols and > > hardware and part derived from 'config true'; but 'config true' is only > > what the operator would like to happen, the operational state is the > > reality. > > Yes, although platforms that control all channels through which the > operator can interact with the box often try to pretend that config and > operational state are the same. It is reflected somewhat in the design of > YANG where operational state data (config false) may be embedded within the > configuration tree. > > > > > Currently we only have 'config true' written by NETCONF in a > > configuration datastore (with operational state not being part of any > > datastore, just part of state, using that term in the Ops Area sense). > > What I2RS then adds is an I2RS datastore, may be one, may be several, > > which is another expression of hope as to what the box will do; > > operational state, as ever, tells us what actually happens. The rules > > of persistence for I2RS are whatever I2RS wants them to be with no > > impact on NETCONF. > > Agreed. > > > > > So I suggest that it is wrong, as I and others have said in the past, to > > talk of editing operational state; the writing of the basic NETMOD > > models have shown that that does not work. The model that has evolved > > is what I call twin trees, one of 'config true' - an aspiration of the > > operator - and the other of 'config false' - operational state, the > > reality. You can see signs of this in the NETMOD models of > > interfaces-cfg, routing-cfg, system-cfg and so on. > > Yes, and I plan to propose that the relationship of such twin trees be > formally stated in YANG models - currently it is only explained in > descriptions. > > > > > I2RS then adds a third tree to the model, of what it would like the box > > to do. I2RS would also need to specify how to resolve conflicts between > > NETCONF and I2RS should they specify different values for the same > > object. This is already an issue, IMO not fully resolved, when the user > > and the system have different views of what should happen - look for > > user-controlled and system-controlled in interfaces-cfg. > > It is necessary to think about some arbitration rules that prevent NETCONF > and I2RS (or other means for changing operational state) to stomp on each > other's toes. I don't think though this has anything to do with > user/system-controlled interfaces. > [Alia] We described the arbitration rules in Section 6.3 of draft-ietf-i2rs-architecture-03. > > > > So one module, three trees, an additional YANG substatement for a leaf > > that is writable by I2RS. > > Rather than inventing new annotations, I'd rather like to see making YANG > less NETCONF-specific so that it could directly define schema and > constraints for other datastores such as the one for I2RS. > [Alia] Please - I think there are different assumptions... Regards, Alia > > Lada > > > > > Tom Petch > > > > > >> > 6.4.2" o writing policy information such as interface attributes > > that > >> > are > >> > specific to the routing protocol or BGP policy that may > > indirectly > >> > manipulate attributes of routes carried in BGP. > >> > > >> > o writing routes or prefixes to be advertised via the protocol" > >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but > > the > >> > I-D goes on to say > >> > " direct modification of the link-state database MUST NOT be > > allowed" > >> > (which I have seen on the list w.r.t. the BGP RIB). > >> > > >> > or > >> > > >> > 8" The interaction of state installed via the I2RS and via a > > router's > >> > configuration needs to be clearly defined." > >> > which again implies that I2RS and C/N/S are writing to the same > > data. > >> > >> *Maybe.* > >> > >> In some cases, the overlap with config state will be quite obvious and > > your > >> observation will strongly hold. > >> > >> In other cases, I think a better perspective is that I2RS injected > > state is > >> effectively like that of another routing protocol. > >> > >> If you'd like to argue that BGP is effectively the same as C/N/S... > > well, if > >> we're talking Flowspec I might agree. :-) > >> > >> > The examples of data that can be changed are few, such as > >> > "For example, the interaction with OSPF might include modifying the > >> > local routing element's link metrics, announcing a > > locally-attached > >> > prefix, .." > >> > which leaves me wondering, do you expect an OSPF YANG model to be > > unable > >> > to change a link metric:-) > >> > >> Sure. In a highly dynamic fashion? With a fallback to a default > > config when > >> the application is done? > >> > >> By comparison to some vendor specific features, it's somewhat the > > difference > >> between a policy database (config) and the dynamic policy API that > > doesn't > >> require a system reconfiguration event. If you want to point out that > > the > >> relationship is strong and that the defining differences are shallow - > > you > >> could very well be right in those contexts. > >> > >> Again, we don't expect I2RS work to supplant netconf/yang. We expect > > to > >> leverage the work. > >> > >> > If I2RS were aiming at a higher level, say specifying policy and > > have > >> > the system translate that into actual config changes I would > > understand > >> > that, but I do not see I2RS going that far, rather when I2RS says > >> > policy, I think it means changing a community (config again) or some > >> > such ie more of an implementation detail than a high level strategy. > >> > >> I hesitate to frame it this way, but one example application is a form > > of > >> SDN. The front end says "provision this VPN" to a data model for that > >> purpose. The fact that it may go behind the covers via client->agent > > and > >> eventually install ephemeral netconf state is an implementation > > detail. > >> > >> If you want to argue that such a higher level model is simply netconf, > > then > >> perhaps we should de-charter and do all of the work in that group. I > > was, > >> however, under the impression that work for various models was being > > pushed > >> to be done in appropriate working groups. :-) > >> > >> -- Jeff > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf3005de28b8fcd604fc88c35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lada,


On Thu, Jun 12, 2014 at 5:15 AM, Ladislav Lhotka <lhotka@nic.= cz> wrote:
&quo= t;t.petch" <ietfc@btconnect.= com> writes:

> ----- Original Message -----
> From: "Jeffrey Haas" <j= haas@pfrc.org>
> To: "t.petch" <iet= fc@btconnect.com>
> Cc: "Jeffrey Haas" <jha= as@pfrc.org>; <i2rs@ietf.org= >
> Sent: Tuesday, June 10, 2014 7:07 PM
>> Tom,
>>
>> [retaining lots of content for context]
>
> now elided as it is not so much about references to extracts of the > architecture I-D
>
>> On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote:
>> > ---- Original Message -----
>> > From: "Jeffrey Haas" <jhaas@pfrc.org>
>> > To: "t.petch" <ietfc@btconnect.com>
>> > Cc: "Jeffrey Haas" <jhaas@pfrc.org>; <i2rs@iet= f.org>
>> > Sent: Tuesday, June 10, 2014 2:41 PM
>> >
>> > > Tom,
>> > >
> <snip>
>>
>> This is much of what I had suggested about the semantics of
> introducing
>> ephemeral config into netconf. =C2=A0Our requirement is that these= things
> are
>> ephemeral. =C2=A0(Although Tom Nadeau presents some nice cases as = to why we
> may
>> want the equivalent of "write running-config" to permit = persistence.)
>>
>> At this point, overlapping ephemeral configuration isn't somet= hing
> that
>> netconf supports. =C2=A0If you scan mail from the last month or so= , you'll
> also
>> see some back and forth between Juergen and Andy and I about how w= e go
> about
>> representing such a thing in the yang model/modules. =C2=A0(And we= never
> fully
>> converged.)
>>
>> From the config perspective, this ephemeral state wasn't somet= hing
> that I
>> believe was part of the config semantics of netconf/yang; it's= an I2RS
>> requirement. =C2=A0Admittedly, once we have such a think then clea= rly
>> applications other than I2RS can make use of it. :-)
>>
>> Choosing a solution space will be the next challenge we have:
>> - Overlapping modules with i2rs context?
>> - Parallel modules?
>> =C2=A0 - How to ensure maximum re-use of the yang modules for conf= ig in an
> i2rs
>> =C2=A0 =C2=A0 context if they are determined to have heavy overlap= ?
>
> Jeff
>
> Yes, I saw the thread - I think I started it and ended it!
>
> Leaving aside the question of just what objects I2RS wants to edit tha= t
> NETCONF cannot (perhaps none:-), the rest of that thread seems clear t= o
> me.
>
> The architecture I-D talks of data store which I think unclear; I thin= k
> that it should be datastore, as used in Ops Area (e.g. by NETCONF). >
> The view that has evolved, and is reflected in the thread, =C2=A0is th= at
> NETCONF 'config true' is not really the configuration. =C2=A0T= he real
> configuration is the operational state, part learnt from protocols and=
> hardware and part derived from 'config true'; but 'config = true' is only
> what the operator would like to happen, the operational state is the > reality.

Yes, although platforms that control all channels through which= the operator can interact with the box often try to pretend that config an= d operational state are the same. It is reflected somewhat in the design of= YANG where operational state data (config false) may be embedded within th= e configuration tree.

>
> Currently we only have 'config true' written by NETCONF in a > configuration datastore (with operational state not being part of any<= br> > datastore, just part of state, using that term in the Ops Area sense).=
> What I2RS then adds is an I2RS datastore, may be one, may be several,<= br> > which is another expression of hope as to what the box will do;
> operational state, as ever, tells us what actually happens. =C2=A0The = rules
> of persistence for I2RS are whatever I2RS wants them to be with no
> impact on NETCONF.

Agreed.

>
> So I suggest that it is wrong, as I and others have said in the past, = to
> talk of editing operational state; the writing of the basic NETMOD
> models have shown that that does not work. =C2=A0The model that has ev= olved
> is what I call twin trees, one of 'config true' - an aspiratio= n of the
> operator - and the other of 'config false' - operational state= , the
> reality. =C2=A0You can see signs of this in the NETMOD models of
> interfaces-cfg, routing-cfg, system-cfg and so on.

Yes, and I plan to propose that the relationship of such twin trees b= e formally stated in YANG models - currently it is only explained in descri= ptions.

>
> I2RS then adds a third tree to the model, of what it would like the bo= x
> to do. =C2=A0I2RS would also need to specify how to resolve conflicts = between
> NETCONF and I2RS should they specify different values for the same
> object. =C2=A0This is already an issue, IMO not fully resolved, when t= he user
> and the system have different views of what should happen - =C2=A0look= for
> user-controlled and system-controlled in interfaces-cfg.

It is necessary to think about some arbitration rules that prevent NE= TCONF and I2RS (or other means for changing operational state) to stomp on = each other's toes. I don't think though this has anything to do wit= h user/system-controlled interfaces.

[Alia] We described the arbitration rules = in Section 6.3 of draft-ietf-i2rs-architecture-03.
=C2=A0
>
> So one module, three trees, an additional YANG substatement for a leaf=
> that is writable by I2RS.

Rather than inventing new annotations, I'd rather like to see mak= ing YANG less NETCONF-specific so that it could directly define schema and = constraints for other datastores such as the one for I2RS.

[Alia] Please - I think there are different assumptions= ...

Regards,
Alia
=C2=A0
=

Lada

>
> Tom Petch
>
>
>> > 6.4.2" =C2=A0o =C2=A0writing policy information such as = interface attributes
> that
>> > are
>> > =C2=A0 =C2=A0 =C2=A0 specific to the routing protocol or BGP = policy that may
> indirectly
>> > =C2=A0 =C2=A0 =C2=A0 manipulate attributes of routes carried = in BGP.
>> >
>> > =C2=A0 =C2=A0o =C2=A0writing routes or prefixes to be adverti= sed via the protocol"
>> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-= RIB but
> the
>> > I-D goes on to say
>> > " direct modification of the link-state database MUST NO= T be
> allowed"
>> > (which I have seen on the list w.r.t. the BGP RIB).
>> >
>> > or
>> >
>> > 8" The interaction of state installed via the I2RS and v= ia a
> router's
>> > configuration needs to be clearly defined."
>> > which again implies that I2RS and C/N/S are writing to the sa= me
> data.
>>
>> *Maybe.*
>>
>> In some cases, the overlap with config state will be quite obvious= and
> your
>> observation will strongly hold.
>>
>> In other cases, I think a better perspective is that I2RS injected=
> state is
>> effectively like that of another routing protocol.
>>
>> If you'd like to argue that BGP is effectively the same as C/N= /S...
> well, if
>> we're talking Flowspec I might agree. :-)
>>
>> > The examples of data that can be changed are few, such as
>> > "For example, the interaction with OSPF might include mo= difying the
>> > =C2=A0 =C2=A0local routing element's link metrics, announ= cing a
> locally-attached
>> > =C2=A0 =C2=A0prefix, .."
>> > which leaves me wondering, do you expect an OSPF YANG model t= o be
> unable
>> > to change a link metric:-)
>>
>> Sure. =C2=A0In a highly dynamic fashion? With a fallback to a defa= ult
> config when
>> the application is done?
>>
>> By comparison to some vendor specific features, it's somewhat = the
> difference
>> between a policy database (config) and the dynamic policy API that=
> doesn't
>> require a system reconfiguration event. =C2=A0If you want to point= out that
> the
>> relationship is strong and that the defining differences are shall= ow -
> you
>> could very well be right in those contexts.
>>
>> Again, we don't expect I2RS work to supplant netconf/yang. =C2= =A0We expect
> to
>> leverage the work.
>>
>> > If I2RS were aiming at a higher level, say specifying policy = and
> have
>> > the system translate that into actual config changes I would<= br> > understand
>> > that, but I do not see I2RS going that far, rather when I2RS = says
>> > policy, I think it means changing a community (config again) = or some
>> > such ie more of an implementation detail than a high level st= rategy.
>>
>> I hesitate to frame it this way, but one example application is a = form
> of
>> SDN. =C2=A0The front end says "provision this VPN" to a = data model for that
>> purpose. =C2=A0The fact that it may go behind the covers via clien= t->agent
> and
>> eventually install ephemeral netconf state is an implementation > detail.
>>
>> If you want to argue that such a higher level model is simply netc= onf,
> then
>> perhaps we should de-charter and do all of the work in that group.= I
> was,
>> however, under the impression that work for various models was bei= ng
> pushed
>> to be done in appropriate working groups. :-)
>>
>> -- Jeff
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--20cf3005de28b8fcd604fc88c35a-- From nobody Mon Jun 23 16:05:25 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1E1A03A4; Mon, 23 Jun 2014 16:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLUGCtppB0C7; Mon, 23 Jun 2014 16:05:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD67E1B2D38; Mon, 23 Jun 2014 16:05:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623230516.26822.91689.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 16:05:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Wi0UTb2gQ6y3fpSQdur-e65uba4 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-architecture-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:05:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : An Architecture for the Interface to the Routing System Authors : Alia Atlas Joel Halpern Susan Hares Dave Ward Thomas D. Nadeau Filename : draft-ietf-i2rs-architecture-04.txt Pages : 31 Date : 2014-06-23 Abstract: This document describes an architecture for a standard, programmatic interface for state transfer in and out of the internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-architecture-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-architecture-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 16:09:29 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1E61A03B1; Mon, 23 Jun 2014 16:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiQSJfWV9Qqt; Mon, 23 Jun 2014 16:09:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 776481B2D2A; Mon, 23 Jun 2014 16:09:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140623230921.30149.3696.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 16:09:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/eF9Ke0WzyQU9eAZNOyIXvXBDAfY Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:09:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Interface to the Routing System Problem Statement Authors : Alia Atlas Thomas D. Nadeau Dave Ward Filename : draft-ietf-i2rs-problem-statement-04.txt Pages : 10 Date : 2014-06-23 Abstract: As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, asynchronous interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Routing System (I2RS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 23 16:10:04 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A5B1B2D3B for ; Mon, 23 Jun 2014 16:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wUYAuVI0Rwi for ; Mon, 23 Jun 2014 16:09:58 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61AA81B2D34 for ; Mon, 23 Jun 2014 16:09:57 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so5555767yho.39 for ; Mon, 23 Jun 2014 16:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=a4dEBQKqCwlZq58gsyroExvs3xCvVxmiU4wLu62tp0I=; b=xd3Nil5VOBoy82k2cC7TKf04X3jQAx6LxFh56rEJ4EgYK5Zfj71UJKDJIvdthQG9OJ 6nWfTgJFVdY33evzukvGJxVZYeb1GABFJDTtd7wvwOIQvcu/stFoBD6zkWdxhUXHkzFo nVLtXtH+0dooJ1fyW2WbQ0+xGzBazC6O8l9tJvOgSk+X5/VwFrcck68nEmXuU6O7LixK T9eNvj1AV+4Hs9na5WEPEKXl52tva/Iu4crmdIBFaNtgU/4HFp8DoQJFo4sKZ3B/q2VJ 30OUF1uDfzbd+KAMlh1h8yJqIpwB8TsVtxxWBCcy/pNaynqh0pIoyGL4IiXcgPaN5Sic WtaQ== MIME-Version: 1.0 X-Received: by 10.236.54.166 with SMTP id i26mr39405102yhc.109.1403564996648; Mon, 23 Jun 2014 16:09:56 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Mon, 23 Jun 2014 16:09:56 -0700 (PDT) Date: Mon, 23 Jun 2014 19:09:56 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec50b51120b67d104fc88f18e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/QTUXr_D9KfrvfkF3yWigUQ6bA4M Subject: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 23:10:02 -0000 --bcaec50b51120b67d104fc88f18e Content-Type: text/plain; charset=UTF-8 Based upon the WGLC comments, I have updated these two drafts. Because I believe that the changes are not particularly controversial (except for the new reference to NETCONF and RESTCONF), I've published the updated versions so that the WG can verify the changes at the same time as my co-authors. The differences for the architecture draft can be found at: http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-architecture-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-architecture-04 and for the problem-statement at: http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-problem-statement-04 Thanks, Alia --bcaec50b51120b67d104fc88f18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based upon the WGLC comments, I have updated these two dra= fts. =C2=A0Because I believe that the changes are not particularly controve= rsial (except for the new reference to NETCONF and RESTCONF), I've publ= ished the updated versions so that the WG can verify the changes at the sam= e time as my co-authors.

--bcaec50b51120b67d104fc88f18e-- From nobody Tue Jun 24 02:53:56 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083911B29A0 for ; Tue, 24 Jun 2014 02:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2kT0xiITv02 for ; Tue, 24 Jun 2014 02:53:50 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7D51B2833 for ; Tue, 24 Jun 2014 02:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0AE3F5408D4; Tue, 24 Jun 2014 11:53:48 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9+7x8rSjWIE; Tue, 24 Jun 2014 11:53:43 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id D8A87540336; Tue, 24 Jun 2014 11:53:41 +0200 (CEST) From: Ladislav Lhotka To: Alia Atlas In-Reply-To: References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 24 Jun 2014 11:53:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/rH4qHMDlxnGXxzyI2NnpnTPS-L4 Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 09:53:53 -0000 Alia Atlas writes: > Hi Lada, > > > On Thu, Jun 12, 2014 at 5:15 AM, Ladislav Lhotka wrote: > >> "t.petch" writes: >> >> > ----- Original Message ----- >> > From: "Jeffrey Haas" >> > To: "t.petch" >> > Cc: "Jeffrey Haas" ; >> > Sent: Tuesday, June 10, 2014 7:07 PM >> >> Tom, >> >> >> >> [retaining lots of content for context] >> > >> > now elided as it is not so much about references to extracts of the >> > architecture I-D >> > >> >> On Tue, Jun 10, 2014 at 04:25:53PM +0100, t.petch wrote: >> >> > ---- Original Message ----- >> >> > From: "Jeffrey Haas" >> >> > To: "t.petch" >> >> > Cc: "Jeffrey Haas" ; >> >> > Sent: Tuesday, June 10, 2014 2:41 PM >> >> > >> >> > > Tom, >> >> > > >> > >> >> >> >> This is much of what I had suggested about the semantics of >> > introducing >> >> ephemeral config into netconf. Our requirement is that these things >> > are >> >> ephemeral. (Although Tom Nadeau presents some nice cases as to why we >> > may >> >> want the equivalent of "write running-config" to permit persistence.) >> >> >> >> At this point, overlapping ephemeral configuration isn't something >> > that >> >> netconf supports. If you scan mail from the last month or so, you'll >> > also >> >> see some back and forth between Juergen and Andy and I about how we go >> > about >> >> representing such a thing in the yang model/modules. (And we never >> > fully >> >> converged.) >> >> >> >> From the config perspective, this ephemeral state wasn't something >> > that I >> >> believe was part of the config semantics of netconf/yang; it's an I2RS >> >> requirement. Admittedly, once we have such a think then clearly >> >> applications other than I2RS can make use of it. :-) >> >> >> >> Choosing a solution space will be the next challenge we have: >> >> - Overlapping modules with i2rs context? >> >> - Parallel modules? >> >> - How to ensure maximum re-use of the yang modules for config in an >> > i2rs >> >> context if they are determined to have heavy overlap? >> > >> > Jeff >> > >> > Yes, I saw the thread - I think I started it and ended it! >> > >> > Leaving aside the question of just what objects I2RS wants to edit that >> > NETCONF cannot (perhaps none:-), the rest of that thread seems clear to >> > me. >> > >> > The architecture I-D talks of data store which I think unclear; I think >> > that it should be datastore, as used in Ops Area (e.g. by NETCONF). >> > >> > The view that has evolved, and is reflected in the thread, is that >> > NETCONF 'config true' is not really the configuration. The real >> > configuration is the operational state, part learnt from protocols and >> > hardware and part derived from 'config true'; but 'config true' is only >> > what the operator would like to happen, the operational state is the >> > reality. >> >> Yes, although platforms that control all channels through which the >> operator can interact with the box often try to pretend that config and >> operational state are the same. It is reflected somewhat in the design of >> YANG where operational state data (config false) may be embedded within the >> configuration tree. >> >> > >> > Currently we only have 'config true' written by NETCONF in a >> > configuration datastore (with operational state not being part of any >> > datastore, just part of state, using that term in the Ops Area sense). >> > What I2RS then adds is an I2RS datastore, may be one, may be several, >> > which is another expression of hope as to what the box will do; >> > operational state, as ever, tells us what actually happens. The rules >> > of persistence for I2RS are whatever I2RS wants them to be with no >> > impact on NETCONF. >> >> Agreed. >> >> > >> > So I suggest that it is wrong, as I and others have said in the past, to >> > talk of editing operational state; the writing of the basic NETMOD >> > models have shown that that does not work. The model that has evolved >> > is what I call twin trees, one of 'config true' - an aspiration of the >> > operator - and the other of 'config false' - operational state, the >> > reality. You can see signs of this in the NETMOD models of >> > interfaces-cfg, routing-cfg, system-cfg and so on. >> >> Yes, and I plan to propose that the relationship of such twin trees be >> formally stated in YANG models - currently it is only explained in >> descriptions. >> >> > >> > I2RS then adds a third tree to the model, of what it would like the box >> > to do. I2RS would also need to specify how to resolve conflicts between >> > NETCONF and I2RS should they specify different values for the same >> > object. This is already an issue, IMO not fully resolved, when the user >> > and the system have different views of what should happen - look for >> > user-controlled and system-controlled in interfaces-cfg. >> >> It is necessary to think about some arbitration rules that prevent NETCONF >> and I2RS (or other means for changing operational state) to stomp on each >> other's toes. I don't think though this has anything to do with >> user/system-controlled interfaces. >> > > [Alia] We described the arbitration rules in Section 6.3 of > draft-ietf-i2rs-architecture-03. I guess we have to think about a proper representation of operational state and ways for tagging its contents or otherwise signalling what caused a particular change. For instance, if a configured static route is not present in a RIB (operational state), it may be because - the next hop wasn't reachable when the static route was configured, or - the I2RS agent deleted it. The NETCONF server should be able to discriminate between these two cases because its action (reinstall the route or not) may depend on it. Lada > > >> > >> > So one module, three trees, an additional YANG substatement for a leaf >> > that is writable by I2RS. >> >> Rather than inventing new annotations, I'd rather like to see making YANG >> less NETCONF-specific so that it could directly define schema and >> constraints for other datastores such as the one for I2RS. >> > > [Alia] Please - I think there are different assumptions... > > Regards, > Alia > > >> >> Lada >> >> > >> > Tom Petch >> > >> > >> >> > 6.4.2" o writing policy information such as interface attributes >> > that >> >> > are >> >> > specific to the routing protocol or BGP policy that may >> > indirectly >> >> > manipulate attributes of routes carried in BGP. >> >> > >> >> > o writing routes or prefixes to be advertised via the protocol" >> >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but >> > the >> >> > I-D goes on to say >> >> > " direct modification of the link-state database MUST NOT be >> > allowed" >> >> > (which I have seen on the list w.r.t. the BGP RIB). >> >> > >> >> > or >> >> > >> >> > 8" The interaction of state installed via the I2RS and via a >> > router's >> >> > configuration needs to be clearly defined." >> >> > which again implies that I2RS and C/N/S are writing to the same >> > data. >> >> >> >> *Maybe.* >> >> >> >> In some cases, the overlap with config state will be quite obvious and >> > your >> >> observation will strongly hold. >> >> >> >> In other cases, I think a better perspective is that I2RS injected >> > state is >> >> effectively like that of another routing protocol. >> >> >> >> If you'd like to argue that BGP is effectively the same as C/N/S... >> > well, if >> >> we're talking Flowspec I might agree. :-) >> >> >> >> > The examples of data that can be changed are few, such as >> >> > "For example, the interaction with OSPF might include modifying the >> >> > local routing element's link metrics, announcing a >> > locally-attached >> >> > prefix, .." >> >> > which leaves me wondering, do you expect an OSPF YANG model to be >> > unable >> >> > to change a link metric:-) >> >> >> >> Sure. In a highly dynamic fashion? With a fallback to a default >> > config when >> >> the application is done? >> >> >> >> By comparison to some vendor specific features, it's somewhat the >> > difference >> >> between a policy database (config) and the dynamic policy API that >> > doesn't >> >> require a system reconfiguration event. If you want to point out that >> > the >> >> relationship is strong and that the defining differences are shallow - >> > you >> >> could very well be right in those contexts. >> >> >> >> Again, we don't expect I2RS work to supplant netconf/yang. We expect >> > to >> >> leverage the work. >> >> >> >> > If I2RS were aiming at a higher level, say specifying policy and >> > have >> >> > the system translate that into actual config changes I would >> > understand >> >> > that, but I do not see I2RS going that far, rather when I2RS says >> >> > policy, I think it means changing a community (config again) or some >> >> > such ie more of an implementation detail than a high level strategy. >> >> >> >> I hesitate to frame it this way, but one example application is a form >> > of >> >> SDN. The front end says "provision this VPN" to a data model for that >> >> purpose. The fact that it may go behind the covers via client->agent >> > and >> >> eventually install ephemeral netconf state is an implementation >> > detail. >> >> >> >> If you want to argue that such a higher level model is simply netconf, >> > then >> >> perhaps we should de-charter and do all of the work in that group. I >> > was, >> >> however, under the impression that work for various models was being >> > pushed >> >> to be done in appropriate working groups. :-) >> >> >> >> -- Jeff >> > >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 24 05:46:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC451B2909 for ; Tue, 24 Jun 2014 05:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBFxPu3yG_0G for ; Tue, 24 Jun 2014 05:46:13 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0111A1B28D6 for ; Tue, 24 Jun 2014 05:46:12 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,537,1400040000"; d="scan'208,217";a="370834229" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jun 2014 08:45:53 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 24 Jun 2014 08:46:11 -0400 From: "George, Wes" To: Alia Atlas Date: Tue, 24 Jun 2014 08:46:09 -0400 Thread-Topic: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) Thread-Index: Ac+PqkaFei3nnVlDR0C7ES85iLW6xg== Message-ID: References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> <20140610201427.GF32305@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFCEEB451FE7Bwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/5II9yf2tJRCfSROmTFhTVaB1HM0 Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 12:46:16 -0000 --_000_CFCEEB451FE7Bwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V0ZNDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KRnJvbTogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFp bC5jb208bWFpbHRvOmFrYXRsYXNAZ21haWwuY29tPj4NCkRhdGU6IE1vbmRheSwgSnVuZSAyMywg MjAxNCBhdCA2OjUzIFBNDQpUbzogIkdlb3JnZSwgV2VzIiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxl LmNvbTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4+DQpDYzogSmVmZnJleSBIYWFz IDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiwgImkycnNAaWV0Zi5vcmc8 bWFpbHRvOmkycnNAaWV0Zi5vcmc+IiA8aTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW2kycnNdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uIGFyY2hp dGVjdHVyZSBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnRzIChyZWR1eCkNCg0KSGkgV2VzICYg SmVmZiwNCg0KVGhlIHByb2JsZW0gd2l0aCByZXNwb25kaW5nIHRvIGVtYWlsIGluIG9yZGVyIGFz IEkgdXBkYXRlIHRoZSBkcmFmdCBpcyBmaW5kaW5nIHVzZWZ1bCBudWdnZXRzIGxpa2UgdGhpcy4N CkkndmUgcmVtb3ZlZCB0aGUgcHJldmlvdXNseSBzdWdnZXN0ZWQgdGV4dCBmcm9tIHRoZSAiSW50 ZXJhY3Rpb25zIHdpdGggTG9jYWwgQ29uZmlnIiBzZWN0aW9uIGFuZCB1cGRhdGVkDQp0aGUgIk1h bmFnZWFiaWxpdHkgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24gdG8gYmUgIk9wZXJhdGlvbmFsIGFu ZCBNYW5hZ2VhYmlsaXR5IENvbnNpZGVyYXRpb25zIiBhbmQgcGx1bmtlZA0KdGhlIGZvbGxvd2lu ZyBhcyB0aGUgZmlyc3QgcGFyYWdyYXBoLg0KDQoiSW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0cm91 Ymxlc2hvb3Rpbmcgb2Ygcm91dGluZyBlbGVtZW50cw0KICBpbXBsZW1lbnRpbmcgSTJSUyBhZ2Vu dHMsIHRob3NlIHJvdXRpbmcgZWxlbWVudHMgc2hvdWxkIHByb3ZpZGUgZm9yDQogIGEgbWVjaGFu aXNtIHRvIHNob3cgYWN0aXZlbHkgcHJvdmlzaW9uZWQgSTJSUyBzdGF0ZSBhbmQgb3RoZXIgSTJS Uw0KICBBZ2VudCBpbnRlcm5hbCBpbmZvcm1hdGlvbi4gIE5vdGUgdGhhdCB0aGlzIGluZm9ybWF0 aW9uIG1heSBjb250YWluDQogIGhpZ2hseSBzZW5zaXRpdmUgbWF0ZXJpYWwgc3ViamVjdCB0byB0 aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb2YNCiAgYW55IGRhdGEgbW9kZWxzIGltcGxlbWVu dGVkIGJ5IHRoYXQgQWdlbnQgYW5kIHRodXMgbXVzdCBiZSBwcm90ZWN0ZWQNCiAgYWNjb3JkaW5n IHRvIHRob3NlIGNvbnNpZGVyYXRpb25zLiAgUHJlZmVyYWJseSwgdGhpcyBtZWNoYW5pc20NCiAg c2hvdWxkIHVzZSBhIGRpZmZlcmVudCBwcml2aWxlZ2VkIG1lYW5zIG90aGVyIHRoYW4gc2ltcGx5 IGNvbm5lY3RpbmcNCiAgYXMgYW4gSTJSUyBjbGllbnQgdG8gbGVhcm4gdGhlIGRhdGEuICBVc2lu ZyBhIGRpZmZlcmVudCBtZWNoYW5pc20NCiAgc2hvdWxkIGltcHJvdmUgdHJhY2VhYmlsaXR5IGFu ZCBmYWlsdXJlIG1hbmFnZW1lbnQuIg0KDQpEb2VzIHRoYXQgd29yayBmb3IgeW91IGJvdGg/DQoN ClRoYW5rcywNCkFsaWENCg0KDQoNCg0KT24gVGh1LCBKdW4gMTIsIDIwMTQgYXQgOToyNiBBTSwg R2VvcmdlLCBXZXMgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208bWFpbHRvOndlc2xleS5nZW9y Z2VAdHdjYWJsZS5jb20+PiB3cm90ZToNCg0KT24gNi8xMC8xNCwgNDoxNCBQTSwgIkplZmZyZXkg SGFhcyIgPGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+IHdyb3RlOg0KDQo+ VGhlIHRyYWNlYWJpbGl0eSBkcmFmdCBzaG91bGQgaG9wZWZ1bGx5IGdpdmUgeW91IHRoZSAid2hh dCB3YXMgcmVxdWVzdGVkIg0KPmVuZCBvZiB0aGUgYXVkaXRpbmcgc3BlY3RydW0uICAoUGxlYXNl IGNvbW1lbnQgaW4gdGhhdCB0aHJlYWQsIGlmDQo+b3RoZXJ3aXNlLikNCg0KSeKAmWxsIHJlYWQg dGhyb3VnaCB0aGUgZHJhZnQsIGF0IHRoZSBsYXRlc3Qgd2hlbiB0aGUgYWRvcHRpb24gY2FsbCBo aXRzLA0KYW5kIG1ha2UgY29tbWVudHMgd2l0aCB0aGlzIGluIG1pbmQuDQoNCj4NCj5XaGF0IEkg YmVsaWV2ZSB5b3UncmUgYXNraW5nIGlzIHJvdWdobHkgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxv d2luZyB0ZXh0DQo+aW4NCj50aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Og0KPg0KPlguIE9wZXJhdGlv bmFsIENvbnNpZGVyYXRpb25zDQo+DQo+SW4gb3JkZXIgdG8gZmFjaWxpdGF0ZSB0cm91Ymxlc2hv b3Rpbmcgb2Ygcm91dGluZyBlbGVtZW50cyBpbXBsZW1lbnRpbmcNCj5JMlJTDQo+YWdlbnRzLCB0 aG9zZSByb3V0aW5nIGVsZW1lbnRzIHNob3VsZCBwcm92aWRlIGZvciBhIG1lY2hhbmlzbSB0byBz aG93DQo+YWN0aXZlbHkgcHJvdmlzaW9uZWQgSTJSUyBzdGF0ZS4gIE5vdGUgdGhhdCB0aGlzIGlu Zm9ybWF0aW9uIG1heSBjb250YWluDQo+aGlnaGx5IHNlbnNpdGl2ZSBtYXRlcmlhbCBzdWJqZWN0 IHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBvZiBhbnkNCj5kYXRhDQo+bW9kZWxzIGlt cGxlbWVudGVkIGJ5IHRoYXQgQWdlbnQgYW5kIHRodXMgbXVzdCBiZSBwcm90ZWN0ZWQgYWNjb3Jk aW5nIHRvDQo+dGhvc2UgY29uc2lkZXJhdGlvbnMuDQoNClllcywgSSB0aGluayB0aGUgb25seSB0 aGluZyB0aGF0IG1pc3NlcyBpcyB0aGUgbmVlZCBmb3IgaXQgdG8gYmUNCmluZGVwZW5kZW50IG9m IHRoZSBhZ2VudCBpdHNlbGYuDQoNCldlcw0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwg aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGlu IHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1h aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmkycnMgbWFpbGluZyBsaXN0DQppMnJzQGll dGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pMnJzDQoNCg== --_000_CFCEEB451FE7Bwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxkaXY+PGRpdj48ZGl2PldGTSZuYnNwOzwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPldlczxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsi Pjxicj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1h bGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRF Ui1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAw aW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJP UkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+IEFsaWEgQXRsYXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+YWthdGxhc0BnbWFpbC5jb208L2E+Jmd0Ozxicj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPiBNb25kYXksIEp1bmUgMjMs IDIwMTQgYXQgNjo1MyBQTTxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4gIkdlb3JnZSwgV2VzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xleS5nZW9yZ2VAdHdj YWJsZS5jb20iPndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0Ozxicj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4gSmVmZnJleSBIYWFzICZsdDs8YSBocmVm PSJtYWlsdG86amhhYXNAcGZyYy5vcmciPmpoYWFzQHBmcmMub3JnPC9hPiZndDssICI8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJt YWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+IFJlOiBbaTJyc10gV29ya2luZyBH cm91cCBMYXN0IENhbGwgb24gYXJjaGl0ZWN0dXJlIGFuZCBwcm9ibGVtIHN0YXRlbWVudCBkcmFm dHMgKHJlZHV4KTxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj5IaSBXZXMg JmFtcDsgSmVmZiw8ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBwcm9ibGVtIHdpdGggcmVzcG9uZGlu ZyB0byBlbWFpbCBpbiBvcmRlciBhcyBJIHVwZGF0ZSB0aGUgZHJhZnQgaXMgZmluZGluZyB1c2Vm dWwgbnVnZ2V0cyBsaWtlIHRoaXMuPC9kaXY+PGRpdj5JJ3ZlIHJlbW92ZWQgdGhlIHByZXZpb3Vz bHkgc3VnZ2VzdGVkIHRleHQgZnJvbSB0aGUgIkludGVyYWN0aW9ucyB3aXRoIExvY2FsIENvbmZp ZyIgc2VjdGlvbiBhbmQgdXBkYXRlZDwvZGl2PjxkaXY+dGhlICJNYW5hZ2VhYmlsaXR5IENvbnNp ZGVyYXRpb25zIiBzZWN0aW9uIHRvIGJlICJPcGVyYXRpb25hbCBhbmQgTWFuYWdlYWJpbGl0eSBD b25zaWRlcmF0aW9ucyIgYW5kIHBsdW5rZWQ8L2Rpdj48ZGl2PnRoZSBmb2xsb3dpbmcgYXMgdGhl IGZpcnN0IHBhcmFncmFwaC4gJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4iSW4gb3Jk ZXIgdG8gZmFjaWxpdGF0ZSB0cm91Ymxlc2hvb3Rpbmcgb2Ygcm91dGluZyBlbGVtZW50czwvZGl2 PjxkaXY+Jm5ic3A7IGltcGxlbWVudGluZyBJMlJTIGFnZW50cywgdGhvc2Ugcm91dGluZyBlbGVt ZW50cyBzaG91bGQgcHJvdmlkZSBmb3I8L2Rpdj48ZGl2PiZuYnNwOyBhIG1lY2hhbmlzbSB0byBz aG93IGFjdGl2ZWx5IHByb3Zpc2lvbmVkIEkyUlMgc3RhdGUgYW5kIG90aGVyIEkyUlM8L2Rpdj48 ZGl2PiZuYnNwOyBBZ2VudCBpbnRlcm5hbCBpbmZvcm1hdGlvbi4gJm5ic3A7Tm90ZSB0aGF0IHRo aXMgaW5mb3JtYXRpb24gbWF5IGNvbnRhaW48L2Rpdj48ZGl2PiZuYnNwOyBoaWdobHkgc2Vuc2l0 aXZlIG1hdGVyaWFsIHN1YmplY3QgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG9mPC9k aXY+PGRpdj4mbmJzcDsgYW55IGRhdGEgbW9kZWxzIGltcGxlbWVudGVkIGJ5IHRoYXQgQWdlbnQg YW5kIHRodXMgbXVzdCBiZSBwcm90ZWN0ZWQ8L2Rpdj48ZGl2PiZuYnNwOyBhY2NvcmRpbmcgdG8g dGhvc2UgY29uc2lkZXJhdGlvbnMuICZuYnNwO1ByZWZlcmFibHksIHRoaXMgbWVjaGFuaXNtPC9k aXY+PGRpdj4mbmJzcDsgc2hvdWxkIHVzZSBhIGRpZmZlcmVudCBwcml2aWxlZ2VkIG1lYW5zIG90 aGVyIHRoYW4gc2ltcGx5IGNvbm5lY3Rpbmc8L2Rpdj48ZGl2PiZuYnNwOyBhcyBhbiBJMlJTIGNs aWVudCB0byBsZWFybiB0aGUgZGF0YS4gJm5ic3A7VXNpbmcgYSBkaWZmZXJlbnQgbWVjaGFuaXNt PC9kaXY+PGRpdj4mbmJzcDsgc2hvdWxkIGltcHJvdmUgdHJhY2VhYmlsaXR5IGFuZCBmYWlsdXJl IG1hbmFnZW1lbnQuIjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RG9lcyB0aGF0IHdvcmsgZm9y IHlvdSBib3RoPzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzLDwvZGl2PjxkaXY+QWxp YTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUaHUsIEp1biAx MiwgMjAxNCBhdCA5OjI2IEFNLCBHZW9yZ2UsIFdlcyA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhy ZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Vz bGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iIj48YnI+DQpP biA2LzEwLzE0LCA0OjE0IFBNLCAiSmVmZnJleSBIYWFzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpo YWFzQHBmcmMub3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+DQomZ3Q7 VGhlIHRyYWNlYWJpbGl0eSBkcmFmdCBzaG91bGQgaG9wZWZ1bGx5IGdpdmUgeW91IHRoZSAid2hh dCB3YXMgcmVxdWVzdGVkIjxicj4NCiZndDtlbmQgb2YgdGhlIGF1ZGl0aW5nIHNwZWN0cnVtLiAm bmJzcDsoUGxlYXNlIGNvbW1lbnQgaW4gdGhhdCB0aHJlYWQsIGlmPGJyPg0KJmd0O290aGVyd2lz ZS4pPGJyPjxicj48L2Rpdj5JJiM4MjE3O2xsIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQsIGF0IHRo ZSBsYXRlc3Qgd2hlbiB0aGUgYWRvcHRpb24gY2FsbCBoaXRzLDxicj4NCmFuZCBtYWtlIGNvbW1l bnRzIHdpdGggdGhpcyBpbiBtaW5kLjxicj48ZGl2IGNsYXNzPSIiPjxicj4NCiZndDs8YnI+DQom Z3Q7V2hhdCBJIGJlbGlldmUgeW91J3JlIGFza2luZyBpcyByb3VnaGx5IHNvbWV0aGluZyBsaWtl IHRoZSBmb2xsb3dpbmcgdGV4dDxicj4NCiZndDtpbjxicj4NCiZndDt0aGUgYXJjaGl0ZWN0dXJl IGRyYWZ0Ojxicj4NCiZndDs8YnI+DQomZ3Q7WC4gT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnM8 YnI+DQomZ3Q7PGJyPg0KJmd0O0luIG9yZGVyIHRvIGZhY2lsaXRhdGUgdHJvdWJsZXNob290aW5n IG9mIHJvdXRpbmcgZWxlbWVudHMgaW1wbGVtZW50aW5nPGJyPg0KJmd0O0kyUlM8YnI+DQomZ3Q7 YWdlbnRzLCB0aG9zZSByb3V0aW5nIGVsZW1lbnRzIHNob3VsZCBwcm92aWRlIGZvciBhIG1lY2hh bmlzbSB0byBzaG93PGJyPg0KJmd0O2FjdGl2ZWx5IHByb3Zpc2lvbmVkIEkyUlMgc3RhdGUuICZu YnNwO05vdGUgdGhhdCB0aGlzIGluZm9ybWF0aW9uIG1heSBjb250YWluPGJyPg0KJmd0O2hpZ2hs eSBzZW5zaXRpdmUgbWF0ZXJpYWwgc3ViamVjdCB0byB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgb2YgYW55PGJyPg0KJmd0O2RhdGE8YnI+DQomZ3Q7bW9kZWxzIGltcGxlbWVudGVkIGJ5IHRo YXQgQWdlbnQgYW5kIHRodXMgbXVzdCBiZSBwcm90ZWN0ZWQgYWNjb3JkaW5nIHRvPGJyPg0KJmd0 O3Rob3NlIGNvbnNpZGVyYXRpb25zLjxicj48YnI+PC9kaXY+WWVzLCBJIHRoaW5rIHRoZSBvbmx5 IHRoaW5nIHRoYXQgbWlzc2VzIGlzIHRoZSBuZWVkIGZvciBpdCB0byBiZTxicj4NCmluZGVwZW5k ZW50IG9mIHRoZSBhZ2VudCBpdHNlbGYuPGJyPjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNv bG9yPSIjODg4ODg4Ij48YnI+DQpXZXM8YnI+PC9mb250Pjwvc3Bhbj48ZGl2IGNsYXNzPSJpbSBI T0VuWmIiPjxicj48YnI+DQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hp Y2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBi ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQg aXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo aXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0 aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBF LW1haWwgYW5kIGFueSBwcmludG91dC48YnI+PC9kaXY+PGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2 IGNsYXNzPSJoNSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQppMnJzIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9y ZyI+aTJyc0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+PGJyPjwvZGl2Pjwvc3Bhbj48L2JvZHk+PC9odG1sPg0K --_000_CFCEEB451FE7Bwesleygeorgetwcablecom_-- From nobody Tue Jun 24 06:42:26 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC381B2A09 for ; Tue, 24 Jun 2014 06:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27tWiWtOqHlA for ; Tue, 24 Jun 2014 06:42:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD6141B2935 for ; Tue, 24 Jun 2014 06:42:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 42128C22C; Tue, 24 Jun 2014 09:42:21 -0400 (EDT) Date: Tue, 24 Jun 2014 09:42:21 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140624134221.GA11842@pfrc> References: <20140605202938.GP13606@pfrc> <20140610172136.GF20397@pfrc> <20140610201427.GF32305@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/acgVFvb-dQ2nbZMLREfOfensVoY Cc: Jeffrey Haas , "i2rs@ietf.org" , "George, Wes" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:42:23 -0000 On Mon, Jun 23, 2014 at 06:53:46PM -0400, Alia Atlas wrote: > The problem with responding to email in order as I update the draft is > finding useful nuggets like this. > I've removed the previously suggested text from the "Interactions with > Local Config" section and updated > the "Manageability Considerations" section to be "Operational and > Manageability Considerations" and plunked > the following as the first paragraph. > > "In order to facilitate troubleshooting of routing elements > implementing I2RS agents, those routing elements should provide for > a mechanism to show actively provisioned I2RS state and other I2RS > Agent internal information. Note that this information may contain > highly sensitive material subject to the Security Considerations of > any data models implemented by that Agent and thus must be protected > according to those considerations. Preferably, this mechanism > should use a different privileged means other than simply connecting > as an I2RS client to learn the data. Using a different mechanism > should improve traceability and failure management." > > Does that work for you both? Works for me. -- Jeff From nobody Tue Jun 24 06:50:30 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F8E1B2945 for ; Tue, 24 Jun 2014 06:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k5LbTAPUrWl for ; Tue, 24 Jun 2014 06:50:25 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1421B29CF for ; Tue, 24 Jun 2014 06:50:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BA8C2C22C; Tue, 24 Jun 2014 09:50:24 -0400 (EDT) Date: Tue, 24 Jun 2014 09:50:24 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20140624135024.GC11842@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/foimJzUF3GIAaseLWqKJ-BLuUHo Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:50:27 -0000 I believe we had sufficient review during the last round of WGLC to advance these documents *if* the concerns previously raised have been sufficiently covered. The one significant detail where that work is unclear is whether the security considerations under current discussion in draft-hares-i2rs-security warrant specific additional detail in the architecture draft. If you've previously raised concerns on these drafts, please note to the list whether you believe they've been addressed. If you were paying specific attention to the security issues, please also review the security draft. The week is yet young. Hopefully the group can be convinced to complete this work by Friday. :-) -- Jeff On Mon, Jun 23, 2014 at 07:09:56PM -0400, Alia Atlas wrote: > Based upon the WGLC comments, I have updated these two drafts. Because I > believe that the changes are not particularly controversial (except for the > new reference to NETCONF and RESTCONF), I've published the updated versions > so that the WG can verify the changes at the same time as my co-authors. > > The differences for the architecture draft can be found at: > http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-architecture-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-architecture-04 > > and for the problem-statement at: > http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-03&difftype=--html&submit=Go%21&url2=draft-ietf-i2rs-problem-statement-04 > > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 24 06:56:02 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932D71B2A29 for ; Tue, 24 Jun 2014 06:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2nUdXR0j4zV for ; Tue, 24 Jun 2014 06:55:45 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D2F1B294B for ; Tue, 24 Jun 2014 06:55:44 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id v1so191252yhn.20 for ; Tue, 24 Jun 2014 06:55:43 -0700 (PDT) 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=KREz0cPkszNqjwrna1ceTMfSZ1ircfJPBmsTwSZCA9U=; b=ruyU1oBaA3s3f4J3w0tsUfSWYTuIy4LGVO4b3fYDTSPIEWCfca6MRzGJx1HgC2Jz45 F2p6wtoKixy4+CHU+b97hn0oZKWFGAhsIwaNWAJsAIHU0nhQjz1LoVN6itp3qAOohgna ULGSjHG62BqwWqsrUNK6u2cs8eIqOeCKw+cvT79hV6AI23KSxO32t/CpftGZ5upeko3U XFIVb7YW4bIsCY0eo2brLikTh8Sq1J1KrrEuV14fWQXbAvaW4KiTkVLfjzdQZM90Qe5S Jac+ojJO13bYBkZCoxFengmw8aOtpgN14mbryBVnlSGY2eOqa+BtGHHOwrKS6SQ0KMup 4lHw== MIME-Version: 1.0 X-Received: by 10.236.54.166 with SMTP id i26mr1481576yhc.109.1403618143749; Tue, 24 Jun 2014 06:55:43 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Tue, 24 Jun 2014 06:55:43 -0700 (PDT) In-Reply-To: References: <20140605202938.GP13606@pfrc> <004301cf849f$f2eb3100$4001a8c0@gateway.2wire.net> <20140610134133.GA18608@pfrc> <005101cf84c0$538ef9e0$4001a8c0@gateway.2wire.net> <20140610180747.GH20397@pfrc> <01a701cf858a$ebb93bc0$4001a8c0@gateway.2wire.net> Date: Tue, 24 Jun 2014 09:55:43 -0400 Message-ID: From: Alia Atlas To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec50b5112dbcd2004fc955035 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/20Zi2Zugmu7uNLAbTb8rhjypgrU Cc: Jeffrey Haas , "i2rs@ietf.org" , "t.petch" Subject: Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:55:56 -0000 --bcaec50b5112dbcd2004fc955035 Content-Type: text/plain; charset=UTF-8 Hi Lada, On Tue, Jun 24, 2014 at 5:53 AM, Ladislav Lhotka wrote: [removing fine conversation] > > [Alia] We described the arbitration rules in Section 6.3 of > > draft-ietf-i2rs-architecture-03. > > I guess we have to think about a proper representation of operational > state and ways for tagging its contents or otherwise signalling what caused > a particular change. > [Alia] I think that this is actually implementation-dependent and find the idea of trying to tag operational state to be excessively complex and downright scary. IMHO, the interaction needs to be between the config system and I2RS. > For instance, if a configured static route is not present in a RIB > (operational state), it may be because > > - the next hop wasn't reachable when the static route was configured, or > [Alia] I think this is a bad example. The route can still go in - it's just not active. Anyway, that's expected to happen in I2RS. > - the I2RS agent deleted it. > In that case, the I2RS agent should have notified the config, IMHO. The NETCONF server should be able to discriminate between these two cases > because its action (reinstall the route or not) may depend on it. > With a better example, yes. Alia > Lada > > > > > > >> > > >> > So one module, three trees, an additional YANG substatement for a leaf > >> > that is writable by I2RS. > >> > >> Rather than inventing new annotations, I'd rather like to see making > YANG > >> less NETCONF-specific so that it could directly define schema and > >> constraints for other datastores such as the one for I2RS. > >> > > > > [Alia] Please - I think there are different assumptions... > > > > Regards, > > Alia > > > > > >> > >> Lada > >> > >> > > >> > Tom Petch > >> > > >> > > >> >> > 6.4.2" o writing policy information such as interface attributes > >> > that > >> >> > are > >> >> > specific to the routing protocol or BGP policy that may > >> > indirectly > >> >> > manipulate attributes of routes carried in BGP. > >> >> > > >> >> > o writing routes or prefixes to be advertised via the protocol" > >> >> > I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB > but > >> > the > >> >> > I-D goes on to say > >> >> > " direct modification of the link-state database MUST NOT be > >> > allowed" > >> >> > (which I have seen on the list w.r.t. the BGP RIB). > >> >> > > >> >> > or > >> >> > > >> >> > 8" The interaction of state installed via the I2RS and via a > >> > router's > >> >> > configuration needs to be clearly defined." > >> >> > which again implies that I2RS and C/N/S are writing to the same > >> > data. > >> >> > >> >> *Maybe.* > >> >> > >> >> In some cases, the overlap with config state will be quite obvious > and > >> > your > >> >> observation will strongly hold. > >> >> > >> >> In other cases, I think a better perspective is that I2RS injected > >> > state is > >> >> effectively like that of another routing protocol. > >> >> > >> >> If you'd like to argue that BGP is effectively the same as C/N/S... > >> > well, if > >> >> we're talking Flowspec I might agree. :-) > >> >> > >> >> > The examples of data that can be changed are few, such as > >> >> > "For example, the interaction with OSPF might include modifying the > >> >> > local routing element's link metrics, announcing a > >> > locally-attached > >> >> > prefix, .." > >> >> > which leaves me wondering, do you expect an OSPF YANG model to be > >> > unable > >> >> > to change a link metric:-) > >> >> > >> >> Sure. In a highly dynamic fashion? With a fallback to a default > >> > config when > >> >> the application is done? > >> >> > >> >> By comparison to some vendor specific features, it's somewhat the > >> > difference > >> >> between a policy database (config) and the dynamic policy API that > >> > doesn't > >> >> require a system reconfiguration event. If you want to point out > that > >> > the > >> >> relationship is strong and that the defining differences are shallow > - > >> > you > >> >> could very well be right in those contexts. > >> >> > >> >> Again, we don't expect I2RS work to supplant netconf/yang. We expect > >> > to > >> >> leverage the work. > >> >> > >> >> > If I2RS were aiming at a higher level, say specifying policy and > >> > have > >> >> > the system translate that into actual config changes I would > >> > understand > >> >> > that, but I do not see I2RS going that far, rather when I2RS says > >> >> > policy, I think it means changing a community (config again) or > some > >> >> > such ie more of an implementation detail than a high level > strategy. > >> >> > >> >> I hesitate to frame it this way, but one example application is a > form > >> > of > >> >> SDN. The front end says "provision this VPN" to a data model for > that > >> >> purpose. The fact that it may go behind the covers via client->agent > >> > and > >> >> eventually install ephemeral netconf state is an implementation > >> > detail. > >> >> > >> >> If you want to argue that such a higher level model is simply > netconf, > >> > then > >> >> perhaps we should de-charter and do all of the work in that group. I > >> > was, > >> >> however, under the impression that work for various models was being > >> > pushed > >> >> to be done in appropriate working groups. :-) > >> >> > >> >> -- Jeff > >> > > >> > _______________________________________________ > >> > i2rs mailing list > >> > i2rs@ietf.org > >> > https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --bcaec50b5112dbcd2004fc955035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lada,


On Tue, Jun 24, 2014 at 5:53 AM, Ladislav Lhotka <lhotka@nic.= cz> wrote:

[removing f= ine conversation]
=C2=A0
> [Alia] We described the arbitration rules in Section 6.3 of
> draft-ietf-i2rs-architecture-03.

I guess we have to think about a proper representation of opera= tional state and ways for tagging its contents or otherwise signalling what= caused a particular change.

[Alia] I t= hink that this is actually implementation-dependent and find the idea of tr= ying to tag operational state to be excessively complex and downright scary= . =C2=A0IMHO, the interaction needs to be between the config system and I2R= S.=C2=A0

=C2=A0
For instance, if a configured static route is not present in a RIB (operati= onal state), it may be because

- the next hop wasn't reachable when the static route was configured, o= r
[Alia] I think this is a bad example. =C2=A0The rout= e can still go in - it's just not active. =C2=A0Anyway, that's expe= cted to happen in I2RS.=C2=A0
=C2=A0
- the I2RS agent deleted it.

In that ca= se, the I2RS agent should have notified the config, IMHO.=C2=A0
<= br>
The NETCONF server should be able to discriminate between these two cases b= ecause its action (reinstall the route or not) =C2=A0may depend on it.
<= /blockquote>

With a better example, yes.

<= /div>
Alia=C2=A0
=C2=A0
Lada

>
>
>> >
>> > So one module, three trees, an additional YANG substatement f= or a leaf
>> > that is writable by I2RS.
>>
>> Rather than inventing new annotations, I'd rather like to see = making YANG
>> less NETCONF-specific so that it could directly define schema and<= br> >> constraints for other datastores such as the one for I2RS.
>>
>
> [Alia] Please - I think there are different assumptions...
>
> Regards,
> Alia
>
>
>>
>> Lada
>>
>> >
>> > Tom Petch
>> >
>> >
>> >> > 6.4.2" =C2=A0o =C2=A0writing policy information= such as interface attributes
>> > that
>> >> > are
>> >> > =C2=A0 =C2=A0 =C2=A0 specific to the routing protoco= l or BGP policy that may
>> > indirectly
>> >> > =C2=A0 =C2=A0 =C2=A0 manipulate attributes of routes= carried in BGP.
>> >> >
>> >> > =C2=A0 =C2=A0o =C2=A0writing routes or prefixes to b= e advertised via the protocol"
>> >> > I had assume that I2RS might write to an IGP LSDB or= BGP Adj-RIB but
>> > the
>> >> > I-D goes on to say
>> >> > " direct modification of the link-state databas= e MUST NOT be
>> > allowed"
>> >> > (which I have seen on the list w.r.t. the BGP RIB).<= br> >> >> >
>> >> > or
>> >> >
>> >> > 8" The interaction of state installed via the I= 2RS and via a
>> > router's
>> >> > configuration needs to be clearly defined."
>> >> > which again implies that I2RS and C/N/S are writing = to the same
>> > data.
>> >>
>> >> *Maybe.*
>> >>
>> >> In some cases, the overlap with config state will be quit= e obvious and
>> > your
>> >> observation will strongly hold.
>> >>
>> >> In other cases, I think a better perspective is that I2RS= injected
>> > state is
>> >> effectively like that of another routing protocol.
>> >>
>> >> If you'd like to argue that BGP is effectively the sa= me as C/N/S...
>> > well, if
>> >> we're talking Flowspec I might agree. :-)
>> >>
>> >> > The examples of data that can be changed are few, su= ch as
>> >> > "For example, the interaction with OSPF might i= nclude modifying the
>> >> > =C2=A0 =C2=A0local routing element's link metric= s, announcing a
>> > locally-attached
>> >> > =C2=A0 =C2=A0prefix, .."
>> >> > which leaves me wondering, do you expect an OSPF YAN= G model to be
>> > unable
>> >> > to change a link metric:-)
>> >>
>> >> Sure. =C2=A0In a highly dynamic fashion? With a fallback = to a default
>> > config when
>> >> the application is done?
>> >>
>> >> By comparison to some vendor specific features, it's = somewhat the
>> > difference
>> >> between a policy database (config) and the dynamic policy= API that
>> > doesn't
>> >> require a system reconfiguration event. =C2=A0If you want= to point out that
>> > the
>> >> relationship is strong and that the defining differences = are shallow -
>> > you
>> >> could very well be right in those contexts.
>> >>
>> >> Again, we don't expect I2RS work to supplant netconf/= yang. =C2=A0We expect
>> > to
>> >> leverage the work.
>> >>
>> >> > If I2RS were aiming at a higher level, say specifyin= g policy and
>> > have
>> >> > the system translate that into actual config changes= I would
>> > understand
>> >> > that, but I do not see I2RS going that far, rather w= hen I2RS says
>> >> > policy, I think it means changing a community (confi= g again) or some
>> >> > such ie more of an implementation detail than a high= level strategy.
>> >>
>> >> I hesitate to frame it this way, but one example applicat= ion is a form
>> > of
>> >> SDN. =C2=A0The front end says "provision this VPN&qu= ot; to a data model for that
>> >> purpose. =C2=A0The fact that it may go behind the covers = via client->agent
>> > and
>> >> eventually install ephemeral netconf state is an implemen= tation
>> > detail.
>> >>
>> >> If you want to argue that such a higher level model is si= mply netconf,
>> > then
>> >> perhaps we should de-charter and do all of the work in th= at group. I
>> > was,
>> >> however, under the impression that work for various model= s was being
>> > pushed
>> >> to be done in appropriate working groups. :-)
>> >>
>> >> -- Jeff
>> >
>> > _______________________________________________
>> > i2rs mailing list
>> > i2rs@ietf.org
>> > https://www.ietf.org/mailman/listinfo/i2rs
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--bcaec50b5112dbcd2004fc955035-- From nobody Wed Jun 25 06:51:35 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59FC1B2C9A for ; Wed, 25 Jun 2014 06:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25lRuSrcz1y1 for ; Wed, 25 Jun 2014 06:51:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C941B2CB2 for ; Wed, 25 Jun 2014 06:51:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A0800125A; Wed, 25 Jun 2014 15:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p6G6Vo7uG-Fa; Wed, 25 Jun 2014 15:51:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jun 2014 15:51:27 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A56A2003C; Wed, 25 Jun 2014 15:51:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sFLHx8KElex6; Wed, 25 Jun 2014 15:51:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF9DA2003A; Wed, 25 Jun 2014 15:51:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7912F2D98ECE; Wed, 25 Jun 2014 15:51:23 +0200 (CEST) Date: Wed, 25 Jun 2014 15:51:22 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140625135122.GA21995@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org References: <20140624135024.GC11842@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140624135024.GC11842@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/g_gDpjsYXEjvPWMcIvM4h2jo9TM Cc: i2rs@ietf.org Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Jun 2014 13:51:33 -0000 On Tue, Jun 24, 2014 at 09:50:24AM -0400, Jeffrey Haas wrote: > > If you were paying specific attention to the security issues, please also > review the security draft. > I have been trying to read draft-hares-i2rs-security-01.txt and to match it against draft-ietf-i2rs-architecture-04.txt and I have come to the solution that we should - stop work draft-hares-i2rs-security-01.txt and - merge all statements from this I-D that are worth keeping and that are not yet part of draft-ietf-i2rs-architecture-04.txt into draft-ietf-i2rs-architecture-04.txt. There are numerous places where I the documents are inconsistent and this should be avoided if all possible and one way of doing this is make sure there is only one document talking about I2RS security 'architecture'. And I do not see a convincing point why the I2RS security 'architecture' should not be sufficiently defined in the I2RS architecture - in fact I see many good reasons why the whole I2RS architecture should be in one document. To substantiate my position, I will list several examples that make me concerned. But note that this list is not complete. * I am concerned about MUST statements in the security document that I do not find in the architecture document. Or, if these MUST statements are already in the architecture document, then there is no point in repeating them in the security document. * I am concerned about definitions such as Role in the security document that I do not find in the same meaning in the architecture document. Furthermore, I am worried about terms like 'routing tree' that are not well defined in the security document and do not exist in the architecture document. I note that the definition of Role is actually inconsistent even within the security document (e.g., 3.3. and 3.1). * There are concepts in the security document like I2RS identity repositories that I do not find in the I2RS architecture. * The section 3.2 of the security document gives guidelines that on things like that with symmetric keys, "sequence numbers which increase monotonically could be useful to help distinguishing replayed messages". I believe this goes way beyond _architectural_ concerns and worse it kind of implies that I2RS may invent their security protocol instead of using one of the already available and well understood security protocols we have. * Section 3.3. is messing up the separation of communication security and access control. Furthermore, the advice given that data model writers should consider whether a client / agent is valid is IMHO wrong. It is wrong to encode authorization policies into data models. The security policy must be configurable at runtime by a security administrator. There needs to be a separation of policy from mechanism. * Similar as above, the advice in section 3.4. that IM/DM writers "must discuss determine" whether encryption is a recommendation or requirement is wrong. It is the job of the security administrator deploying I2RS to answer those questions. All the IM/DM writer can reasonably do is to provide guidelines what in particular may need protection (this is what we are doing for ~20 years for MIB modules). * My understanding is that so called "stacked I2RS agent-clients in broker topologies" are left out of scope in the architecture. Why do such things pop up in the security architecture? What is the point of having an I2RS architecture with a certain scope and then an I2RS security architecture with a bigger scope? Bottom line is that I strongly prefer if all the security aspects of the I2RS architecture are covered in the document that defines the I2RS architecture. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jun 25 06:57:21 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6AD1B2CA6 for ; Wed, 25 Jun 2014 06:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWVjKjlMy4wA for ; Wed, 25 Jun 2014 06:57:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BC21B2CA0 for ; Wed, 25 Jun 2014 06:57:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8256B125D; Wed, 25 Jun 2014 15:57:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FJJ1a87MX-8h; Wed, 25 Jun 2014 15:57:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Jun 2014 15:57:16 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D92B2003D; Wed, 25 Jun 2014 15:57:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gdS8qM-79ZiW; Wed, 25 Jun 2014 15:57:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36E1A2003C; Wed, 25 Jun 2014 15:57:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2641D2D98F2F; Wed, 25 Jun 2014 15:57:14 +0200 (CEST) Date: Wed, 25 Jun 2014 15:57:13 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20140625135713.GA22139@elstar.local> Mail-Followup-To: Alia Atlas , "i2rs@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/I4DCmSU9xqnvBhSz-7oLDKHP68Y Cc: "i2rs@ietf.org" Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Jun 2014 13:57:21 -0000 On Mon, Jun 23, 2014 at 07:09:56PM -0400, Alia Atlas wrote: > Based upon the WGLC comments, I have updated these two drafts. Because I > believe that the changes are not particularly controversial (except for the > new reference to NETCONF and RESTCONF), I've published the updated versions > so that the WG can verify the changes at the same time as my co-authors. I suggest to take this out again: Additionally, on March 2, 2014, the IESG issued a statement about Writeable MIB Modules which is expected to limit creation of future writeable MIB modules. This is what the statement really says (despite its unfortunate title, http://www.ietf.org/iesg/statement/writable-mib-module.html): SNMP MIB modules creating and modifying configuration state should only be produced by working groups in cases of clear utility and consensus to use SNMP write operations for configuration, and in consultation with the OPS ADs/MIB doctors. My understanding is that configuration here is meant in the OPS sense and my understanding is that I2RS is about changing operations state as understood in the OPS community. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jun 26 14:11:53 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C251E1B2F06 for ; Thu, 26 Jun 2014 14:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_W1LM3r5zHa for ; Thu, 26 Jun 2014 14:11:42 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEA91A028F for ; Thu, 26 Jun 2014 14:11:42 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so2503588yha.3 for ; Thu, 26 Jun 2014 14:11:41 -0700 (PDT) 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=/PzxZ18+EhVgxTnCOyg88oBPwLwABbnG0rUwt5VPT6I=; b=GCbNEc3+tocxxkKc737WK3+FV/kK8iEDK/2BJ6tEZPz31NGtYBZUD8DAPh/urqkckP 4IgRcCwsgmlv6qDeF/jM7abeOjxngVIMo7t9JbS1usEj8OZPff6tprqi62IIW0o23tt6 Snm6+BTUuriv4CH5Zn+0VEeRSHjNcCHutpG6AJD9RQ45dOJZ/S7nmGud/PfkbeKhdey/ SORZeEM9ZLrOV+6SKEbJFhAcF6qT8H4dfwcVqB9o3U9ju8bmJwmOPolNSTBU3Rx0K24v EVKPyAe46g+WHs2hIDKVaPMoJ46DXDC6pC3RkJFEbjb81Wy7vCrDW2drOPhLZTFWXBOT /61w== MIME-Version: 1.0 X-Received: by 10.236.130.77 with SMTP id j53mr16002802yhi.139.1403817101591; Thu, 26 Jun 2014 14:11:41 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Thu, 26 Jun 2014 14:11:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Jun 2014 17:11:41 -0400 Message-ID: From: Alia Atlas To: Robert Raszuk Content-Type: multipart/alternative; boundary=20cf3010edb7ab8c0e04fcc3a38e Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/YnBNjw1QDOvEmzE4w8_oCMQhp8w Cc: "i2rs@ietf.org" , Edward Crabbe Subject: Re: [i2rs] working group last call: draft-atlas-i2rs-problem-statement X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:11:50 -0000 --20cf3010edb7ab8c0e04fcc3a38e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robert, Sorry for the delay and missing these on the first pass! I really appreciate that you took the time to do a careful and thoughtful review. On Mon, Jun 9, 2014 at 10:42 AM, Robert Raszuk wrote: > Regarding draft-ietf-i2rs-problem-statement-01 > > I have few minor comments: > > 1. > Figure 1 sort of implies that I2RS client to I2RS Agent is always a > point to point session. Is this intentional or accidental ? I can > imagine bunch of I2RS clients feeding agends with pieces of required > information which only putted together makes sense - is this out of > scope as too complex ? Or is this what is called multi-headed control > ? > [Alia] I've certainly only pictured a point-to-point session. I don't expect that the I2RS agent would "put together pieces" but rather that the I2RS Clients can send atomic operations. Together that set might happen to make up a service, but that wouldn't be realized or dealt with by the I2RS agent. > If so It's definition is not that clear. Does "multi-headed" just > means number of independent clients feeding in async mode complete > information chunks or is that I2RS agent can collect pieces of info > for a given information and compiles the product itself. My question > is for the latter mode. > [Alia] I think it is the former > 2. > > In addition to interfaces to the RIB layer, > > Are we always talking about global RIB or also RIB on line cards on > distributed systems. While former is much easier the latter may help > with scalability issues. > [Alia] Hmm, in the problem-statement, I think it can be unspecified. In general, I think about the global RIB - but we do have in the RIB model the idea of different routing-instances which apply to only particular interfaces. So - depending upon a particular implementation - feeding routes into a routing-instance with interfaces on only a single card might help; I think that's going to be implementation specific, but the RIB model should be general enough. > 3. > Pls change [I-D.gredler-idr-ls-distribution]) to > draft-ietf-idr-ls-distribution > [Alia] Absolutely - thanks for the catch! > 4. > > For applications to have a feedback loop that includes awareness of > > the relevant traffic, an application must be able to request the > > measurement and timely, scalable reporting of data." > > Frankly I am not sure if I like and support the idea of mixing control > plane and data plane reporting netflow like data on the same I2RS > channel/session. > > Not questioning the need .. just questioning the approach :) > [Alia] Ah - this is why I keep talking and writing about multiple transport channels. So - the control can be on one channel and the data-plane reporting can be on another agreed upon channel. IMHO, I want a way to ship data off the linecards without it having to travel up to a central point. > 5. > > While a few of these (e.g. link up/down) may be available via > > MIB Notifications today, the full range is not - nor is there the > > standardized ability to set up the router to trigger different > > actions upon an event=E2=80=99s occurrence so that a rapid reaction can= be > > accomplished. > > So I2RS will also define a router's policy language which will allow > for setting via I2RS protocol conditional behavior upon specific > network events ? Will it ever ship complete ? Will it require RIB > redesign by some vendors which today may not have all opaque info > there ? > [Alia] Well, we may have to have a simple version first - but when there is a response that wants to happen in a quick fashion, I think that'd help. I haven't seen a lot of work on this idea - but I'm happier to have it in the problem-statement and then we can see. It's awsome goal and very attractive, but to me it means that this one > is a bit separate effort which make take much much longer to agreed in > IETF on then plain I2RS remote control idea. > [Alia] Yes. The idea was more connected when we had time-based operations. I do think that thinking about the simplest requirements and use-cases here would help. The problem-statement might be a bit aspirational for now... Thanks again, Alia > > Thx, > R. > > On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe wrote: > > Hello all; > > > > Jeff and I would like to start the two week working group last call for > > draft-atlas-i2rs-problem-statement. The document may be found here: > > > > http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02 > > > > The editors and authors are advised to try to resolve as many of the > > comments as possible (on the mailing list) as they come in, but not to > > post the new version of the draft until the wglc is closed and the > > comments are resolved. > > > > This working group last call will end on Friday, 5/30/14 > > > > best, > > -ed > > > > _______________________________________________ > > 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 > --20cf3010edb7ab8c0e04fcc3a38e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robert,

Sorry for the delay and miss= ing these on the first pass! =C2=A0I really appreciate that you
t= ook the time to do a careful and thoughtful review.


On Mon, Jun 9, 2014 at 10:42 AM, Robert = Raszuk <robert@raszuk.net> wrote:
Regarding draft-ietf-i2rs-problem-statement-01

I have few minor comments:

1.
Figure 1 sort of implies that I2RS client to I2RS Agent is always a
point to point session. Is this intentional or accidental ? I can
imagine bunch of I2RS clients feeding agends with pieces of required
information which only putted together makes sense - is this out of
scope as too complex ? Or is this what is called multi-headed control
?

[Alia] I've certainly only pictur= ed a point-to-point session. =C2=A0I don't expect
that the I2= RS agent would "put together pieces" but rather that the I2RS
Clients can send atomic operations. =C2=A0Together that set might happ= en to make
up a service, but that wouldn't be realized or dea= lt with by the I2RS agent.=C2=A0

=C2=A0
If so It's definition is not that clear. Does "multi-headed" = =C2=A0just
means number of independent clients feeding in async mode complete
information chunks or is that I2RS agent can collect pieces of info
for a given information and compiles the product itself. My question
is for the latter mode.

[Alia] I think = it is the former=C2=A0
=C2=A0
2.
> In addition to interfaces to the RIB layer,

Are we always talking about global RIB or also RIB on line cards on
distributed systems. While former is much easier the latter may help
with scalability issues.

[Alia] Hmm, in= the problem-statement, I think it can be unspecified. =C2=A0In general,
I think about the global RIB - but we do have in the RIB model the = idea of different
routing-instances which apply to only particular interfaces. =C2=A0So = - depending upon
a particular implementation - feeding routes int= o a routing-instance with interfaces
on only a single card might = help; I think that's going to be implementation specific,
but the RIB model should be general enough.

= =C2=A0
3.
Pls change [I-D.gredler-idr-ls-distribution]) to draft-ietf-idr-ls-distribu= tion

[Alia] Absolutely - thanks for the= catch!
=C2=A0
4.
> For applications to have a feedback loop that includes awareness of > the relevant traffic, an application must be able to request the
> measurement and timely, scalable reporting of data."

Frankly I am not sure if I like and support the idea of mixing control
plane and data plane reporting netflow like data on the same I2RS
channel/session.

Not questioning the need .. just questioning the approach :)

[Alia] Ah - this is why I keep talking and writing ab= out multiple transport channels.
So - the control can be on one c= hannel and the data-plane reporting can be on
another agreed upon channel. =C2=A0IMHO, I want a way to ship data off= the linecards
without it having to travel up to a central point.=
=C2=A0
5.
> While a few of these (e.g. link up/down) may be available via
> MIB Notifications today, the full range is not - nor is there the
> standardized ability to set up the router to trigger different
> actions upon an event=E2=80=99s occurrence so that a rapid reaction ca= n be
> accomplished.

So I2RS will also define a router's policy language which will allow for setting via I2RS protocol conditional behavior upon specific
network events ? Will it ever ship complete ? Will it require RIB
redesign by some vendors which today may not have all opaque info
there ?

[Alia] Well, we may have to hav= e a simple version first - but when there is
a response that want= s to happen in a quick fashion, I think that'd help. =C2=A0I
haven't seen a lot of work on this idea - but I'm happier to have i= t in the
problem-statement and then we can see.

It's awsome goal and very attractive, but to me it means that this one<= br> is a bit separate effort which make take much much longer to agreed in
IETF on then plain I2RS remote control idea.

[Alia] Yes. =C2=A0The idea was more connected when we had time-based = operations.
I do think that thinking about the simplest requireme= nts and use-cases here
would help. =C2=A0The problem-statement might be a bit aspirational fo= r now...

Thanks again,
Alia
= =C2=A0

Thx,
R.

On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe <edc@google.com> wrote:
> Hello all;
>
> Jeff and I would like to start the two week working group last call fo= r
> draft-atlas-i2rs-problem-statement. =C2=A0The document may be found he= re:
>
> http://tools.ietf.org/html/draft-atlas-i2rs-proble= m-statement-02
>
> The editors and authors are advised to try to resolve as many of the > comments as possible (on the mailing list) as they come in, but not to=
> post the new version of the draft until the wglc is closed and the
> comments are resolved.
>
> This working group last call will end on Friday, 5/30/14
>
> best,
> =C2=A0 =C2=A0-ed
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>

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

--20cf3010edb7ab8c0e04fcc3a38e-- From nobody Thu Jun 26 14:13:51 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571411B2F2C for ; Thu, 26 Jun 2014 14:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCWeMFyMuHtx for ; Thu, 26 Jun 2014 14:13:47 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112751A028F for ; Thu, 26 Jun 2014 14:13:47 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so2502792yha.24 for ; Thu, 26 Jun 2014 14:13:46 -0700 (PDT) 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 :content-type; bh=oIHyWaF5u8S1Zu+3HXQIG3SwYQ4/aB8TZIMGiJShzkM=; b=t6/p0Cg1C9WymQ+5AktBDBKDSqi3XZrCiF5VN7Ad85YLpPS9di2IJH6axV7WDoqtl/ DZ2/luGmbl0fYIoZS/S4XUVC1C3wChhZ51y4VBX1EWFtiTdzEVqQLMEuJrH/qoT32/7O W4GpmXHTnrjk5Eqe0DB2CEdscH7PAPlQowBvloP10tI6WKQFrO3o1zP391/+2Jl7rrRY VNzM7RwiK+HGoq6eR0AW0bMgSADV8KiJ2SMZz++JAZN4cLdDIdsO3wLtgZysV4W8eE0/ l7e7FCLpbPAUIirV2EEujnt6XErsrd5LpH5fhnPtqeRS7njfUtdE2yrSin7xgrqbmoY1 Wjyw== MIME-Version: 1.0 X-Received: by 10.236.137.242 with SMTP id y78mr7896373yhi.152.1403817226454; Thu, 26 Jun 2014 14:13:46 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Thu, 26 Jun 2014 14:13:46 -0700 (PDT) In-Reply-To: <20140625135713.GA22139@elstar.local> References: <20140625135713.GA22139@elstar.local> Date: Thu, 26 Jun 2014 17:13:46 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Alia Atlas , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf303a2f8d1ccbda04fcc3ab11 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/Ch44Hn6W_9K_0fcn851X-FOdLUU Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:13:49 -0000 --20cf303a2f8d1ccbda04fcc3ab11 Content-Type: text/plain; charset=UTF-8 Hi Juergen, On Wed, Jun 25, 2014 at 9:57 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jun 23, 2014 at 07:09:56PM -0400, Alia Atlas wrote: > > Based upon the WGLC comments, I have updated these two drafts. Because I > > believe that the changes are not particularly controversial (except for > the > > new reference to NETCONF and RESTCONF), I've published the updated > versions > > so that the WG can verify the changes at the same time as my co-authors. > > I suggest to take this out again: > > Additionally, on March 2, 2014, the IESG issued a statement about > Writeable MIB Modules which is expected to limit creation of future > writeable MIB modules. > > This is what the statement really says (despite its unfortunate > title, http://www.ietf.org/iesg/statement/writable-mib-module.html): > > SNMP MIB modules creating and modifying configuration state should > only be produced by working groups in cases of clear utility and > consensus to use SNMP write operations for configuration, and in > consultation with the OPS ADs/MIB doctors. > > My understanding is that configuration here is meant in the OPS sense > and my understanding is that I2RS is about changing operations state > as understood in the OPS community. > I've also heard support for having it in. I think that what it says is accurate - that WGs will be asked to think about whether write operations are needed in MIBs going forward. Can you suggest a rewording that you'd be comfortable with? Alia > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --20cf303a2f8d1ccbda04fcc3ab11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

On Wed, Jun 25, 2014 at 9:5= 7 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> wrote:
On Mon, Jun 23, 2014 at 07:09:56PM -0400, Alia Atlas wrote:
> Based upon the WGLC comments, I have updated the= se two drafts. =C2=A0Because I
> believe that the changes are not particularly controversial (except fo= r the
> new reference to NETCONF and RESTCONF), I've published the updated= versions
> so that the WG can verify the changes at the same time as my co-author= s.

I suggest to take this out again:

=C2=A0 Additionally, on March 2, 2014, the IESG issued a statement about =C2=A0 Writeable MIB Modules which is expected to limit creation of future<= br> =C2=A0 writeable MIB modules.

This is what the statement really says (despite its unfortunate
title, http://www.ietf.org/iesg/statement/writable-mib-modul= e.html):

=C2=A0 SNMP MIB modules creating and modifying configuration state should =C2=A0 only be produced by working groups in cases of clear utility and
=C2=A0 consensus to use SNMP write operations for configuration, and in
=C2=A0 consultation with the OPS ADs/MIB doctors.

My understanding is that configuration here is meant in the OPS sense
and my understanding is that I2RS is about changing operations state
as understood in the OPS community.

I&#= 39;ve also heard support for having it in. =C2=A0I think that what it says = is accurate -
that WGs will be asked to think about whether w= rite operations are needed
in MIBs going forward.

Can you suggest a rewo= rding that you'd be comfortable with?

Alia
=C2=A0

/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >

--20cf303a2f8d1ccbda04fcc3ab11-- From nobody Thu Jun 26 14:17:00 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13A1B2F2C for ; Thu, 26 Jun 2014 14:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPjq4q66yGGS for ; Thu, 26 Jun 2014 14:16:54 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B221B2F14 for ; Thu, 26 Jun 2014 14:16:54 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id z6so2515965yhz.0 for ; Thu, 26 Jun 2014 14:16:53 -0700 (PDT) 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 :content-type; bh=JugwzdTNZ875oeJzapS9zBXgy2dIB54Eq31C5iScvcc=; b=RduCDGZ8HI0qrdJCEXxsRor8bQB92mpoB3ROywPqZdUweeZZc2PJgkTdf6AxDUNhdk coe3Oc8tTq58SjyHK3q26f2CotNH1Qnue0Q6b2JQqHBJA+6GoVjhkWjkvSyGFZV3+h7v kQ7/XMTO40H5pq1fbR7ayNnj+SJNn67CePduoAX20/1Wbe7PL/ejy4Z48/vmv+HExiuX SyDLyfm0DQmErWr20HdFcm03M+8YvtIDbnOlgPmeTwJS6uLV7okVX1TKeVDFCg6N69cb A5R9NYo0Xy0kbdL4q5BetoymHU3joS/fsRPaaMbku27alYviGT/wEoBnlJn04R6dqzhS q2lQ== MIME-Version: 1.0 X-Received: by 10.236.149.72 with SMTP id w48mr9254795yhj.101.1403817413736; Thu, 26 Jun 2014 14:16:53 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Thu, 26 Jun 2014 14:16:53 -0700 (PDT) In-Reply-To: <20140625135122.GA21995@elstar.local> References: <20140624135024.GC11842@pfrc> <20140625135122.GA21995@elstar.local> Date: Thu, 26 Jun 2014 17:16:53 -0400 Message-ID: From: Alia Atlas To: Juergen Schoenwaelder , Jeffrey Haas , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf303a30ed467efe04fcc3b6fd Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/19bqASOUlu_l0NKW4DVO09NcTzk Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 21:16:57 -0000 --20cf303a30ed467efe04fcc3b6fd Content-Type: text/plain; charset=UTF-8 Given the level of maturity of the security draft, that we put into the architecture draft what we think is good guidance without selecting existing mechanisms, and that we are trying to finish the architecture draft, do you really see aspects missing and if so, precisely what, around the security section? I don't want to confuse cherry-picking the parts that are needed from an immature draft with information that is missing from the architecture. IMHO, we will need a draft that talks about what protocols can meet the requirements, whether there is a mandatory-to-implement, and so on. That draft may or may not be what the efforts at the security draft matures into. Regards, Alia On Wed, Jun 25, 2014 at 9:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jun 24, 2014 at 09:50:24AM -0400, Jeffrey Haas wrote: > > > > If you were paying specific attention to the security issues, please also > > review the security draft. > > > > I have been trying to read draft-hares-i2rs-security-01.txt and to > match it against draft-ietf-i2rs-architecture-04.txt and I have come > to the solution that we should > > - stop work draft-hares-i2rs-security-01.txt and > > - merge all statements from this I-D that are worth keeping and that > are not yet part of draft-ietf-i2rs-architecture-04.txt into > draft-ietf-i2rs-architecture-04.txt. > > There are numerous places where I the documents are inconsistent and > this should be avoided if all possible and one way of doing this is > make sure there is only one document talking about I2RS security > 'architecture'. And I do not see a convincing point why the I2RS > security 'architecture' should not be sufficiently defined in the I2RS > architecture - in fact I see many good reasons why the whole I2RS > architecture should be in one document. > > To substantiate my position, I will list several examples that make > me concerned. But note that this list is not complete. > > * I am concerned about MUST statements in the security document that I > do not find in the architecture document. Or, if these MUST > statements are already in the architecture document, then there is > no point in repeating them in the security document. > > * I am concerned about definitions such as Role in the security > document that I do not find in the same meaning in the architecture > document. Furthermore, I am worried about terms like 'routing tree' > that are not well defined in the security document and do not exist > in the architecture document. I note that the definition of Role is > actually inconsistent even within the security document (e.g., > 3.3. and 3.1). > > * There are concepts in the security document like I2RS identity > repositories that I do not find in the I2RS architecture. > > * The section 3.2 of the security document gives guidelines that on > things like that with symmetric keys, "sequence numbers which > increase monotonically could be useful to help distinguishing > replayed messages". I believe this goes way beyond _architectural_ > concerns and worse it kind of implies that I2RS may invent their > security protocol instead of using one of the already available and > well understood security protocols we have. > > * Section 3.3. is messing up the separation of communication security > and access control. Furthermore, the advice given that data model > writers should consider whether a client / agent is valid is IMHO > wrong. It is wrong to encode authorization policies into data > models. The security policy must be configurable at runtime by a > security administrator. There needs to be a separation of policy > from mechanism. > > * Similar as above, the advice in section 3.4. that IM/DM writers > "must discuss determine" whether encryption is a recommendation or > requirement is wrong. It is the job of the security administrator > deploying I2RS to answer those questions. All the IM/DM writer can > reasonably do is to provide guidelines what in particular may need > protection (this is what we are doing for ~20 years for MIB > modules). > > * My understanding is that so called "stacked I2RS agent-clients in > broker topologies" are left out of scope in the architecture. Why do > such things pop up in the security architecture? What is the point > of having an I2RS architecture with a certain scope and then an I2RS > security architecture with a bigger scope? > > Bottom line is that I strongly prefer if all the security aspects of > the I2RS architecture are covered in the document that defines the > I2RS architecture. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --20cf303a30ed467efe04fcc3b6fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Given the level of maturity of the security draft, that we= put into the architecture draft
what we think is good guidance without= selecting existing mechanisms, and that we
are trying to finish = the architecture draft, do you really see aspects missing and if so,
precisely what, around the security section?

= I don't want to confuse cherry-picking the parts that are needed from a= n immature draft
with information that is missing from the archit= ecture.

IMHO, we will need a draft that talks about what protoc= ols can meet the requirements,
whether there is a mandatory-to-im= plement, and so on. =C2=A0That draft may or may not be
what the e= fforts at the security draft matures into.

Regards,
Alia


On Wed, Jun 25, 2014 at 9:51 AM, = Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit= y.de> wrote:
On Tue, Jun 24, 2014 at 09:5= 0:24AM -0400, Jeffrey Haas wrote:
>
> If you were paying specific attention to the security issues, please a= lso
> review the security draft.
>

I have been trying to read draft-hares-i2rs-security-01.txt and to match it against draft-ietf-i2rs-architecture-04.txt and I have come
to the solution that we should

- stop work draft-hares-i2rs-security-01.txt and

- merge all statements from this I-D that are worth keeping and that
=C2=A0 are not yet part of draft-ietf-i2rs-architecture-04.txt into
=C2=A0 draft-ietf-i2rs-architecture-04.txt.

There are numerous places where I the documents are inconsistent and
this should be avoided if all possible and one way of doing this is
make sure there is only one document talking about I2RS security
'architecture'. And I do not see a convincing point why the I2RS security 'architecture' should not be sufficiently defined in the I= 2RS
architecture - in fact I see many good reasons why the whole I2RS
architecture should be in one document.

To substantiate my position, I will list several examples that make
me concerned. But note that this list is not complete.

* I am concerned about MUST statements in the security document that I
=C2=A0 do not find in the architecture document. Or, if these MUST
=C2=A0 statements are already in the architecture document, then there is =C2=A0 no point in repeating them in the security document.

* I am concerned about definitions such as Role in the security
=C2=A0 document that I do not find in the same meaning in the architecture<= br> =C2=A0 document. Furthermore, I am worried about terms like 'routing tr= ee'
=C2=A0 that are not well defined in the security document and do not exist<= br> =C2=A0 in the architecture document. I note that the definition of Role is<= br> =C2=A0 actually inconsistent even within the security document (e.g.,
=C2=A0 3.3. and 3.1).

* There are concepts in the security document like I2RS identity
=C2=A0 repositories that I do not find in the I2RS architecture.

* The section 3.2 of the security document gives guidelines that on
=C2=A0 things like that with symmetric keys, "sequence numbers which =C2=A0 increase monotonically could be useful to help distinguishing
=C2=A0 replayed messages". I believe this goes way beyond _architectur= al_
=C2=A0 concerns and worse it kind of implies that I2RS may invent their
=C2=A0 security protocol instead of using one of the already available and<= br> =C2=A0 well understood security protocols we have.

* Section 3.3. is messing up the separation of communication security
=C2=A0 and access control. Furthermore, the advice given that data model =C2=A0 writers should consider whether a client / agent is valid is IMHO =C2=A0 wrong. It is wrong to encode authorization policies into data
=C2=A0 models. =C2=A0The security policy must be configurable at runtime by= a
=C2=A0 security administrator. There needs to be a separation of policy
=C2=A0 from mechanism.

* Similar as above, the advice in section 3.4. that IM/DM writers
=C2=A0 "must discuss determine" whether encryption is a recommend= ation or
=C2=A0 requirement is wrong. It is the job of the security administrator =C2=A0 deploying I2RS to answer those questions. All the IM/DM writer can =C2=A0 reasonably do is to provide guidelines what in particular may need =C2=A0 protection (this is what we are doing for ~20 years for MIB
=C2=A0 modules).

* My understanding is that so called "stacked I2RS agent-clients in =C2=A0 broker topologies" are left out of scope in the architecture. W= hy do
=C2=A0 such things pop up in the security architecture? What is the point =C2=A0 of having an I2RS architecture with a certain scope and then an I2RS=
=C2=A0 security architecture with a bigger scope?

Bottom line is that I strongly prefer if all the security aspects of
the I2RS architecture are covered in the document that defines the
I2RS architecture.

/js

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49= 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, = Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.de/= >

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

--20cf303a30ed467efe04fcc3b6fd-- From nobody Fri Jun 27 00:09:20 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC921B306B for ; Fri, 27 Jun 2014 00:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jenh7A2cbJnn for ; Fri, 27 Jun 2014 00:09:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6707D1B305F for ; Fri, 27 Jun 2014 00:09:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E43DF13D7; Fri, 27 Jun 2014 09:09:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3a9jgK-7ubf5; Fri, 27 Jun 2014 09:09:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Jun 2014 09:09:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FD9920043; Fri, 27 Jun 2014 09:09:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MMXS5wdmD3w7; Fri, 27 Jun 2014 09:09:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0098C20040; Fri, 27 Jun 2014 09:09:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EE0172D9AACA; Fri, 27 Jun 2014 09:09:12 +0200 (CEST) Date: Fri, 27 Jun 2014 09:09:12 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20140627070912.GC26128@elstar.local> Mail-Followup-To: Alia Atlas , "i2rs@ietf.org" References: <20140625135713.GA22139@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/FXFiufz8kynu5grTg9lGR5qjt-c Cc: "i2rs@ietf.org" Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2014 07:09:19 -0000 On Thu, Jun 26, 2014 at 05:13:46PM -0400, Alia Atlas wrote: > Hi Juergen, > > On Wed, Jun 25, 2014 at 9:57 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jun 23, 2014 at 07:09:56PM -0400, Alia Atlas wrote: > > > Based upon the WGLC comments, I have updated these two drafts. Because I > > > believe that the changes are not particularly controversial (except for > > the > > > new reference to NETCONF and RESTCONF), I've published the updated > > versions > > > so that the WG can verify the changes at the same time as my co-authors. > > > > I suggest to take this out again: > > > > Additionally, on March 2, 2014, the IESG issued a statement about > > Writeable MIB Modules which is expected to limit creation of future > > writeable MIB modules. > > > > This is what the statement really says (despite its unfortunate > > title, http://www.ietf.org/iesg/statement/writable-mib-module.html): > > > > SNMP MIB modules creating and modifying configuration state should > > only be produced by working groups in cases of clear utility and > > consensus to use SNMP write operations for configuration, and in > > consultation with the OPS ADs/MIB doctors. > > > > My understanding is that configuration here is meant in the OPS sense > > and my understanding is that I2RS is about changing operations state > > as understood in the OPS community. > > > > I've also heard support for having it in. I think that what it says is > accurate - > that WGs will be asked to think about whether write operations are needed > in MIBs going forward. > > Can you suggest a rewording that you'd be comfortable with? The edit is to simply remove the sentence. And I disagree that the statement says that "WGs will be asked to think about whether write operations are needed in MIBs going forward". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jun 27 00:15:45 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9833B1B2F82 for ; Fri, 27 Jun 2014 00:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpsvRVZeGnlY for ; Fri, 27 Jun 2014 00:15:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDB01B2AEB for ; Fri, 27 Jun 2014 00:15:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F07901382; Fri, 27 Jun 2014 09:15:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SGTY4-SDmOSj; Fri, 27 Jun 2014 09:15:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 27 Jun 2014 09:15:38 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD30020043; Fri, 27 Jun 2014 09:15:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A4CujuNZvrg8; Fri, 27 Jun 2014 09:15:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 237D520040; Fri, 27 Jun 2014 09:15:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D46C2D9AAFB; Fri, 27 Jun 2014 09:15:37 +0200 (CEST) Date: Fri, 27 Jun 2014 09:15:37 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20140627071537.GD26128@elstar.local> Mail-Followup-To: Alia Atlas , Jeffrey Haas , "i2rs@ietf.org" References: <20140624135024.GC11842@pfrc> <20140625135122.GA21995@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/fdC3QMZqQTao-lZzeTMwcmZ7wDs Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2014 07:15:43 -0000 Alia, the security draft claims that it is "an expansion of the security architecture found in the i2rs architecture." Note that it says _architecture_. I believe all _architectural_ security aspects have to be part of the I2RS architecture and there should not be a need for a second I-D to refine them. I personally do not believe anything is missing security wise in the I2RS architecture but apparently several people do. They should make concrete proposals to add missing things to the I2RS architecture instead of pushing a separate I-D. /js On Thu, Jun 26, 2014 at 05:16:53PM -0400, Alia Atlas wrote: > Given the level of maturity of the security draft, that we put into the > architecture draft > what we think is good guidance without selecting existing mechanisms, and > that we > are trying to finish the architecture draft, do you really see aspects > missing and if so, > precisely what, around the security section? > > I don't want to confuse cherry-picking the parts that are needed from an > immature draft > with information that is missing from the architecture. > > IMHO, we will need a draft that talks about what protocols can meet the > requirements, > whether there is a mandatory-to-implement, and so on. That draft may or > may not be > what the efforts at the security draft matures into. > > Regards, > Alia > > > On Wed, Jun 25, 2014 at 9:51 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Jun 24, 2014 at 09:50:24AM -0400, Jeffrey Haas wrote: > > > > > > If you were paying specific attention to the security issues, please also > > > review the security draft. > > > > > > > I have been trying to read draft-hares-i2rs-security-01.txt and to > > match it against draft-ietf-i2rs-architecture-04.txt and I have come > > to the solution that we should > > > > - stop work draft-hares-i2rs-security-01.txt and > > > > - merge all statements from this I-D that are worth keeping and that > > are not yet part of draft-ietf-i2rs-architecture-04.txt into > > draft-ietf-i2rs-architecture-04.txt. > > > > There are numerous places where I the documents are inconsistent and > > this should be avoided if all possible and one way of doing this is > > make sure there is only one document talking about I2RS security > > 'architecture'. And I do not see a convincing point why the I2RS > > security 'architecture' should not be sufficiently defined in the I2RS > > architecture - in fact I see many good reasons why the whole I2RS > > architecture should be in one document. > > > > To substantiate my position, I will list several examples that make > > me concerned. But note that this list is not complete. > > > > * I am concerned about MUST statements in the security document that I > > do not find in the architecture document. Or, if these MUST > > statements are already in the architecture document, then there is > > no point in repeating them in the security document. > > > > * I am concerned about definitions such as Role in the security > > document that I do not find in the same meaning in the architecture > > document. Furthermore, I am worried about terms like 'routing tree' > > that are not well defined in the security document and do not exist > > in the architecture document. I note that the definition of Role is > > actually inconsistent even within the security document (e.g., > > 3.3. and 3.1). > > > > * There are concepts in the security document like I2RS identity > > repositories that I do not find in the I2RS architecture. > > > > * The section 3.2 of the security document gives guidelines that on > > things like that with symmetric keys, "sequence numbers which > > increase monotonically could be useful to help distinguishing > > replayed messages". I believe this goes way beyond _architectural_ > > concerns and worse it kind of implies that I2RS may invent their > > security protocol instead of using one of the already available and > > well understood security protocols we have. > > > > * Section 3.3. is messing up the separation of communication security > > and access control. Furthermore, the advice given that data model > > writers should consider whether a client / agent is valid is IMHO > > wrong. It is wrong to encode authorization policies into data > > models. The security policy must be configurable at runtime by a > > security administrator. There needs to be a separation of policy > > from mechanism. > > > > * Similar as above, the advice in section 3.4. that IM/DM writers > > "must discuss determine" whether encryption is a recommendation or > > requirement is wrong. It is the job of the security administrator > > deploying I2RS to answer those questions. All the IM/DM writer can > > reasonably do is to provide guidelines what in particular may need > > protection (this is what we are doing for ~20 years for MIB > > modules). > > > > * My understanding is that so called "stacked I2RS agent-clients in > > broker topologies" are left out of scope in the architecture. Why do > > such things pop up in the security architecture? What is the point > > of having an I2RS architecture with a certain scope and then an I2RS > > security architecture with a bigger scope? > > > > Bottom line is that I strongly prefer if all the security aspects of > > the I2RS architecture are covered in the document that defines the > > I2RS architecture. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jun 27 06:13:06 2014 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9BD1B2F41 for ; Fri, 27 Jun 2014 06:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9N_ex6z6wIt for ; Fri, 27 Jun 2014 06:13:04 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id E8A051B2B76 for ; Fri, 27 Jun 2014 06:13:03 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,560,1400040000"; d="scan'208";a="384280117" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 27 Jun 2014 09:12:08 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Fri, 27 Jun 2014 09:12:40 -0400 From: "George, Wes" To: Juergen Schoenwaelder , Alia Atlas Date: Fri, 27 Jun 2014 09:12:39 -0400 Thread-Topic: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 Thread-Index: Ac+SCXjwM7ZyTiTUS3WckpFk7lysBg== Message-ID: References: <20140625135713.GA22139@elstar.local> <20140627070912.GC26128@elstar.local> In-Reply-To: <20140627070912.GC26128@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/i2rs/EL1AZemfrjr2tJwKJTKdfOYipoU Cc: "i2rs@ietf.org" Subject: Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:13:05 -0000 T24gNi8yNy8xNCwgMzowOSBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciINCjxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQoNCj4+SSd2ZSBhbHNvIGhlYXJk IHN1cHBvcnQgZm9yIGhhdmluZyBpdCBpbi4gIEkgdGhpbmsgdGhhdCB3aGF0IGl0IHNheXMgaXMN Cj4+IGFjY3VyYXRlIC0NCj4+IHRoYXQgV0dzIHdpbGwgYmUgYXNrZWQgdG8gdGhpbmsgYWJvdXQg d2hldGhlciB3cml0ZSBvcGVyYXRpb25zIGFyZQ0KPj5uZWVkZWQNCj4+IGluIE1JQnMgZ29pbmcg Zm9yd2FyZC4NCj4+DQo+PiBDYW4geW91IHN1Z2dlc3QgYSByZXdvcmRpbmcgdGhhdCB5b3UnZCBi ZSBjb21mb3J0YWJsZSB3aXRoPw0KPg0KPlRoZSBlZGl0IGlzIHRvIHNpbXBseSByZW1vdmUgdGhl IHNlbnRlbmNlLg0KPg0KPkFuZCBJIGRpc2FncmVlIHRoYXQgdGhlIHN0YXRlbWVudCBzYXlzIHRo YXQgIldHcyB3aWxsIGJlIGFza2VkIHRvDQo+dGhpbmsgYWJvdXQgd2hldGhlciB3cml0ZSBvcGVy YXRpb25zIGFyZSBuZWVkZWQgaW4gTUlCcyBnb2luZw0KPmZvcndhcmQiLg0KDQpXR10gd2VsbCwg dGhlIG9ic2VydmF0aW9uIGlzIGFjY3VyYXRlLCB3aGV0aGVyIHRoZSBzdGF0ZW1lbnQgYWN0dWFs bHkgc2F5cw0KdGhhdCBvciBub3QsIGJlY2F1c2UgcGVvcGxlIHdpbGwgYXNrLiBBbGlhLCBzaW5j ZSBJJ20gdGhlIG9uZSB0aGF0DQpzdWdnZXN0ZWQgdGhhdCB3ZSBhZGRyZXNzIHRoaXMsIEkgc3Vn Z2VzdCB0aGF0IHlvdSBzaW1wbHkgbWFrZSBhbg0KaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRo ZSBzdGF0ZW1lbnQgd2l0aG91dCBhIGxvdCBvZiBlZGl0b3JpYWxpemluZywNCnBvc3NpYmx5IGp1 c3QgcXVvdGluZyB0aGUgcmVsZXZhbnQgcGFydCB0aGF0IEp1ZXJnZW4gaW5jbHVkZWQgaW4gaGlz DQpyZXNwb25zZS4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxp bmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUg bm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoNClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K