From N.Leymann@telekom.de Tue Jul 2 04:29:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328E511E8485 for ; Tue, 2 Jul 2013 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeBwUXAOGoHu for ; Tue, 2 Jul 2013 04:29:35 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40821F99A2 for ; Tue, 2 Jul 2013 04:29:27 -0700 (PDT) Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jul 2013 13:29:25 +0200 Received: from HE100024.emea1.cds.t-internal.com (10.125.65.200) by HE101251.emea1.cds.t-internal.com (10.125.92.154) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 2 Jul 2013 13:29:25 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE100024.emea1.cds.t-internal.com ([2002:769:410c::769:410c]) with mapi; Tue, 2 Jul 2013 13:29:25 +0200 From: To: , Date: Tue, 2 Jul 2013 13:29:24 +0200 Thread-Topic: [i2rs] comments on draft-atlas-i2rs-architecture-00 Thread-Index: Ac50FtkRtBf/0bNXRlOsTEKB74zYGgC/0aVg Message-ID: <9762ACF04FA26B4388476841256BDE02011AD557360D@HE111543.emea1.cds.t-internal.com> References: <51CDB017.5030609@joelhalpern.com> In-Reply-To: <51CDB017.5030609@joelhalpern.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: i2rs@ietf.org Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 11:29:40 -0000 Hi, [....] >for collision detection. (I personally expect "entire table" to be a >very rare case.) >More complex collisions are not expected to be noticed by the system. >If a client manipulating item A depends upon the value of item B, it >should register for notifications of changes to B. I assume that this will be independent of the source of the change (e.g. whether B was changed by another client or by CLI, Routing, SNMP, ...)? Regards Nic From akatlas@gmail.com Tue Jul 2 06:35:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9676F21F9DBA for ; Tue, 2 Jul 2013 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZsx2TgxrhxT for ; Tue, 2 Jul 2013 06:35:45 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6121F9DB7 for ; Tue, 2 Jul 2013 06:35:44 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so12472199iea.32 for ; Tue, 02 Jul 2013 06:35:44 -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=nF7x9DRo0Ow9C9LQ/3pvwTKSM9JtStpNU+CsG8Ri0nY=; b=hoYyXrXSI7z2e8hbsmznEcjFPsjrMbcoU0J4Bsi0fFQawhysBJt/Ub/1c4QCIL9qvU nP/b7S+Z6+pKNU8FoftwpV+agj8GVnpGssBi/iGVgpn8zYiEbRLwCbDRY6J+oxELaJIh FCbQweroQZoJPcRE3rAM83c4zB3dLT2dgFBjxoYcEfCRuVm7smY6HuuO0LeAB8hWRU9G 1SGacn9Jh1RfqgZ1Hr73S6MXaiTim7dk/QseJZxiY8ago6Wh3Zqrnj3xJqMRoKISUhaS JcdtsVX7SloXhD9cQSSD8AG1Qk75CgAEq7u4XJGFGl+GRiBmPTQVy75WyKbmXCG8bAqG KzMQ== MIME-Version: 1.0 X-Received: by 10.50.77.80 with SMTP id q16mr20511599igw.3.1372772144487; Tue, 02 Jul 2013 06:35:44 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Tue, 2 Jul 2013 06:35:44 -0700 (PDT) In-Reply-To: <9762ACF04FA26B4388476841256BDE02011AD557360D@HE111543.emea1.cds.t-internal.com> References: <51CDB017.5030609@joelhalpern.com> <9762ACF04FA26B4388476841256BDE02011AD557360D@HE111543.emea1.cds.t-internal.com> Date: Tue, 2 Jul 2013 09:35:44 -0400 Message-ID: From: Alia Atlas To: "N.Leymann@telekom.de" Content-Type: multipart/alternative; boundary=047d7bdc123807a1f704e0876cf3 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , Andy Bierman Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:35:45 -0000 --047d7bdc123807a1f704e0876cf3 Content-Type: text/plain; charset=ISO-8859-1 Exactly so - at least in my view. Alia On Tue, Jul 2, 2013 at 7:29 AM, wrote: > Hi, > > [....] > >for collision detection. (I personally expect "entire table" to be a > >very rare case.) > >More complex collisions are not expected to be noticed by the system. > >If a client manipulating item A depends upon the value of item B, it > >should register for notifications of changes to B. > I assume that this will be independent of the source of the change > (e.g. whether B was changed by another client or by CLI, Routing, > SNMP, ...)? > > Regards > > Nic > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7bdc123807a1f704e0876cf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Exactly so - at least in my view.

Alia<= /div>


On= Tue, Jul 2, 2013 at 7:29 AM, <N.Leymann@telekom.de> wro= te:
Hi,

[....]
>for collision detection. (I personally expect "e= ntire table" to be a
>very rare case.)
>More complex collisions are not expected to be noticed by the system. >If a client manipulating item A depends upon the value of item B, it >should register for notifications of changes to B.
I assume that this will be independent of the source of the change (e.g. whether B was changed by another client or by CLI, Routing,
SNMP, ...)?

=A0 Regards

=A0 =A0 =A0Nic
___________________________________= ____________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7bdc123807a1f704e0876cf3-- From jmh@joelhalpern.com Tue Jul 2 06:39:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7F21F9C82 for ; Tue, 2 Jul 2013 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGRpXiH8i9rn for ; Tue, 2 Jul 2013 06:39:41 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D504621F8FF8 for ; Tue, 2 Jul 2013 06:39:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 382B81BD40AB; Tue, 2 Jul 2013 06:39:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-124.clppva.east.verizon.net [70.106.134.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 74F0C1BD41AF; Tue, 2 Jul 2013 06:39:34 -0700 (PDT) Message-ID: <51D2D813.2070803@joelhalpern.com> Date: Tue, 02 Jul 2013 09:39:31 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: N.Leymann@telekom.de References: <51CDB017.5030609@joelhalpern.com> <9762ACF04FA26B4388476841256BDE02011AD557360D@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE02011AD557360D@HE111543.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: i2rs@ietf.org, andy@yumaworks.com Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:39:47 -0000 That, independence of change source, sounds right to me. Thanks, Joel On 7/2/2013 7:29 AM, N.Leymann@telekom.de wrote: > Hi, > > [....] >> for collision detection. (I personally expect "entire table" to be a >> very rare case.) >> More complex collisions are not expected to be noticed by the system. >> If a client manipulating item A depends upon the value of item B, it >> should register for notifications of changes to B. > I assume that this will be independent of the source of the change > (e.g. whether B was changed by another client or by CLI, Routing, > SNMP, ...)? > > Regards > > Nic > From jmh.direct@joelhalpern.com Fri Jun 28 19:28:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C19121F9E1F for ; Fri, 28 Jun 2013 19:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdEoMTOjMCSd for ; Fri, 28 Jun 2013 19:27:55 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED621F9E16 for ; Fri, 28 Jun 2013 19:27:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A070C1D4D97; Fri, 28 Jun 2013 19:27:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from localhost (unknown [166.137.82.102]) by mailb2.tigertech.net (Postfix) with ESMTPA id 76E251C004D; Fri, 28 Jun 2013 19:27:53 -0700 (PDT) Date: Fri, 28 Jun 2013 22:16:38 -0400 Message-ID: Importance: low From: "Jmh.direct" To: andy@yumaworks.com, jmh@joelhalpern.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_945387860150473" X-Mailman-Approved-At: Tue, 02 Jul 2013 08:55:14 -0700 Cc: i2rs@ietf.org Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 02:28:01 -0000 ----_com.android.email_945387860150473 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLgpUaGFua3MsCkpvZWwKCgpTZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBo b25lIG9uIEFUJlQKCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KU3ViamVjdDog UmU6IFtpMnJzXSBjb21tZW50cyBvbiBkcmFmdC1hdGxhcy1pMnJzLWFyY2hpdGVjdHVyZS0wMCAK RnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IApUbzogIkpvZWwgTS4gSGFs cGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+IApDQzogaTJyc0BpZXRmLm9yZyAKCm51bGw= ----_com.android.email_945387860150473 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5Xb3JrcyBmb3IgbWUuPGRpdj5UaGFu a3MsPC9kaXY+PGRpdj5Kb2VsPGJyPjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4NyUi PlNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmYW1wO1Q8L3NwYW4+IDwvZGl2 Pjxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+U3ViamVj dDogUmU6IFtpMnJzXSBjb21tZW50cyBvbiBkcmFmdC1hdGxhcy1pMnJzLWFyY2hpdGVjdHVyZS0w MCA8YnI+RnJvbTogQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7IDxicj5U bzogIkpvZWwgTS4gSGFscGVybiIgJmx0O2ptaEBqb2VsaGFscGVybi5jb20mZ3Q7IDxicj5DQzog aTJyc0BpZXRmLm9yZyA8YnI+PGJyPjxicj4gPC9ib2R5Pg== ----_com.android.email_945387860150473-- From akatlas@juniper.net Tue Jul 2 14:14:43 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D323611E80E0 for ; Tue, 2 Jul 2013 14:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IRG+ZxnURav for ; Tue, 2 Jul 2013 14:14:37 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4121F8904 for ; Tue, 2 Jul 2013 14:14:36 -0700 (PDT) Received: from mail113-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Tue, 2 Jul 2013 21:14:27 +0000 Received: from mail113-ch1 (localhost [127.0.0.1]) by mail113-ch1-R.bigfish.com (Postfix) with ESMTP id CD8BA3A015A for ; Tue, 2 Jul 2013 21:14:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzc85fhzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail113-ch1: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail113-ch1 (localhost.localdomain [127.0.0.1]) by mail113-ch1 (MessageSwitch) id 1372799665529468_12254; Tue, 2 Jul 2013 21:14:25 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail113-ch1.bigfish.com (Postfix) with ESMTP id 7D386140050 for ; Tue, 2 Jul 2013 21:14:25 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 21:14:25 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Jul 2013 14:14:24 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 2 Jul 2013 14:14:23 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 2 Jul 2013 14:26:11 -0700 Received: from mail133-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Jul 2013 21:14:23 +0000 Received: from mail133-co1 (localhost [127.0.0.1]) by mail133-co1-R.bigfish.com (Postfix) with ESMTP id 2484A40089 for ; Tue, 2 Jul 2013 21:14:23 +0000 (UTC) Received: from mail133-co1 (localhost.localdomain [127.0.0.1]) by mail133-co1 (MessageSwitch) id 1372799661343056_8511; Tue, 2 Jul 2013 21:14:21 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.247]) by mail133-co1.bigfish.com (Postfix) with ESMTP id 5043DA6004A for ; Tue, 2 Jul 2013 21:14:21 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Jul 2013 21:14:20 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Tue, 2 Jul 2013 21:14:17 +0000 From: Alia Atlas To: "i2rs@ietf.org" Thread-Topic: draft submission deadline - July 15 24:00 UTC Thread-Index: Ac53aRsh0gKZeybHQ3Od/7QgV46rwg== Date: Tue, 2 Jul 2013 21:14:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B35138C42BY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [i2rs] draft submission deadline - July 15 24:00 UTC X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:14:43 -0000 --_000_D1CF735B7C7B744582438550F826E01B35138C42BY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In what may be happy news for some of you, I just learned that the IESG has= merged the two internet-draft deadlines. Both initial document (-00) and = final documents can be submitted until July 15. But remember that we'd all like to read your fascinating ideas and mull the= m over - so sooner is still better :) Alia --_000_D1CF735B7C7B744582438550F826E01B35138C42BY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In what may be happy news for some of you, I just learned that the IES= G has merged the two internet-draft deadlines.  Both initial document = (-00) and final documents can be submitted until July 15.
 
But remember that we’d all like to read your fascinating ideas a= nd mull them over – so sooner is still better J
 
Alia
 
 --_000_D1CF735B7C7B744582438550F826E01B35138C42BY2PRD0510MB389_-- From russw@riw.us Thu Jul 4 14:41:11 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11DAF11E81D0 for ; Thu, 4 Jul 2013 14:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZOjclu5a+zj for ; Thu, 4 Jul 2013 14:41:04 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 40FE811E81C0 for ; Thu, 4 Jul 2013 14:41:04 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1UurGr-0007nJ-FP; Thu, 04 Jul 2013 14:40:57 -0700 From: "Russ White" To: , , References: <9762ACF04FA26B4388476841256BDE02011A939375CF@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE02011A939375CF@HE111543.emea1.cds.t-internal.com> Date: Thu, 4 Jul 2013 17:41:02 -0400 Message-ID: <011001ce78ff$2f8ac420$8ea04c60$@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: AQNl/DWa2AygQDLa+v5Vpy+WK7vB/AJq0Yg5lhKvGBA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] comments on draft-atlas-i2rs-problem-statement? X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 21:41:11 -0000 > - Also decoupling of life cycles (e.g. between an application and the network > functionality) is one problem which needs > to addressed. At the moment in many cases there is (still and > unfortunately) a close relationship between a (network) > service and the configuration of the network nodes. E.g. > configuration changes are necessary and even software updates > in order to support a certain service required by a product. With I2RS we > could make thos two things independent. > The "application" uses the well defined I2RS interface in order to influence > routing. No direct access to the nodes is > necessary. Thefore in ideal case the software life cycle of the software on > the node is independet of the software > life cyles of the application. I'm not certain how this could be addressed in the draft --nor what specific value it would bring. I think there might want to be an "operational issues," draft someplace where this could fit better than in a problem statement, per se? :-) Russ From russw@riw.us Thu Jul 4 14:44:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B638911E81C0 for ; Thu, 4 Jul 2013 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FB_ROLLER_IS_T=1.357] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEWI6USJKOB0 for ; Thu, 4 Jul 2013 14:44:08 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2F11E81B6 for ; Thu, 4 Jul 2013 14:44:08 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1UurJv-0007xg-10; Thu, 04 Jul 2013 14:44:07 -0700 From: "Russ White" To: "'Andy Bierman'" , "'Joel M. Halpern'" References: <51CDB017.5030609@joelhalpern.com> <51CDCB9D.4000009@joelhalpern.com> In-Reply-To: Date: Thu, 4 Jul 2013 17:44:12 -0400 Message-ID: <011101ce78ff$a08f9100$e1aeb300$@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: AQNBaMfiqkZ1sEJj7HNer5i3cWAW8wFVwg0BAfyiC/gChyS+wwFcThr+ljV+bBA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org Subject: Re: [i2rs] comments on draft-atlas-i2rs-architecture-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 21:44:13 -0000 > > In contrast, with perform all or perform until error the client is > > telling the agent not to worry about interacting dependencies. The > > agent can simply apply the changes in the message one at a time to the > system. > > > > The later is muh simpler o implement, and much faster to apply. That > > efficiency is important for many I2RS cases. But it clearly does not > > cover everything folks will want to do with I2RS, so we need the former as > well. I think this would probably interact favorable with an atomic interface model... Which is what I would prefer anyway. If the point of this exercise is to move intelligence to the controller (at least to centralize policy!), then it seems like leaving the intelligence in the controller is the best bet. The more intelligence we add to the agent/end device, the most complex the protocol, and the end (forwarding) device need to be... :-) Russ From akatlas@gmail.com Fri Jul 5 17:25:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6876C21F9E63 for ; Fri, 5 Jul 2013 17:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Gs7rkqVSh1 for ; Fri, 5 Jul 2013 17:25:17 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DFB6021F9E66 for ; Fri, 5 Jul 2013 17:25:16 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so6573130iec.13 for ; Fri, 05 Jul 2013 17:25: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 :content-type; bh=rmQY0HfJcL0iPr1X3OQ2vOmugHjh5FhiF7qbDyhdD8s=; b=AvN1Tju8Om2hPMoXbKtAd46Ie+5PJjjq1YPrriW3HZoAfFMyp6isedkeYArYyeNXyp i8xl1ryKlrnk0WrbjMZ9EY2z7NEf/sgk4SjVogK3htkm4+HGNt8wFKGfTMJHC9Pg1AKE jwCx6eazn0G2U+3xVkbF+EdjmGIGJek5bff0/6z5sTqloI5WLifPMcGz981PjEknNkf9 2pbS0CZY6XKpRO1AESg7SeEgIS7jDzwuf/yeF7RGWynVjssqgS62I8bIjeemppumWsKD 2zIE1s5HdGn824cSUHFoj9V5W8VLuKr5PV4C/weHEIX1O6WyXtMInqJYldKCvHhXFCi/ By4A== MIME-Version: 1.0 X-Received: by 10.43.12.198 with SMTP id pj6mr4528659icb.68.1373070316254; Fri, 05 Jul 2013 17:25:16 -0700 (PDT) Received: by 10.64.47.168 with HTTP; Fri, 5 Jul 2013 17:25:16 -0700 (PDT) In-Reply-To: <20130706002000.640.24427.idtracker@ietfa.amsl.com> References: <20130706002000.640.24427.idtracker@ietfa.amsl.com> Date: Fri, 5 Jul 2013 20:25:16 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec518701c73c37904e0ccd8bc Subject: [i2rs] Fwd: IETF 87 Final Agenda X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 00:25:17 -0000 --bcaec518701c73c37904e0ccd8bc Content-Type: text/plain; charset=ISO-8859-1 I2RS is scheduled for Thursday Afternoon Session I ---------- Forwarded message ---------- From: IETF Agenda Date: Fri, Jul 5, 2013 at 8:20 PM Subject: IETF 87 Final Agenda To: IETF Announcement List Cc: ietf@ietf.org 87th IETF Meeting - Berlin, Germany July 28 - August 2, 2013 The final agenda has been posted. https://datatracker.ietf.org/meeting/87/agenda.html https://datatracker.ietf.org/meeting/87/agenda.txt While this is considered the final agenda for printing, changes may be made to the agenda up until and during the meeting. Updates will be reflected on the web version of the agenda. Information about the 87th IETF meeting in Berlin, Germany can be found here: https://www.ietf.org/meeting/87/index.html Thank you and see you in Berlin! Sincerely, The IETF Secretariat --bcaec518701c73c37904e0ccd8bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I2RS is scheduled for=A0Thursday Afternoon Session I

---------- Forwarded message ----------
From: IETF Agenda <agenda@ietf.org>
Date: Fri, Jul 5, 2013 at 8:20 PM
Su= bject: IETF 87 Final Agenda
To: IETF Announcement List <ie= tf-announce@ietf.org>
Cc: ietf@i= etf.org



87th IETF Meeting - Berlin, Germany
July 28 - August 2, 2013

The final agenda has been posted.

https://datatracker.ietf.org/meeting/87/agenda.html
https://datatracker.ietf.org/meeting/87/agenda.txt

While this is considered the final agenda for printing, changes may
be made to the agenda up until and during the meeting. Updates will be refl= ected on the web version of the agenda.

Information about the 87th IETF meeting in Berlin, Germany can be found her= e: https://www.ietf.org/meeting/87/index.html

Thank you and see you in Berlin!

Sincerely,

The IETF Secretariat

--bcaec518701c73c37904e0ccd8bc-- From akatlas@juniper.net Mon Jul 8 12:29:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A621F9977 for ; Mon, 8 Jul 2013 12:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=1.882, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IEyLQbYdwAn for ; Mon, 8 Jul 2013 12:29:14 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7CA21F96EF for ; Mon, 8 Jul 2013 12:29:14 -0700 (PDT) Received: from mail52-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE009.bigfish.com (10.236.130.72) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:29:13 +0000 Received: from mail52-co9 (localhost [127.0.0.1]) by mail52-co9-R.bigfish.com (Postfix) with ESMTP id 8438C940383 for ; Mon, 8 Jul 2013 19:29:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail52-co9: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=akatlas@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail52-co9 (localhost.localdomain [127.0.0.1]) by mail52-co9 (MessageSwitch) id 1373311750903599_2458; Mon, 8 Jul 2013 19:29:10 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.226]) by mail52-co9.bigfish.com (Postfix) with ESMTP id D905D2E0064 for ; Mon, 8 Jul 2013 19:29:10 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.51) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:29:09 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Jul 2013 12:29:08 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 8 Jul 2013 12:29:08 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:32:55 -0700 Received: from mail160-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:29:07 +0000 Received: from mail160-tx2 (localhost [127.0.0.1]) by mail160-tx2-R.bigfish.com (Postfix) with ESMTP id AB9AC1C00E0 for ; Mon, 8 Jul 2013 19:29:07 +0000 (UTC) Received: from mail160-tx2 (localhost.localdomain [127.0.0.1]) by mail160-tx2 (MessageSwitch) id 1373311708485337_27853; Mon, 8 Jul 2013 19:28:28 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.241]) by mail160-tx2.bigfish.com (Postfix) with ESMTP id 676CB3E02F1 for ; Mon, 8 Jul 2013 19:28:28 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:28:28 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.169]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0324.000; Mon, 8 Jul 2013 19:28:27 +0000 From: Alia Atlas To: "i2rs@ietf.org" Thread-Topic: IETF-87 agenda topics for i2rs Thread-Index: Ac58EVEcdovNKcVLTr6NKaWmhehDDQ== Date: Mon, 8 Jul 2013 19:28:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3513C6BEBY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [i2rs] IETF-87 agenda topics for i2rs X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:29:21 -0000 --_000_D1CF735B7C7B744582438550F826E01B3513C6BEBY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I2RS is scheduled to meet on Thursday, August 1 from 13:00-15:00. Please f= orward any I2RS agenda items you have to Ed and myself. The deadline is Ju= ly 16 - but earlier is better. Our WG agenda is due on July 17. Our focus is on problem-statement, architecture, use-cases, and information= models. We do require an internet-draft (with planned-to-be very rare exc= eptions). For accepted presentations, please provide your slides by July 30 10pm CET. Finally, if you request an agenda slot, please do so by replying to this me= ssage and don't change the subject line. Thanks, Alia and Ed --_000_D1CF735B7C7B744582438550F826E01B3513C6BEBY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I2RS is scheduled to meet on Thursday, August 1 from 13:00-15:00. = ; Please forward any I2RS agenda items you have to Ed and myself.  The= deadline is July 16 – but earlier is better.    Our W= G agenda is due on July 17.
 
Our focus is on problem-statement, architecture, use-cases, and inform= ation models.  We do require an internet-draft (with planned-to-be ver= y rare exceptions).
 
For accepted presentations, please provide your slides by July 30 10pm= CET.
 
Finally, if you request an agenda slot, please do so by replyin= g to this message and don't change the subject line.
 
Thanks,
Alia and Ed
 
 --_000_D1CF735B7C7B744582438550F826E01B3513C6BEBY2PRD0510MB389_-- From akatlas@juniper.net Fri Jul 12 08:42:05 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3B11E811A for ; Fri, 12 Jul 2013 08:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.565 X-Spam-Level: X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsYGmesXKRNm for ; Fri, 12 Jul 2013 08:41:58 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8911E813A for ; Fri, 12 Jul 2013 08:41:51 -0700 (PDT) Received: from mail124-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 15:41:50 +0000 Received: from mail124-db8 (localhost [127.0.0.1]) by mail124-db8-R.bigfish.com (Postfix) with ESMTP id 39B9AA048F for ; Fri, 12 Jul 2013 15:41:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85fh4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz18c673hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail124-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=akatlas@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail124-db8 (localhost.localdomain [127.0.0.1]) by mail124-db8 (MessageSwitch) id 1373643708205128_22103; Fri, 12 Jul 2013 15:41:48 +0000 (UTC) Received: from DB8EHSMHS027.bigfish.com (unknown [10.174.8.249]) by mail124-db8.bigfish.com (Postfix) with ESMTP id 2AD451C0048 for ; Fri, 12 Jul 2013 15:41:48 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS027.bigfish.com (10.174.4.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 12 Jul 2013 15:41:46 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Jul 2013 08:41:44 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 12 Jul 2013 08:41:43 -0700 Received: from CO9EHSOBE027.bigfish.com (207.46.163.26) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 12 Jul 2013 08:54:23 -0700 Received: from mail194-co9-R.bigfish.com (10.236.132.240) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Fri, 12 Jul 2013 15:41:43 +0000 Received: from mail194-co9 (localhost [127.0.0.1]) by mail194-co9-R.bigfish.com (Postfix) with ESMTP id 0D0C11C04E9 for ; Fri, 12 Jul 2013 15:41:43 +0000 (UTC) Received: from mail194-co9 (localhost.localdomain [127.0.0.1]) by mail194-co9 (MessageSwitch) id 1373643701570305_13318; Fri, 12 Jul 2013 15:41:41 +0000 (UTC) Received: from CO9EHSMHS017.bigfish.com (unknown [10.236.132.230]) by mail194-co9.bigfish.com (Postfix) with ESMTP id 7EE2838004C; Fri, 12 Jul 2013 15:41:41 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CO9EHSMHS017.bigfish.com (10.236.130.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Jul 2013 15:41:40 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.99]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0324.000; Fri, 12 Jul 2013 15:41:39 +0000 From: Alia Atlas To: "i2rs@ietf.org" Thread-Topic: drafts planned to ask for WG adoption Thread-Index: Ac5/Fkt86MkHP56rTe+PDolvvcgX1g== Date: Fri, 12 Jul 2013 15:41:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B3A928166BY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GOOGLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Edward Crabbe Subject: [i2rs] drafts planned to ask for WG adoption X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:42:05 -0000 --_000_D1CF735B7C7B744582438550F826E01B3A928166BY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ed and I plan to ask about consensus for working group adoption for the fol= lowing drafts: draft-atlas-i2rs-problem-statement-01 (to be published later today/Monday) draft-atlas-i2rs-architecture-01 (to be published later today/Monday) draft-keyupdate-i2rs-bgp-usecases-02 (just published) draft-nitinb-i2rs-rib-info-model-01 (to be published Monday) We intend to conclude the WG adoption discuss on August 12. Please read an= d focus on these drafts. We hope there will be other drafts ready to consider for WG adoption - but = this is the first clear set. Thanks, Alia --_000_D1CF735B7C7B744582438550F826E01B3A928166BY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ed and I plan to ask about consensus for working group adoption for th= e following drafts:
 
draft-atlas-i2rs-problem-statement-01  (to be published later tod= ay/Monday)
draft-atlas-i2rs-architecture-01 (to be published later today/Monday)<= /div>
draft-keyupdate-i2rs-bgp-usecases-02 (just published)
draft-nitinb-i2rs-rib-info-model-01  (to be published Monday)
 
We intend to conclude the WG adoption discuss on August 12.  Plea= se read and focus on these drafts.
We hope there will be other drafts ready to consider for WG adoption &= #8211; but this is the first clear set.
 
Thanks,
Alia
 
 --_000_D1CF735B7C7B744582438550F826E01B3A928166BY2PRD0510MB389_-- From jmh@joelhalpern.com Fri Jul 12 10:29:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365711E811E for ; Fri, 12 Jul 2013 10:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqlBczeEdL6Z for ; Fri, 12 Jul 2013 10:29:10 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D4AB421E80A9 for ; Fri, 12 Jul 2013 10:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BE8711C081A for ; Fri, 12 Jul 2013 10:29:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3B58C1C060F for ; Fri, 12 Jul 2013 10:29:10 -0700 (PDT) Message-ID: <51E03CDE.6000905@joelhalpern.com> Date: Fri, 12 Jul 2013 13:29:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "i2rs@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [i2rs] draft-keyupdate-i2rs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 17:29:18 -0000 Looking at this draft, it has a number of very helpful use cases. I support adopting this draft by the working group. I do have two questions about one aspect of the content. Section 2 on BGP configuration describes a number of complicated problems in current BGP configuration. However, I do not understand how using I2RS would substantially help address the actual difficulties. These are not problems that depend upon topology knowledge, nor are they tasks that are generally driven by application interfaces. (The VPN case may be an exception to the later.) More importantly, these seem to be configuration operations which should be essentially permanent and fully integrated with the basic configuration of the device. My understanding is that I2RS is not intended to supplant that base configuration. Possibly I am confused in this regard? Thank you, Joel On 7/12/2013 11:41 AM, Alia Atlas wrote: > Ed and I plan to ask about consensus for working group adoption for the > following drafts: ... > draft-keyupdate-i2rs-bgp-usecases-02 (just published) ... > Thanks, > Alia > From russw@riw.us Mon Jul 15 05:15:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DFE11E80E8 for ; Mon, 15 Jul 2013 05:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCbDfbelFnRs for ; Mon, 15 Jul 2013 05:15:47 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id D145311E80C5 for ; Mon, 15 Jul 2013 05:15:46 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1Uyhgw-0003zU-6Y; Mon, 15 Jul 2013 05:15:46 -0700 From: "Russ White" To: "'Joel M. Halpern'" , References: <51E03CDE.6000905@joelhalpern.com> In-Reply-To: <51E03CDE.6000905@joelhalpern.com> Date: Mon, 15 Jul 2013 08:15:44 -0400 Message-ID: <020501ce8155$08b647d0$1a22d770$@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: AQJN9Yw59TNBHnMv4Hn+/DwR7toLZwIp6q+YmFVtuVA= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] draft-keyupdate-i2rs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:15:53 -0000 Joel: > However, I do not understand how using I2RS would substantially help > address the actual difficulties. These are not problems that depend upon > topology knowledge, nor are they tasks that are generally driven by > application interfaces. (The VPN case may be an exception to the later.) > More importantly, these seem to be configuration operations which should > be essentially permanent and fully integrated with the basic configuration of > the device. My understanding is that I2RS is not intended to supplant that > base configuration. Possibly I am confused in this regard? I think you bring up an important point here... It seems, to me, that I2RS got off to a good start with only dealing with one specific area of use cases --where knowledge of the topology is important, and hence interaction would primarily be with the routing system at the layer 3 forwarding table. It seems, to me (anyway), that we've since moved into the realm of "configuring anything that has to do with routing," which means replacing existing mechanisms rather than simply supplementing what's already there with "new stuff." I.e., we're trying to boil the ocean, and, "the ocean ain't gonna be boiled." By moving into the "pure" configuration space, we've opened up the same argument space that has plagued MIBs verses YANG verses ... for years. Which has made for some entertaining reading, to be certain, but... I'm not certain we should have slipped our scope to take on such a huge problem so quickly. Maybe we should try and regain some focus here. If we can solve the problem no-one else solves (interaction with the routing system, beginning with the simple stuff, like just interacting with the layer 3 forwarding table), then we can branch out and start looking at routing policy, and then out into other things, like provisioning, etc. At each step of the way, we should seriously consider what "new thing" we can bring to the table, to make certain we're not just putting the second bake on the potatoes. Just my 2c. --feel free to disagree, or to just tell me I'm all wet. :-) Russ From russw@riw.us Mon Jul 15 05:44:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89DF21F9FE2 for ; Mon, 15 Jul 2013 05:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zas5sjmIlGS4 for ; Mon, 15 Jul 2013 05:44:33 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC4421F9F96 for ; Mon, 15 Jul 2013 05:44:32 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1Uyi8l-0006JS-ML; Mon, 15 Jul 2013 05:44:31 -0700 From: "Russ White" To: Date: Mon, 15 Jul 2013 08:44:30 -0400 Message-ID: <027a01ce8159$0d2f28f0$278d7ad0$@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: Ac6BV9mxNi7PyssnRIGt/4lbCgtdGg== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: zhuyq@gsta.com Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:44:39 -0000 Y'all: It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase might provide a solid use case to add to one of our use case drafts in I2RS. The basic idea is this: Rather than advertising multiple routes using something like add-paths to optimize traffic flow between eBGP edges, why not just have the RR advertise only the route that's best from each eBGP speaker's perspective? Now, I have a long standing desire to see it implemented. OTOH, even if add-paths is implemented, there is the issue of which set of paths to send to the RR clients in any given situation. So I don't see draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to add-paths, but rather a complimentary idea. But how is the RR to know which path to send to which RR client? This is where i2rs seems to fit. If the RR was attached to a controller that had visibility into the layer 3 routing table at each RR client, that information could be used to determine which path to send where. The RR could also calculate the best path from the perspective of each RR client --but even though SPF is trivial to run, there are still problems with this solution. First, you can't run SPF for a router that's not in your flooding domain. Second, you can't take into account any local policies configured on the router you're running SPF from the perspective of. Hence --just use i2rs to peek into the RR clients local routing table, and send the client the right BGP route(s) as indicated (using add-paths to include more than one path if needed, for load sharing or the like). This would probably fit better into the BGP use cases draft, rather than the one I'm co-authoring --OTOH, I thought we were merging these two into a single use cases draft covering all the "first line" use cases i2rs would like to cover. Thoughts? :-) Russ From nitinb@juniper.net Mon Jul 15 12:31:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7F521E8133 for ; Mon, 15 Jul 2013 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BanvQZQZcQmd for ; Mon, 15 Jul 2013 12:31:34 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3021E8144 for ; Mon, 15 Jul 2013 12:31:33 -0700 (PDT) Received: from mail44-db8-R.bigfish.com (10.174.8.241) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 19:31:32 +0000 Received: from mail44-db8 (localhost [127.0.0.1]) by mail44-db8-R.bigfish.com (Postfix) with ESMTP id 9E0F628008D for ; Mon, 15 Jul 2013 19:31:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail44-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=nitinb@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail44-db8 (localhost.localdomain [127.0.0.1]) by mail44-db8 (MessageSwitch) id 137391669095586_28427; Mon, 15 Jul 2013 19:31:30 +0000 (UTC) Received: from DB8EHSMHS011.bigfish.com (unknown [10.174.8.226]) by mail44-db8.bigfish.com (Postfix) with ESMTP id 131409A0047 for ; Mon, 15 Jul 2013 19:31:30 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.53) by DB8EHSMHS011.bigfish.com (10.174.4.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 15 Jul 2013 19:31:28 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Jul 2013 12:31:26 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.123.3; Mon, 15 Jul 2013 12:31:26 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 15 Jul 2013 12:35:57 -0700 Received: from mail95-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 15 Jul 2013 19:31:25 +0000 Received: from mail95-tx2 (localhost [127.0.0.1]) by mail95-tx2-R.bigfish.com (Postfix) with ESMTP id 0F2F53400EE for ; Mon, 15 Jul 2013 19:31:25 +0000 (UTC) Received: from mail95-tx2 (localhost.localdomain [127.0.0.1]) by mail95-tx2 (MessageSwitch) id 1373916683492177_4323; Mon, 15 Jul 2013 19:31:23 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.227]) by mail95-tx2.bigfish.com (Postfix) with ESMTP id 722ED3C006F for ; Mon, 15 Jul 2013 19:31:23 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 15 Jul 2013 19:31:23 +0000 Received: from BL2PRD0510MB375.namprd05.prod.outlook.com ([169.254.1.208]) by BL2PRD0510HT003.namprd05.prod.outlook.com ([10.255.100.38]) with mapi id 14.16.0329.000; Mon, 15 Jul 2013 19:31:20 +0000 From: Nitin Bahadur To: "i2rs@ietf.org" Thread-Topic: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt Thread-Index: AQHOgZGhebqy3aEUp0GzOI/nVMQ9O5llq0wA Date: Mon, 15 Jul 2013 19:31:19 +0000 Message-ID: In-Reply-To: <20130715192914.7395.12726.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <5FBD72121908A2439184146A2925DC18@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:31:40 -0000 A new version of the RIB info model draft has been posted. =20 Notable changes include: - Addition of multicast support - Text clarifications as per received comments Thanks Nitin On 7/15/13 12:29 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-nitinb-i2rs-rib-info-model-01.txt >has been successfully submitted by Nitin Bahadur and posted to the >IETF repository. > >Filename: draft-nitinb-i2rs-rib-info-model >Revision: 01 >Title: Routing Information Base Info Model >Creation date: 2013-07-15 >Group: Individual Submission >Number of pages: 24 >URL: =20 >http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-01.tx >t >Status: =20 >http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model >Htmlized: =20 >http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-nitinb-i2rs-rib-info-model-01 > >Abstract: > Routing and routing functions in enterprise and carrier networks are > typically performed by network devices (routers and switches) using a > routing information base (RIB). Protocols and configuration push > data into the RIB and the RIB manager install state into the > hardware; for packet forwarding. This draft specifies an information > model for the RIB to enable defining a standardized data model. Such > a data model can be used to define an interface to the RIB from an > entity that may even be external to the network device. This > interface can be used to support new use-cases being defined by the > IETF I2RS WG. > > =20 > =20 > > >The IETF Secretariat > > > From maxpassion@gmail.com Mon Jul 15 20:19:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76B121E8186 for ; Mon, 15 Jul 2013 20:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwFuZERww1mY for ; Mon, 15 Jul 2013 20:19:34 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 00E1421E8177 for ; Mon, 15 Jul 2013 20:19:33 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db10so119028veb.26 for ; Mon, 15 Jul 2013 20:19:33 -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=LuA3fSrqPBLxHUEOeZib5Ipnt9U6AIcxW8iPgOFadis=; b=u6J3tyPO1lScNrytoY/pl1pQnaAGYYKtiiO2a8EBMXlrl7d62sVUErzJlewZV5pqog HE7TQM9poYryQmyG7d2Trjc/l6dcbhaDfVRvnaIGcDTIzTBVbORRWc7mx+klFnhixqfO nTU01MCXwxFyL/a/5+gYzpbjbpQW6febhG0qF6poLW5f4wfHoie4lnLqbWEL9mikHnu9 uX4sI15+BAXjj+lUNBke0ejJ9wKnmWqesg1+kjmDT5wPkRhzPz89QYbNUpDp3dyXxMWq 2eZZiyywZdKlq7tGy0a+cZFBSjM8GWf2MvyMJVdfO5F2fB7NsxHhoS6JyBLOctAvpfLh P3yA== MIME-Version: 1.0 X-Received: by 10.58.128.71 with SMTP id nm7mr13745208veb.51.1373944773010; Mon, 15 Jul 2013 20:19:33 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Mon, 15 Jul 2013 20:19:32 -0700 (PDT) In-Reply-To: <003301ce81d2$c68da550$53a8eff0$@com> References: <003301ce81d2$c68da550$53a8eff0$@com> Date: Tue, 16 Jul 2013 11:19:32 +0800 Message-ID: From: Liu Dapeng To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=047d7b60518c22edd904e19872db Subject: [i2rs] Fwd: FW: New Version Notification for draft-liu-i2rs-architecture-02.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 03:19:34 -0000 --047d7b60518c22edd904e19872db Content-Type: text/plain; charset=ISO-8859-1 Hello All, We update our previous i2rs architecture draft. Your comment and review is appreciated. Thanks, Regards, Dapeng Liu ---------- Forwarded message ---------- From: Dapeng Liu Date: 2013/7/16 Subject: FW: New Version Notification for draft-liu-i2rs-architecture-02.txt To: maxpassion@gmail.com -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, July 16, 2013 1:42 AM To: Bhumip Khasnabish; Dapeng Liu; Hui Deng Subject: New Version Notification for draft-liu-i2rs-architecture-02.txt A new version of I-D, draft-liu-i2rs-architecture-02.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Filename: draft-liu-i2rs-architecture Revision: 02 Title: Architecture Discussion of I2RS Creation date: 2013-07-15 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-liu-i2rs-architecture-02.txt Status: http://datatracker.ietf.org/doc/draft-liu-i2rs-architecture Htmlized: http://tools.ietf.org/html/draft-liu-i2rs-architecture-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-liu-i2rs-architecture-02 Abstract: This document discusses the high level architecture of I2RS. This document also provides brief descriptions on the use of virtualization and its impact on constructing chained and grouped services. We plan to include further details on virtualization, service chaining, and grouping in a future version of this draft. The IETF Secretariat -- ------ Best Regards, Dapeng Liu --047d7b60518c22edd904e19872db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,

We update our previous i2rs = architecture draft. Your comment and review is appreciated.

<= /div>
Thanks,
Regards,
Dapeng Liu=
---------- Forwarded message ----------
= From: Dapeng Liu <liudapeng@chin= amobile.com>
Date: 2013/7/16
Subject: FW: New Version Notification for draft-liu-i2rs= -architecture-02.txt
To: maxpassion@gmail.com



-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, July 16, 2013 1:42 AM
To: Bhumip Khasnabish; Dapeng Liu; Hui Deng
Subject: New Version Notification for draft-liu-i2rs-architecture-02.txt

A new version of I-D, draft-liu-i2rs-architecture-02.txt
has been successfully submitted by Dapeng Liu and posted to the IETF reposi= tory.

Filename: =A0 =A0 =A0 =A0draft-liu-i2rs-architecture
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Architecture Discussion of I2RS
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-liu-i2rs-architecture-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-liu-i2rs-architecture
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu-= i2rs-architecture-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdi= ff?url2=3Ddraft-liu-i2rs-architecture-02

Abstract:
=A0 =A0This document discusses the high level architecture of I2RS. =A0This=
=A0 =A0document also provides brief descriptions on the use of
=A0 =A0virtualization and its impact on constructing chained and grouped =A0 =A0services. =A0We plan to include further details on virtualization, =A0 =A0service chaining, and grouping in a future version of this draft.



The IETF Secretariat







--

------
Best Regard= s,
Dapeng Liu
--047d7b60518c22edd904e19872db-- From maxpassion@gmail.com Mon Jul 15 20:24:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D27221E8177 for ; Mon, 15 Jul 2013 20:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvUBxgO63GKh for ; Mon, 15 Jul 2013 20:24:26 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id ED89321E80FC for ; Mon, 15 Jul 2013 20:24:25 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so117458vcb.11 for ; Mon, 15 Jul 2013 20:24:25 -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=pUOpqGyknieE72JC2S02mtKF/lRmGIDjbpcEOUuohAI=; b=dsNvKrofoG6qkt0/wTO9rh0lJ7sPph7Rzy2tllib1eOI7NFR+s9pYfQe7a10CwcpK/ Pk/0NqUtfaUd0wSnx5PX//SpCi16vOYUQlVz3+Cr1U2fyfg0YHOp7GeeQGwdwer9w+2T 2rBtTKqxYbb5fhjTuQhHLv0jJYfdpkqG6bzg6YtVVFb+zMjoGfkzEFUZ2Zp8rBGoUxhh wGpdLkiFyCVwevnVyd6fL5fLPUmkgzwU9cBBl75H3YM9GYpRVc0ij1UxncFvjg1pCYR5 fwQIlF0muqOFK1Qp8ymMxUBuGucXul6e+m1t0L4HB2GEUpXsxeaUfihTqLa2DZxKMGhB F5MQ== MIME-Version: 1.0 X-Received: by 10.220.90.71 with SMTP id h7mr29460100vcm.16.1373945065436; Mon, 15 Jul 2013 20:24:25 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Mon, 15 Jul 2013 20:24:25 -0700 (PDT) In-Reply-To: <003101ce81d2$96b89ec0$c429dc40$@com> References: <003101ce81d2$96b89ec0$c429dc40$@com> Date: Tue, 16 Jul 2013 11:24:25 +0800 Message-ID: From: Liu Dapeng To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a8c1290fe5604e1988371 Subject: [i2rs] Fwd: FW: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 03:24:26 -0000 --047d7b3a8c1290fe5604e1988371 Content-Type: text/plain; charset=ISO-8859-1 Hello all, We submit a i2rs IPv6 use case draft. Your comment and review is appreciated. Thanks, Regards, Dapeng Liu ---------- Forwarded message ---------- From: Dapeng Liu Date: 2013/7/16 Subject: FW: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt To: maxpassion@gmail.com -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, July 16, 2013 2:20 AM To: Dapeng Liu Subject: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt A new version of I-D, draft-liu-i2rs-ipv6-use-case-00.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Filename: draft-liu-i2rs-ipv6-use-case Revision: 00 Title: I2RS use case for IPv6 transition Creation date: 2013-07-15 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-liu-i2rs-ipv6-use-case-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-i2rs-ipv6-use-case Htmlized: http://tools.ietf.org/html/draft-liu-i2rs-ipv6-use-case-00 Abstract: This document discusses the use cases of I2RS in IPv4/IPv6 transition scenario. The IETF Secretariat -- ------ Best Regards, Dapeng Liu --047d7b3a8c1290fe5604e1988371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all,

We submit a i2rs IPv6 use ca= se draft. Your comment and review is appreciated.

= Thanks,
Regards,
Dapeng Liu
---------- Forwarded message ----------
From: Dapeng Liu <liudapeng@chinamobile.com>
Date: 2013/7/16
S= ubject: FW: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.tx= t
To: maxpassion@gmail.com


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, July 16, 2013 2:20 AM
To: Dapeng Liu
Subject: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt

A new version of I-D, draft-liu-i2rs-ipv6-use-case-00.txt
has been successfully submitted by Dapeng Liu and posted to the IETF reposi= tory.

Filename: =A0 =A0 =A0 =A0draft-liu-i2rs-ipv6-use-case
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 I2RS use case for IPv6 transition
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 5
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-liu-i2rs-ipv6-use-case-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/= draft-liu-i2rs-ipv6-use-case
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu= -i2rs-ipv6-use-case-00


Abstract:
=A0 =A0This document discusses the use cases of I2RS in IPv4/IPv6 transitio= n
=A0 =A0scenario.




The IETF Secretariat







--

------
Best Regard= s,
Dapeng Liu
--047d7b3a8c1290fe5604e1988371-- From mach.chen@huawei.com Wed Jul 17 03:00:51 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86EF21F9A8F; Wed, 17 Jul 2013 03:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhe-XGGrHwGS; Wed, 17 Jul 2013 03:00:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 934E321F9A81; Wed, 17 Jul 2013 03:00:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN22972; Wed, 17 Jul 2013 10:00:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 10:59:44 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 11:00:18 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 17:59:49 +0800 From: Mach Chen To: Russ White , "i2rs@ietf.org" Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: Ac6BV9mxNi7PyssnRIGt/4lbCgtdGgBZMkLg Date: Wed, 17 Jul 2013 09:59:48 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" , "zhuyq@gsta.com" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 10:00:51 -0000 Hi Russ, Thanks for bringing up this discussion! Please see my reply inline... Best regards, Mach > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of R= uss > White > Sent: Monday, July 15, 2013 8:45 PM > To: i2rs@ietf.org > Cc: zhuyq@gsta.com > Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usec= ase as an > I2RS Use Case >=20 > Y'all: >=20 > It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase mi= ght > provide a solid use case to add to one of our use case drafts in I2RS. Th= e > basic idea is this: >=20 > Rather than advertising multiple routes using something like add-paths to > optimize traffic flow between eBGP edges, why not just have the RR advert= ise > only the route that's best from each eBGP speaker's perspective? Now, I h= ave > a long standing desire to see it implemented. OTOH, even if add-paths is > implemented, there is the issue of which set of paths to send to the RR > clients in any given situation. So I don't see > draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > add-paths, but rather a complimentary idea. I agree if the RR wants to advertise more than one routes to the clients.=20 >=20 > But how is the RR to know which path to send to which RR client? This is > where i2rs seems to fit. If the RR was attached to a controller that had > visibility into the layer 3 routing table at each RR client, that > information could be used to determine which path to send where. The RR > could also calculate the best path from the perspective of each RR client Yes, this is one possible way to achieve it. Alternate way is that the RR i= s the "controller" or part of a controller, it has not only the visibility = into the layer 3 routing table at each client, but the topology and other r= elated information of the network. Then the RR can compute a path for a spe= cific source and destination pair, just like the traffic engineering, and t= hen it advertises the relevant routes to clients though the existing route = reflection mechanisms.=20 > --but even though SPF is trivial to run, there are still problems with th= is > solution. First, you can't run SPF for a router that's not in your floodi= ng > domain. Second, you can't take into account any local policies configured= on > the router you're running SPF from the perspective of. The RR and the routers/clients do not have to be in the same flooding domai= n, the RR can establish IGP multiple adjacencies with domains (per adjacenc= y per domain) or use BGP-LS to collect the topology information. =20 Regarding to the local policies, if want the RR the consider the local poli= cies, there have to be some mechanisms to collect the local policies and ju= st configure it on the RR.=20 >=20 > Hence --just use i2rs to peek into the RR clients local routing table, an= d > send the client the right BGP route(s) as indicated (using add-paths to > include more than one path if needed, for load sharing or the like). >=20 > This would probably fit better into the BGP use cases draft, rather than = the > one I'm co-authoring --OTOH, I thought we were merging these two into a > single use cases draft covering all the "first line" use cases i2rs would > like to cover. >=20 > Thoughts? >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From maxpassion@gmail.com Fri Jul 19 02:44:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB311E80D7 for ; Fri, 19 Jul 2013 02:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g23oL+1689N for ; Fri, 19 Jul 2013 02:44:01 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE111E80D9 for ; Fri, 19 Jul 2013 02:44:01 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id m17so1385912vca.3 for ; Fri, 19 Jul 2013 02:44:00 -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=r4rGeqPflzTpyytn/LJgnyU5REjMs/6/rTE1yLx+mSc=; b=c9JoWYv/3I6H9M2tAMSyQ6C/RoW7vw3wP9pBVkAvwaqpJHq+HtyWRgFvP9pnEHoSx1 IOE2pp/oY0j4+l9xf975GunzeETFa21iynRdppUvZAUhCx3nB/7z4zHuu9l695z0u7iL SanTfdAfGCjvW5OGGmTtG6dLM/O0nQoMX4YDBi67MHEgP1v7Y6gzcU8gOq7FFWibCpaZ YlXCyfmxXh9a8rIQ88pvYK4gmqZqdOHlGs8QAC87hPxPheMEU/qh6JRRUFNf/SXc3QG8 tlUdnOlwIq3w0INNNyKE9B6s3uBftXFrg+3RrYXyd3U/P4Pn9yvKyiZn/FRheFfF18e4 FesQ== MIME-Version: 1.0 X-Received: by 10.220.164.138 with SMTP id e10mr5479262vcy.27.1374227040716; Fri, 19 Jul 2013 02:44:00 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Fri, 19 Jul 2013 02:44:00 -0700 (PDT) In-Reply-To: References: <003101ce81d2$96b89ec0$c429dc40$@com> Date: Fri, 19 Jul 2013 17:44:00 +0800 Message-ID: From: Liu Dapeng To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=001a11c1dfbc9a4d9604e1da2a16 Subject: Re: [i2rs] FW: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:44:02 -0000 --001a11c1dfbc9a4d9604e1da2a16 Content-Type: text/plain; charset=ISO-8859-1 Hi all, This draft discusses the IPv4/IPv6 transition use case of i2rs. The motivation is that i2rs can be used to help the management and trouble shooting of IPv4/IPv6 transition scenario. For example,in IPv4/IPv6 dual-stack network, the network's IPv4 and IPv6 domain normally independent from each other logically but the dual-stack router is one physical device. So the topology/routing state of the IPv4 network and IPv6 network normally need to keep consistent. With i2rs, it can discovery the inconsistent of IPv4/IPv6 domain and facilitate management and trouble shooting. I'd like to hear the group's opinion whether it is a valid use case for i2rs? Your feedback and comments are appreciated. Regards, Dapeng Liu 2013/7/16 Liu Dapeng > Hello all, > > We submit a i2rs IPv6 use case draft. Your comment and review is > appreciated. > > Thanks, > Regards, > Dapeng Liu > > ---------- Forwarded message ---------- > From: Dapeng Liu > Date: 2013/7/16 > Subject: FW: New Version Notification for > draft-liu-i2rs-ipv6-use-case-00.txt > To: maxpassion@gmail.com > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, July 16, 2013 2:20 AM > To: Dapeng Liu > Subject: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt > > > A new version of I-D, draft-liu-i2rs-ipv6-use-case-00.txt > has been successfully submitted by Dapeng Liu and posted to the IETF > repository. > > Filename: draft-liu-i2rs-ipv6-use-case > Revision: 00 > Title: I2RS use case for IPv6 transition > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 5 > URL: > http://www.ietf.org/internet-drafts/draft-liu-i2rs-ipv6-use-case-00.txt > Status: > http://datatracker.ietf.org/doc/draft-liu-i2rs-ipv6-use-case > Htmlized: > http://tools.ietf.org/html/draft-liu-i2rs-ipv6-use-case-00 > > > Abstract: > This document discusses the use cases of I2RS in IPv4/IPv6 transition > scenario. > > > > > The IETF Secretariat > > > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > -- ------ Best Regards, Dapeng Liu --001a11c1dfbc9a4d9604e1da2a16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

This draft discusse= s the IPv4/IPv6 transition use case of i2rs. The motivation is that i2rs ca= n be used to help the management and trouble shooting of IPv4/IPv6 transiti= on scenario. For example,in IPv4/IPv6 dual-stack network, the network's= IPv4 and IPv6 domain normally independent from each other logically but th= e dual-stack router is one physical device. So the topology/routing state o= f the IPv4 network and IPv6 network normally need to keep consistent. With = i2rs, it can discovery the=A0inconsistent of IPv4/IPv6 domain and facilitat= e management and trouble shooting. I'd like to hear the group's opi= nion whether it is a valid use case for i2rs? Your feedback and comments ar= e appreciated.

Regards,
Dapeng Liu

2013/7/16 Liu Dapeng = <maxpassion@gm= ail.com>
Hello all,
=A0
We submit a = i2rs IPv6 use case draft. Your comment and review is appreciated.

Thanks,
Regards,
Dapeng Liu

---------- Forwarded message ----------
From: Dapeng Liu <liudapeng@chinamobile.com>
Da= te: 2013/7/16
Subject: FW: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.t= xt
To: maxpassion@gm= ail.com



-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Tuesday, July 16, 2013 2:20 AM
To: Dapeng Liu
Subject: New Version Notification for draft-liu-i2rs-ipv6-use-case-00.txt

A new version of I-D, draft-liu-i2rs-ipv6-use-case-00.txt
has been successfully submitted by Dapeng Liu and posted to the IETF reposi= tory.

Filename: =A0 =A0 =A0 =A0draft-liu-i2rs-ipv6-use-case
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 I2RS use case for IPv6 transition
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 5
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org= /internet-drafts/draft-liu-i2rs-ipv6-use-case-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/= draft-liu-i2rs-ipv6-use-case
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu= -i2rs-ipv6-use-case-00


Abstract:
=A0 =A0This document discusses the use cases of I2RS in IPv4/IPv6 transitio= n
=A0 =A0scenario.




The IETF Secretariat







--

------
Best Regards,
Dapeng Liu



--

------Best Regards,
Dapeng Liu
--001a11c1dfbc9a4d9604e1da2a16-- From rraszuk@gmail.com Fri Jul 19 06:56:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D929021E80C0; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6jGLZO8UgdK; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 28EF811E8139; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so9450036iec.19 for ; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C5hLGGo5gIuRfINfFi6LdkifxhnqHhVBTzAIDFciXFs=; b=cMivnBjVuA2ruciKE/w+qHjQiPVj/M22m1kz6fc8LfIjdb7+TYVwxwXNN4flaoDZcj smTYBwkOPWksJBUHdzwnqd8tArw26Y7tVFt3eKMPX7t/sdLhAu2BmDyO0emMkxtPfYDS YDMhDWnm4e6no6ZqpDdUtq/AVBl5bWZzgz/kR55sKSW9wAXCR1Vn19oVG+L/RRY2Wujz 0+gIGGaOPJYmtrPFZzr6fxCWwi+CMTwYKs5b2ife0QJ0VIbBS5FowrWYIxDs/qWj6eej 0DYTpDRo9KGF1M3DMB0kTX4oRO52v+gjOPrO/1DH8EDb61Hwqwg/p9D60bevUJeTwCkN V8og== MIME-Version: 1.0 X-Received: by 10.43.88.3 with SMTP id ay3mr10238335icc.61.1374242176055; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Fri, 19 Jul 2013 15:56:16 +0200 X-Google-Sender-Auth: -Avsn4XceTy-nDjLOtLcdEKcQA0 Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "zhuyq@gsta.com" , "idr@ietf.org" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:56:25 -0000 Hi Mach, I have read your draft. I find nothing there which is not already solved by IDR WG document http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 The status of this WG document is pending two implementations. If you see anything technically missing in this draft possibly along with draft-varlashkin-bgp-nh-cost-02 let's discuss. Best regards, R. On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote: > Hi Russ, > > Thanks for bringing up this discussion! > > Please see my reply inline... > > Best regards, > Mach > >> -----Original Message----- >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of = Russ >> White >> Sent: Monday, July 15, 2013 8:45 PM >> To: i2rs@ietf.org >> Cc: zhuyq@gsta.com >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-use= case as an >> I2RS Use Case >> >> Y'all: >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase m= ight >> provide a solid use case to add to one of our use case drafts in I2RS. T= he >> basic idea is this: >> >> Rather than advertising multiple routes using something like add-paths t= o >> optimize traffic flow between eBGP edges, why not just have the RR adver= tise >> only the route that's best from each eBGP speaker's perspective? Now, I = have >> a long standing desire to see it implemented. OTOH, even if add-paths is >> implemented, there is the issue of which set of paths to send to the RR >> clients in any given situation. So I don't see >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to >> add-paths, but rather a complimentary idea. > > I agree if the RR wants to advertise more than one routes to the clients. > >> >> But how is the RR to know which path to send to which RR client? This is >> where i2rs seems to fit. If the RR was attached to a controller that had >> visibility into the layer 3 routing table at each RR client, that >> information could be used to determine which path to send where. The RR >> could also calculate the best path from the perspective of each RR clien= t > > Yes, this is one possible way to achieve it. Alternate way is that the RR= is the "controller" or part of a controller, it has not only the visibilit= y into the layer 3 routing table at each client, but the topology and other= related information of the network. Then the RR can compute a path for a s= pecific source and destination pair, just like the traffic engineering, and= then it advertises the relevant routes to clients though the existing rout= e reflection mechanisms. > >> --but even though SPF is trivial to run, there are still problems with t= his >> solution. First, you can't run SPF for a router that's not in your flood= ing >> domain. Second, you can't take into account any local policies configure= d on >> the router you're running SPF from the perspective of. > > The RR and the routers/clients do not have to be in the same flooding dom= ain, the RR can establish IGP multiple adjacencies with domains (per adjace= ncy per domain) or use BGP-LS to collect the topology information. > > Regarding to the local policies, if want the RR the consider the local po= licies, there have to be some mechanisms to collect the local policies and = just configure it on the RR. > >> >> Hence --just use i2rs to peek into the RR clients local routing table, a= nd >> send the client the right BGP route(s) as indicated (using add-paths to >> include more than one path if needed, for load sharing or the like). >> >> This would probably fit better into the BGP use cases draft, rather than= the >> one I'm co-authoring --OTOH, I thought we were merging these two into a >> single use cases draft covering all the "first line" use cases i2rs woul= d >> like to cover. >> >> Thoughts? >> >> :-) >> >> Russ >> >> _______________________________________________ >> 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 mach.chen@huawei.com Sun Jul 21 23:21:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6827421E804D; Sun, 21 Jul 2013 23:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co93qCXnyxzf; Sun, 21 Jul 2013 23:21:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3083F21E8064; Sun, 21 Jul 2013 23:21:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ82456; Mon, 22 Jul 2013 06:20:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 07:19:52 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 07:20:42 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 14:20:37 +0800 From: Mach Chen To: Robert Raszuk Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: AQHOhIe/1DV2tpe+J0edLtmbNRgGA5lwODAQ Date: Mon, 22 Jul 2013 06:20:36 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Russ White , "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 06:21:23 -0000 Hi Robert, Many thanks for spending time to read the draft and your comments! If I understand the ORR and draft-varlashkin correctly, they both try to ca= lculate (from the client's perspective) the best route that is from the cli= ent to destination/nexthop.=20 But, just as Russ summarized, the use cases introduced in this draft (use c= ase 1 and 2) require to calculate the route from the eBGP peer's perspectiv= e, hence to optimize the traffic flow between eBGP peers (between MANs). Th= is seems not be solved by the ORR and draft-varlashkin.=20 Best regards, Mach > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, July 19, 2013 9:56 PM > To: Mach Chen > Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com > Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase > as an I2RS Use Case >=20 > Hi Mach, >=20 > I have read your draft. I find nothing there which is not already > solved by IDR WG document > http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 >=20 > The status of this WG document is pending two implementations. >=20 > If you see anything technically missing in this draft possibly along > with draft-varlashkin-bgp-nh-cost-02 let's discuss. >=20 > Best regards, > R. >=20 >=20 > On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote: > > Hi Russ, > > > > Thanks for bringing up this discussion! > > > > Please see my reply inline... > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf O= f Russ > >> White > >> Sent: Monday, July 15, 2013 8:45 PM > >> To: i2rs@ietf.org > >> Cc: zhuyq@gsta.com > >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-u= secase as > an > >> I2RS Use Case > >> > >> Y'all: > >> > >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase= might > >> provide a solid use case to add to one of our use case drafts in I2RS.= The > >> basic idea is this: > >> > >> Rather than advertising multiple routes using something like add-paths= to > >> optimize traffic flow between eBGP edges, why not just have the RR > advertise > >> only the route that's best from each eBGP speaker's perspective? Now, = I have > >> a long standing desire to see it implemented. OTOH, even if add-paths = is > >> implemented, there is the issue of which set of paths to send to the R= R > >> clients in any given situation. So I don't see > >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > >> add-paths, but rather a complimentary idea. > > > > I agree if the RR wants to advertise more than one routes to the client= s. > > > >> > >> But how is the RR to know which path to send to which RR client? This = is > >> where i2rs seems to fit. If the RR was attached to a controller that h= ad > >> visibility into the layer 3 routing table at each RR client, that > >> information could be used to determine which path to send where. The R= R > >> could also calculate the best path from the perspective of each RR cli= ent > > > > Yes, this is one possible way to achieve it. Alternate way is that the = RR is the > "controller" or part of a controller, it has not only the visibility into= the layer 3 > routing table at each client, but the topology and other related informat= ion of the > network. Then the RR can compute a path for a specific source and destina= tion > pair, just like the traffic engineering, and then it advertises the relev= ant routes to > clients though the existing route reflection mechanisms. > > > >> --but even though SPF is trivial to run, there are still problems with= this > >> solution. First, you can't run SPF for a router that's not in your flo= oding > >> domain. Second, you can't take into account any local policies configu= red on > >> the router you're running SPF from the perspective of. > > > > The RR and the routers/clients do not have to be in the same flooding d= omain, > the RR can establish IGP multiple adjacencies with domains (per adjacency= per > domain) or use BGP-LS to collect the topology information. > > > > Regarding to the local policies, if want the RR the consider the local = policies, > there have to be some mechanisms to collect the local policies and just c= onfigure > it on the RR. > > > >> > >> Hence --just use i2rs to peek into the RR clients local routing table,= and > >> send the client the right BGP route(s) as indicated (using add-paths t= o > >> include more than one path if needed, for load sharing or the like). > >> > >> This would probably fit better into the BGP use cases draft, rather th= an the > >> one I'm co-authoring --OTOH, I thought we were merging these two into = a > >> single use cases draft covering all the "first line" use cases i2rs wo= uld > >> like to cover. > >> > >> Thoughts? > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> 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 rraszuk@gmail.com Mon Jul 22 03:48:27 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9270E11E811D; Mon, 22 Jul 2013 03:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejwG1HF78eiR; Mon, 22 Jul 2013 03:48:10 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2011E812D; Mon, 22 Jul 2013 03:42:18 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so14765731iea.18 for ; Mon, 22 Jul 2013 03:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H0krPrIBJfdBepywKah1yaJhVeEXVL+MsUVQ3TfbNOU=; b=c+Aa71LN3kw/9PjmcHej9dA1ntT6mQCOaLQs98lz3HWop+1Buj5GeWH7rGRXZJG5yg itEcCGF1NBqmMILoRW6CjP+SkO0puF9tiUlvSqq93jiIw1s7IIb1q7Rk06iq1Ql7skKO G1YuZ7x4AmJkpKawWgttGzajTky5tMv1DmCpvRgBcD85G657aLR2G7S/k987YletLg5W viLLIHzzQkKb5ovCOX5ozgZAZUtZBcldrP02E0Vabj0VhheL2EznOG45F2KlWKCoH50s isx828wF/9l+1AljY6RQoBacuc8QNcOS1N/QzhpOliAEF2yYuv8zcS6HPgjRTzZUXY4W dEsA== MIME-Version: 1.0 X-Received: by 10.42.43.202 with SMTP id y10mr16706932ice.28.1374489326773; Mon, 22 Jul 2013 03:35:26 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Mon, 22 Jul 2013 03:35:26 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Mon, 22 Jul 2013 12:35:26 +0200 X-Google-Sender-Auth: yONinWFOhYHrchY-rIR-l6NzfI4 Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 10:48:27 -0000 Hello Mach, > But, just as Russ summarized, the use cases introduced in this draft (use= case 1 and 2) require to > calculate the route from the eBGP peer's perspective, hence to optimize t= he traffic flow between > eBGP peers (between MANs). This seems not be solved by the ORR and draft-= varlashkin. In the route reflection based networks eBGP peers are also RR clients. The ORR draft allows you to choose the correct exit path for given prefix based on set of criteria. Such criteria can be IGP metric based or any other set of constrain as determined by the operator. Now if your requirement is: The requirement would like this: the traffic between MAN1 and MAN2 is required to follow the path: E-A-B; and the traffic between MAN1 and MAN3 is required to follow the path: E-D-C. then the correct way to solve it is to use either IGP Segment Routing, MPLS-TE or BGP Vector Routing proposals. I am of the strong opinion that the solution proposed in your draft to steer traffic via customized IBGP P router's programming with hop by hop different next hop setting is very problematic. BGP is not a right protocol for IGP traffic steering. In your example: For example, for a path from Source 1 (S1) to Destination 1 (D1), if the computed path is: S1-A-B-C-D1, then the RR will distribute a route (D1) to C with the nexthop set to D1; a route (D1) to B with the nexthop set to C, and a route (D1) to A with the nexthop set to B, and finally the route (D1) will be distributed to S1 by A. you only list steady state. At any IGP P node failure case you are to again depend on your RR reprogramming selective nodes to stop traffic drops and repair the intra-domain path. Btw the difference of the above as compared with BGP Vector Routing proposal http://goo.gl/qutBU is that upon the failure of any Vector Node (signaled via the IGP) such node would not be considered and next Vector Node (or final next hop) would be used as the next encapsulation point. Your proposal does not seem to have such local path repair ability. Btw this is typical illustration where number of "SDN" folks who push for massive centralization of everything do not realize a benefit of having in each domain robust IGP transport and a BGP used as an service overlay on top of it. Best regards, R. > On Mon, Jul 22, 2013 at 8:20 AM, Mach Chen wrote: > > Hi Robert, > > Many thanks for spending time to read the draft and your comments! > > If I understand the ORR and draft-varlashkin correctly, they both try to = calculate (from the client's perspective) the best route that is from the c= lient to destination/nexthop. > > But, just as Russ summarized, the use cases introduced in this draft (use= case 1 and 2) require to calculate the route from the eBGP peer's perspect= ive, hence to optimize the traffic flow between eBGP peers (between MANs). = This seems not be solved by the ORR and draft-varlashkin. > > Best regards, > Mach > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, July 19, 2013 9:56 PM >> To: Mach Chen >> Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com >> Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering= -usecase >> as an I2RS Use Case >> >> Hi Mach, >> >> I have read your draft. I find nothing there which is not already >> solved by IDR WG document >> http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-0= 5 >> >> The status of this WG document is pending two implementations. >> >> If you see anything technically missing in this draft possibly along >> with draft-varlashkin-bgp-nh-cost-02 let's discuss. >> >> Best regards, >> R. >> >> >> On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote= : >> > Hi Russ, >> > >> > Thanks for bringing up this discussion! >> > >> > Please see my reply inline... >> > >> > Best regards, >> > Mach >> > >> >> -----Original Message----- >> >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf = Of Russ >> >> White >> >> Sent: Monday, July 15, 2013 8:45 PM >> >> To: i2rs@ietf.org >> >> Cc: zhuyq@gsta.com >> >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase as >> an >> >> I2RS Use Case >> >> >> >> Y'all: >> >> >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecas= e might >> >> provide a solid use case to add to one of our use case drafts in I2RS= . The >> >> basic idea is this: >> >> >> >> Rather than advertising multiple routes using something like add-path= s to >> >> optimize traffic flow between eBGP edges, why not just have the RR >> advertise >> >> only the route that's best from each eBGP speaker's perspective? Now,= I have >> >> a long standing desire to see it implemented. OTOH, even if add-paths= is >> >> implemented, there is the issue of which set of paths to send to the = RR >> >> clients in any given situation. So I don't see >> >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to >> >> add-paths, but rather a complimentary idea. >> > >> > I agree if the RR wants to advertise more than one routes to the clien= ts. >> > >> >> >> >> But how is the RR to know which path to send to which RR client? This= is >> >> where i2rs seems to fit. If the RR was attached to a controller that = had >> >> visibility into the layer 3 routing table at each RR client, that >> >> information could be used to determine which path to send where. The = RR >> >> could also calculate the best path from the perspective of each RR cl= ient >> > >> > Yes, this is one possible way to achieve it. Alternate way is that the= RR is the >> "controller" or part of a controller, it has not only the visibility int= o the layer 3 >> routing table at each client, but the topology and other related informa= tion of the >> network. Then the RR can compute a path for a specific source and destin= ation >> pair, just like the traffic engineering, and then it advertises the rele= vant routes to >> clients though the existing route reflection mechanisms. >> > >> >> --but even though SPF is trivial to run, there are still problems wit= h this >> >> solution. First, you can't run SPF for a router that's not in your fl= ooding >> >> domain. Second, you can't take into account any local policies config= ured on >> >> the router you're running SPF from the perspective of. >> > >> > The RR and the routers/clients do not have to be in the same flooding = domain, >> the RR can establish IGP multiple adjacencies with domains (per adjacenc= y per >> domain) or use BGP-LS to collect the topology information. >> > >> > Regarding to the local policies, if want the RR the consider the local= policies, >> there have to be some mechanisms to collect the local policies and just = configure >> it on the RR. >> > >> >> >> >> Hence --just use i2rs to peek into the RR clients local routing table= , and >> >> send the client the right BGP route(s) as indicated (using add-paths = to >> >> include more than one path if needed, for load sharing or the like). >> >> >> >> This would probably fit better into the BGP use cases draft, rather t= han the >> >> one I'm co-authoring --OTOH, I thought we were merging these two into= a >> >> single use cases draft covering all the "first line" use cases i2rs w= ould >> >> like to cover. >> >> >> >> Thoughts? >> >> >> >> :-) >> >> >> >> Russ >> >> >> >> _______________________________________________ >> >> 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 mach.chen@huawei.com Tue Jul 23 02:13:51 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68B811E8103; Tue, 23 Jul 2013 02:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGqxae0AQcEI; Tue, 23 Jul 2013 02:13:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 130D811E8155; Tue, 23 Jul 2013 02:13:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR95769; Tue, 23 Jul 2013 09:13:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 10:13:29 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 10:13:38 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 17:12:23 +0800 From: Mach Chen To: Robert Raszuk Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: AQHOhIe/1DV2tpe+J0edLtmbNRgGA5lwODAQ///G/wCAAe6VIA== Date: Tue, 23 Jul 2013 09:12:22 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Russ White , "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 09:13:52 -0000 Hi Robert, Please see my reply inline... > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, July 22, 2013 6:35 PM > To: Mach Chen > Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com; wangsb > Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase > as an I2RS Use Case >=20 > Hello Mach, >=20 > > But, just as Russ summarized, the use cases introduced in this draft (u= se case 1 > and 2) require to > > calculate the route from the eBGP peer's perspective, hence to optimize= the > traffic flow between > > eBGP peers (between MANs). This seems not be solved by the ORR and > draft-varlashkin. >=20 >=20 > In the route reflection based networks eBGP peers are also RR clients. > The ORR draft allows you to choose the correct exit path for given > prefix based on set of criteria. Such criteria can be IGP metric based > or any other set of constrain as determined by the operator. Here the eBGP peers that I referred to are the eBGP speakers residing in ot= her AS (for example, the eBGP speakers in the MANs other than in the Core n= etwork). So, these eBGP speaker should not be the clients of the RR.=20 >=20 > Now if your requirement is: >=20 > The requirement > would like this: the traffic between MAN1 and MAN2 is required to > follow the path: E-A-B; and the traffic between MAN1 and MAN3 is > required to follow the path: E-D-C. >=20 > then the correct way to solve it is to use either IGP Segment Routing, > MPLS-TE or BGP Vector Routing proposals. You listed solutions are alternative ways to satisfy the above requirement,= we had considered and discussed these potential solutions with some custom= ers. Since these solutions will require either large network update(e.g., S= R) or to totally change to a new deployment solution (e.g, MPLS-TE). To dep= loy these solutions to solve the above issue is not practice, at least for = now or in near term.=20 The idea of the RRTS proposed in the draft is try to avoid large network up= date or bringing significant new solution to the product network, with the = idea of RRTS, most of the devices are not necessary to be updated.=20 >=20 > I am of the strong opinion that the solution proposed in your draft to > steer traffic via customized IBGP P router's programming with hop by > hop different next hop setting is very problematic. BGP is not a right > protocol for IGP traffic steering. In your example: >=20 > For example, for a path from Source 1 (S1) to Destination 1 (D1), if > the computed path is: S1-A-B-C-D1, then the RR will distribute a > route (D1) to C with the nexthop set to D1; a route (D1) to B with > the nexthop set to C, and a route (D1) to A with the nexthop set to > B, and finally the route (D1) will be distributed to S1 by A. >=20 > you only list steady state. At any IGP P node failure case you are to > again depend on your RR reprogramming selective nodes to stop traffic > drops and repair the intra-domain path. The concept of RRTS is similar to MPLS-TE, the path is an End-2-End path, t= he RR is responsible for path calculation and distribute the routes to rele= vant routers. The different is that MPLS-TE uses MPLS label to direct forwa= rding, RRTS uses IP routes to direct forwarding. We just leverage the BGP r= oute reflection mechanism to achieve this. So, for the failure case, RRTS also needs to calculate and "install" backup= path/routes, it also need do RR or FRR as well if needed.=20 >=20 > Btw the difference of the above as compared with BGP Vector Routing > proposal http://goo.gl/qutBU is that upon the failure of any Vector > Node (signaled via the IGP) such node would not be considered and next > Vector Node (or final next hop) would be used as the next > encapsulation point. Your proposal does not seem to have such local > path repair ability. Thanks for pointing out this, I have not read it and will read it later. >=20 > Btw this is typical illustration where number of "SDN" folks who push > for massive centralization of everything do not realize a benefit of > having in each domain robust IGP transport and a BGP used as an > service overlay on top of it. I know what you mean, and I also agree with you that it's not necessary to = centralize everything.=20 The RRTS idea does not intend to control everything, and it is not designed= for any networks, it tries to solve the use cases introduced in the draft = without large network updates.=20 Since the existing tools are limited, especially for the pure IP forwarding= network, it seems this may be the only way to control the forwarding path = in an explicit way.=20 In some customer's network, the IP Core network is not so dynamical as imag= ined. And furthermore, they may think it's better that the core network sho= uld be relatively static and controllable, hence they could conduct the tra= ffic easier. =20 Best regards, Mach >=20 > Best regards, > R. >=20 >=20 > > On Mon, Jul 22, 2013 at 8:20 AM, Mach Chen > wrote: > > > > Hi Robert, > > > > Many thanks for spending time to read the draft and your comments! > > > > If I understand the ORR and draft-varlashkin correctly, they both try t= o calculate > (from the client's perspective) the best route that is from the client to > destination/nexthop. > > > > But, just as Russ summarized, the use cases introduced in this draft (u= se case 1 > and 2) require to calculate the route from the eBGP peer's perspective, h= ence to > optimize the traffic flow between eBGP peers (between MANs). This seems n= ot > be solved by the ORR and draft-varlashkin. > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > >> Raszuk > >> Sent: Friday, July 19, 2013 9:56 PM > >> To: Mach Chen > >> Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com > >> Subject: Re: [i2rs] Thoughts on > draft-chen-idr-rr-based-traffic-steering-usecase > >> as an I2RS Use Case > >> > >> Hi Mach, > >> > >> I have read your draft. I find nothing there which is not already > >> solved by IDR WG document > >> http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection= -05 > >> > >> The status of this WG document is pending two implementations. > >> > >> If you see anything technically missing in this draft possibly along > >> with draft-varlashkin-bgp-nh-cost-02 let's discuss. > >> > >> Best regards, > >> R. > >> > >> > >> On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen > wrote: > >> > Hi Russ, > >> > > >> > Thanks for bringing up this discussion! > >> > > >> > Please see my reply inline... > >> > > >> > Best regards, > >> > Mach > >> > > >> >> -----Original Message----- > >> >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behal= f Of > Russ > >> >> White > >> >> Sent: Monday, July 15, 2013 8:45 PM > >> >> To: i2rs@ietf.org > >> >> Cc: zhuyq@gsta.com > >> >> Subject: [i2rs] Thoughts on > draft-chen-idr-rr-based-traffic-steering-usecase as > >> an > >> >> I2RS Use Case > >> >> > >> >> Y'all: > >> >> > >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usec= ase > might > >> >> provide a solid use case to add to one of our use case drafts in I2= RS. The > >> >> basic idea is this: > >> >> > >> >> Rather than advertising multiple routes using something like add-pa= ths to > >> >> optimize traffic flow between eBGP edges, why not just have the RR > >> advertise > >> >> only the route that's best from each eBGP speaker's perspective? No= w, I > have > >> >> a long standing desire to see it implemented. OTOH, even if add-pat= hs is > >> >> implemented, there is the issue of which set of paths to send to th= e RR > >> >> clients in any given situation. So I don't see > >> >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > >> >> add-paths, but rather a complimentary idea. > >> > > >> > I agree if the RR wants to advertise more than one routes to the cli= ents. > >> > > >> >> > >> >> But how is the RR to know which path to send to which RR client? Th= is is > >> >> where i2rs seems to fit. If the RR was attached to a controller tha= t had > >> >> visibility into the layer 3 routing table at each RR client, that > >> >> information could be used to determine which path to send where. Th= e RR > >> >> could also calculate the best path from the perspective of each RR = client > >> > > >> > Yes, this is one possible way to achieve it. Alternate way is that t= he RR is the > >> "controller" or part of a controller, it has not only the visibility i= nto the layer 3 > >> routing table at each client, but the topology and other related infor= mation of > the > >> network. Then the RR can compute a path for a specific source and > destination > >> pair, just like the traffic engineering, and then it advertises the re= levant routes > to > >> clients though the existing route reflection mechanisms. > >> > > >> >> --but even though SPF is trivial to run, there are still problems w= ith this > >> >> solution. First, you can't run SPF for a router that's not in your = flooding > >> >> domain. Second, you can't take into account any local policies conf= igured > on > >> >> the router you're running SPF from the perspective of. > >> > > >> > The RR and the routers/clients do not have to be in the same floodin= g > domain, > >> the RR can establish IGP multiple adjacencies with domains (per adjace= ncy per > >> domain) or use BGP-LS to collect the topology information. > >> > > >> > Regarding to the local policies, if want the RR the consider the loc= al policies, > >> there have to be some mechanisms to collect the local policies and jus= t > configure > >> it on the RR. > >> > > >> >> > >> >> Hence --just use i2rs to peek into the RR clients local routing tab= le, and > >> >> send the client the right BGP route(s) as indicated (using add-path= s to > >> >> include more than one path if needed, for load sharing or the like)= . > >> >> > >> >> This would probably fit better into the BGP use cases draft, rather= than the > >> >> one I'm co-authoring --OTOH, I thought we were merging these two in= to a > >> >> single use cases draft covering all the "first line" use cases i2rs= would > >> >> like to cover. > >> >> > >> >> Thoughts? > >> >> > >> >> :-) > >> >> > >> >> Russ > >> >> > >> >> _______________________________________________ > >> >> 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 rraszuk@gmail.com Tue Jul 23 04:28:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C868211E8218; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePQYFyb4iHi5; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3081211E8204; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so9780639obb.8 for ; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/bGEiZtAxUtbqufCAg2WkA3Dgzck/ZwpZtBEVk9bRQw=; b=RkR++zFGAUGrJbDyZo6XagTw0bjWXXadEekLdt7zoqXiXy6BKH1OFBBtIcQsOnz+hw Q9fd8enr7OaoFmPqEy30+jUtUoJ2q1gLpBL+f9lop9OHuN6uA6I6cl3gWvQ9noIoTT2D +F0kWuXrQw4y9WOlNNIAeDtZAZsMUrEiDXRdmVRPxfDlv+tfqGldsGEvCu5hIUY0GnLE UtXozlh1oFx9so5RD3YSVuBFainHdcjlXNxXLcLf2xNU82nPnHNZmU6Bp8ACA8b7ntu9 EiBWaw9P4SywS8AAyMvwrEMvSQwnrVrRQEsmPrPmtfESq2HEK9TqL5hSNmG60/Bco9pc +UIA== MIME-Version: 1.0 X-Received: by 10.50.107.103 with SMTP id hb7mr21423260igb.25.1374578913677; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Tue, 23 Jul 2013 13:28:33 +0200 X-Google-Sender-Auth: SazOe9rc9nrP20rezTpVJT0kS1A Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russ White , "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 11:28:34 -0000 Hi Mach, > The concept of RRTS is similar to MPLS-TE, the path is an End-2-End path,= the RR is responsible for path calculation and distribute the routes to re= levant routers. The different is that MPLS-TE uses MPLS label to direct for= warding, RRTS uses IP routes to direct forwarding. We just leverage the BGP= route reflection mechanism to achieve this. > > So, for the failure case, RRTS also needs to calculate and "install" back= up path/routes, it also need do RR or FRR as well if needed. I am afraid that maybe I was not clear. I would like to observe that there is fundamental difference between RRTS and MPLS-TE or any other IGP centric traffic steering solutions. The former works on the basis of all BGP routes (could be millions) while the latter works on the basis of just proper steering via IGP to BGP next hops. Hence the latter allows indirection while the former does not. For me this is the most significant difference of both paradigms. Best regards, R. From akatlas@gmail.com Wed Jul 24 14:52:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828511E8147 for ; Wed, 24 Jul 2013 14:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIm8jv2AgziZ for ; Wed, 24 Jul 2013 14:52:11 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7985B11E81DD for ; Wed, 24 Jul 2013 14:52:06 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so2434933oah.10 for ; Wed, 24 Jul 2013 14:52:04 -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=71y6lWisns5Mx1CTFsdeK8nBS6BWuy1Gb0ZnKR9KvLw=; b=ZB64oZ4stcLIXmkurpQf9eVn0Tuxmswdjr6cLdI61/muulFMBSz/bifGnb0o3s7MMq NkYO1VSjR5NWynCQGZAdWOyPJYmBDLM1j6/kodWp88jS+NCRhZsz0zgWATKKJkG4fd/b /6a0QUPSgCa1vxMRlE2S4o501zwydQ88ehL/V4b4NPGbtNKZizUfNpdTnFTFvlsGY/ZX vZHZeXkcwZjGdXEtHEZy9SSffoEdZUReIx9L5p2HnZn6tS6qS7+lt11DTAmvp3clRlR6 0GDuJMk5ri+Ee40KqrNl03QxBbcIH9leUtk5tISR9Z8A4q4kAGYOux7mCnuGCJygpC1Y xy6Q== MIME-Version: 1.0 X-Received: by 10.42.80.9 with SMTP id t9mr20233096ick.14.1374702724331; Wed, 24 Jul 2013 14:52:04 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 14:52:04 -0700 (PDT) Date: Wed, 24 Jul 2013 17:52:04 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e52cf8e42ba04e248ebf5 Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:52:17 -0000 --20cf300e52cf8e42ba04e248ebf5 Content-Type: text/plain; charset=ISO-8859-1 Please review draft-atlas-i2rs-architecture-01 and comment on whether it should be adopted by I2RS. Detailed technical conversation is also most welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --20cf300e52cf8e42ba04e248ebf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please review draft-atlas-i2rs-architecture-01 and comment= on whether it should be adopted by I2RS. =A0Detailed technical conversatio= n is also most welcome.

Authors: Are you aware of any IPR that appli= es to draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for m= ore details).

This WG call for adoption will complete on August 12.

Thanks,Alia
--20cf300e52cf8e42ba04e248ebf5-- From akatlas@gmail.com Wed Jul 24 14:53:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B9611E8134 for ; Wed, 24 Jul 2013 14:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwt8so++mNDn for ; Wed, 24 Jul 2013 14:53:16 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6924211E80E1 for ; Wed, 24 Jul 2013 14:53:16 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so14548374obb.28 for ; Wed, 24 Jul 2013 14:53:15 -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=IXX8PSWBXqnosbwZ/At59n04kw0JRi956fBYk7ci/ao=; b=QwVWJ+dFECyFZJdoZk3eE+QNhyXg+vtoYM5+acfRUKas1wAa7a5gD9OB7xghKLchRk c/pIOKfBOpl20gAEcgLMTmg428vpDDhuJJr1VLKz2QhkHEEdkxErC5xTaHUxUPl6nYH5 Axd8av4dBqrA5g3+hZOCcDraxSdoJoemyFnXaZs9eDeC/mSUxIcptWvgLJocNGyNrtmP u/DR5hPBhcyx/f/NT+EVQnUXysXv2GPVnnTzYo32G6d0zHL2nD/apmcARYLE5zkLQMrh uL9GgDjEaclLSsUjhHS5grec8jj1I1M2TzAabOVi1rQ/CPeRYqCKy1qlZ8qeHoJG9093 1xvA== MIME-Version: 1.0 X-Received: by 10.42.80.9 with SMTP id t9mr20233484ick.14.1374702794932; Wed, 24 Jul 2013 14:53:14 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 14:53:14 -0700 (PDT) Date: Wed, 24 Jul 2013 17:53:14 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e52cfc38dd504e248ef8f Subject: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:53:16 -0000 --20cf300e52cfc38dd504e248ef8f Content-Type: text/plain; charset=ISO-8859-1 Please review draft-atlas-i2rs-problem-statement-01 and comment on whether it should be adopted by I2RS. Detailed technical conversation is also most welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --20cf300e52cfc38dd504e248ef8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please review draft-atlas-i2rs-problem-statement-01 and co= mment on whether it should be adopted by I2RS. =A0Detailed technical conver= sation is also most welcome.

Authors: Are you aware of any IPR that = applies to draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and = 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,Alia
--20cf300e52cfc38dd504e248ef8f-- From akatlas@gmail.com Wed Jul 24 14:55:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827211E8145 for ; Wed, 24 Jul 2013 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqyxgr4c34ao for ; Wed, 24 Jul 2013 14:55:16 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 628A411E8141 for ; Wed, 24 Jul 2013 14:55:16 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so2405180oag.18 for ; Wed, 24 Jul 2013 14:55:16 -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=pxJNjizcYE8D5gMmMOOMygD1r83TrMbLQgemfxcRF/I=; b=vg3b6SxBZU6aDDUWCcgkS20eYan8UOJv+d10HXSciPfdcAXxdiSxjK1TjDd3D7OQGY 0aD0NOrzTSmBTIPl/DtSSCwiGBgk+GOPG2HIsAdBD3vESIWQWQpTQboegSiiZKaB+pfU JjgljOyZfdLU0fWZNR2J9HIywJnbCpaiiNGFQ+8ogSmYykmijld68GQrEY8v+Uu76qHS 8ZxCe+znC99PKCbGy2LCj4voEZw4y5f9UWBiW9j3zOYg4WStxzb6lZjnhacfIR3dsQse FT/fmwFb8K1SY2tZ9XVHc2Ou2H+tLOJUZRN3Fj2EfvbojRAveLG+ofaJaoLsXGng89E/ tolg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pxJNjizcYE8D5gMmMOOMygD1r83TrMbLQgemfxcRF/I=; b=I/wFc4om7GjN+kJCT0HZnAahqxbz7HEskpQ2hgh74MjsZcpIxV+enrVIKS1YL6NcmZ 1u8/mHoGzRUng3wL8nOkbeZYstIBK6kwHG3FM4kzfvIqbalkYygNnMfuR7rQF9x+PlbJ GLmbl7hhkE4B6+HmHgSTL0h4s3l+S1+RKtvVgCo6RSrKIhzLdDZdt/hYLnxd6f9VezJ9 WOaQC3q8TGn/GVcgvJyrJ/YqyZyXTs/7MC95LsDhziFy7NaX/F3uwbSUPwIyg+Swl16I On//d6ydgWjmDxQY4IhBTnUK7bp1Nc4fysWceMzx5SA5nm+TkRfI7L85etdomGDvWcDj N2XQ== MIME-Version: 1.0 X-Received: by 10.50.153.49 with SMTP id vd17mr689080igb.22.1374702915930; Wed, 24 Jul 2013 14:55:15 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 14:55:15 -0700 (PDT) Date: Wed, 24 Jul 2013 17:55:15 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e014954bef9d9fd04e248f679 Subject: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:55:17 -0000 --089e014954bef9d9fd04e248f679 Content-Type: text/plain; charset=ISO-8859-1 Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether it should be adopted by I2RS. Detailed technical conversation is also most welcome. Authors: Are you aware of any IPR that applies to draft-nitinb-i2rs-rib-info-model-01 Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --089e014954bef9d9fd04e248f679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please review draft-nitinb-i2rs-rib-info-model-01 and comm= ent on whether it should be adopted by I2RS. =A0Detailed technical conversa= tion is also most welcome.

Authors: Are you aware of any IPR that ap= plies to=A0draft-nitinb-i2rs-rib-info-model-01=A0 Is so, has this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and = 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,Alia
--089e014954bef9d9fd04e248f679-- From akatlas@gmail.com Wed Jul 24 14:59:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D811E8141 for ; Wed, 24 Jul 2013 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyUp0-aTWMiv for ; Wed, 24 Jul 2013 14:59:44 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 648B911E8259 for ; Wed, 24 Jul 2013 14:59:43 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so14428429obb.33 for ; Wed, 24 Jul 2013 14:59:41 -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=RhospByp5B7kIIECKqSng3DBy76RstjGRuSZAwySG1k=; b=Mndnx3Kfc/vAkFQbbAZHaPiyGcd3qIzX1v/UsrOi4hTdwr0a1S1qy5KZ+JMo8TiaK0 xbzQPXQJ2ikCT88usOJIb0ABPKczSgTSy0vktR8quDJJfm5/64QIWJtX6/We4BpTLo1m SgBNdI1wO/uNOgUhlUOKgZpphHeZLcr6b1MM0H/94GPKQmNhqtMcPD+YgiHpGEHVIwek Ys8HqGq/fXX8MdKrxWQtqAbp/G4RC/T3VFS9fwbyEf5EzBPIX4hF5vedbA8wh5GxGCSr 42zkQrY6q0cZySMYhg4RFYFVgiqjUh4zlyl9E6dQ+sGTnIknBPzB7/oRY3Yr5hVZeWpg kjNw== MIME-Version: 1.0 X-Received: by 10.43.65.144 with SMTP id xm16mr19446890icb.112.1374703181840; Wed, 24 Jul 2013 14:59:41 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 14:59:41 -0700 (PDT) Date: Wed, 24 Jul 2013 17:59:41 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51b1b6fd349d804e2490670 Subject: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:59:45 -0000 --bcaec51b1b6fd349d804e2490670 Content-Type: text/plain; charset=ISO-8859-1 Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether it should be adopted by I2RS. Detailed technical conversation is also most welcome. Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02. Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --bcaec51b1b6fd349d804e2490670 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please review=A0draft-keyupdate-i= rs-bgp-usecases-02=A0and comment on whether it should be adopted by I2RS. = =A0Detailed technical conversation is also most welcome.

Authors: Are you aware of any IP= R that applies to=A0draft-keyupdate= -irs-bgp-usecases-02.=A0 Is so, has this IPR been disclosed in compliance w= ith IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will c= omplete on August 12.

Thanks,
Alia
--bcaec51b1b6fd349d804e2490670-- From jmh@joelhalpern.com Wed Jul 24 15:02:00 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2786811E8258 for ; Wed, 24 Jul 2013 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A02ZVRGJkY0E for ; Wed, 24 Jul 2013 15:01:55 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 40FB211E815E for ; Wed, 24 Jul 2013 15:01:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 25C361CC269C; Wed, 24 Jul 2013 15:01:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9201C1CC269A; Wed, 24 Jul 2013 15:01:54 -0700 (PDT) Message-ID: <51F04ED0.4020305@joelhalpern.com> Date: Wed, 24 Jul 2013 18:01:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:02:00 -0000 As a co-author, I do think this is ready for working group adoption and improvement. Also, I do not know of any IPR that applies to this document. Yours, Joel M. Halpern On 7/24/13 5:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From shares@ndzh.com Wed Jul 24 15:04:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2E11E8258 for ; Wed, 24 Jul 2013 15:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoJ+N+tNsqUB for ; Wed, 24 Jul 2013 15:04:14 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5E96D11E8136 for ; Wed, 24 Jul 2013 15:04:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=221.254.18.69; From: "Susan Hares" To: "'Alia Atlas'" , References: In-Reply-To: Date: Wed, 24 Jul 2013 18:04:06 -0400 Message-ID: <007601ce88b9$b89cbc90$29d635b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01CE8898.318CA330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDy/ZSEFTYIc5r7W6tvKZQsp8eHVZsreAog Content-Language: en-us X-Authenticated-User: skh@ndzh.com Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:04:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01CE8898.318CA330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As a co-author, I also am not aware of any IPR that applies to this draft. Like Joel, I feel this draft is ready for WG adoption. Sue From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, July 24, 2013 5:52 PM To: i2rs@ietf.org Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Please review draft-atlas-i2rs-architecture-01 and comment on whether it should be adopted by I2RS. Detailed technical conversation is also most welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia ------=_NextPart_000_0077_01CE8898.318CA330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a co-author, I also am not aware of any IPR that applies to this = draft.

Like Joel, I feel this draft is ready for WG adoption. =

 

Sue

 

From:= = i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of = Alia Atlas
Sent: Wednesday, July 24, 2013 5:52 = PM
To: i2rs@ietf.org
Subject: [i2rs] Call for = Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug = 12)

 

Please = review draft-atlas-i2rs-architecture-01 and comment on whether it should = be adopted by I2RS.  Detailed technical conversation is also most = welcome.

Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details).

This WG call for adoption will complete on August = 12.

Thanks,
Alia

------=_NextPart_000_0077_01CE8898.318CA330-- From akatlas@gmail.com Wed Jul 24 15:04:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0844F11E8272 for ; Wed, 24 Jul 2013 15:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTKMRJwdTRow for ; Wed, 24 Jul 2013 15:04:25 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id EECBF11E8269 for ; Wed, 24 Jul 2013 15:04:24 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so2486099oag.9 for ; Wed, 24 Jul 2013 15:04:24 -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=xCaYDjUjuwonLfr7pjrIO83GRMsNp58FNMsfIPpAEcM=; b=SUoPy1tBNeDpiQWmUEFpb0lAoBOAAej05qID70ABxOnKNSeihy5t0aL6tq2eLUN+ot jOqLwOOReK+FBzDJRDhjCvfKNeiuKD6wECtdSTlSIjJhddX4ljSRv31UmJEYhUAnNcCp s/taGeMy1b9LuJc6mdRYgnH0VrJYWe//OU7QrAkKmj+sdEOa3VDH9D3FmfAibswMlY+J qId2ec1kc7dvtO+MNrcFmftyJPPEC3EsawUjgKLYflE9xEV5wDDvDIHg7IRdE27DHZ0o aNv8YXm5Ecgzvqmd3nzgyREESuHfhCKAqaZw9393zsQ5V6vOQP7rIcJ0imcpO46c3xhr ulfw== MIME-Version: 1.0 X-Received: by 10.50.67.20 with SMTP id j20mr697296igt.36.1374703464505; Wed, 24 Jul 2013 15:04:24 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 15:04:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 18:04:24 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc0f42ac696f04e2491746 Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:04:26 -0000 --047d7bdc0f42ac696f04e2491746 Content-Type: text/plain; charset=ISO-8859-1 Note that: draft-keyupdate-i2rs-bgp-usecases-00 has only the basic changes from IRS to I2RS compared to draft-keyupdate-irs-bgp-usecases-02. Feel free to review and comment on draft-keyupdate-i2rs-bgp-usecases-00 instead. Also - in this case, it is particularly important to have good conversation and discussion on the draft (unless you believe it is perfect) - to help guide the co-authors on how to improve the draft. Regards, Alia On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas wrote: > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether > it should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02. > Is so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > --047d7bdc0f42ac696f04e2491746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note that: =A0draft-keyupdate-i2rs-bgp-usecases-00 has onl= y the basic changes from IRS to I2RS compared to draft-keyupdate-irs-bgp-us= ecases-02. =A0 Feel free to review and comment on draft-keyupdate-i2rs-bgp-= usecases-00 instead.

Also - in this case, it is particularly important to have go= od conversation and discussion on the draft (unless you believe it is perfe= ct) - to help guide the co-authors on how to improve the draft.

Regards,
Alia
=A0



On We= d, Jul 24, 2013 at 5:59 PM, Alia Atlas <akatlas@gmail.com> w= rote:
Please review=A0draft-keyupdate-irs-bgp-usecases-02=A0and comment on whether = it should be adopted by I2RS. =A0Detailed technical conversation is also mo= st welcome.

Authors: Are you aware of any IP= R that applies to=A0draft-keyupdate= -irs-bgp-usecases-02.=A0 Is so, has this IPR been disclosed in compliance w= ith IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will c= omplete on August 12.

Thanks,
Alia

--047d7bdc0f42ac696f04e2491746-- From tnadeau@lucidvision.com Wed Jul 24 15:05:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D93F11E8141 for ; Wed, 24 Jul 2013 15:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK9ojF-rQdnD for ; Wed, 24 Jul 2013 15:05:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E511E8259 for ; Wed, 24 Jul 2013 15:05:01 -0700 (PDT) Received: from dwkwok-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 136E0250E12C; Wed, 24 Jul 2013 18:04:59 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4322223F-9744-4B1C-9FC5-5348820B5A1B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 24 Jul 2013 18:04:58 -0400 Message-Id: <48A27ED9-FD36-49AB-982F-EE983CD82397@lucidvision.com> References: To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:05:10 -0000 --Apple-Mail=_4322223F-9744-4B1C-9FC5-5348820B5A1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think this is ready for working group adoption. I do not know = of any IPR that applies to this document. --Tom On Jul 24, 2013:5:53 PM, at 5:53 PM, Alia Atlas = wrote: > Please review draft-atlas-i2rs-problem-statement-01 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 = and 5378 for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_4322223F-9744-4B1C-9FC5-5348820B5A1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I think = this is ready for working group adoption. I do not know of any IPR that applies = to this document.

= --Tom
akatlas@gmail.com> = wrote:

Please review = draft-atlas-i2rs-problem-statement-01 and comment on whether it should = be adopted by I2RS.  Detailed technical conversation is also most = welcome.

Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 = and 5378 for more details).

This WG call for adoption will complete on August = 12.

Thanks,
Alia
_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_4322223F-9744-4B1C-9FC5-5348820B5A1B-- From tnadeau@lucidvision.com Wed Jul 24 15:05:57 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146FD11E827C for ; Wed, 24 Jul 2013 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKUy5phzAyXa for ; Wed, 24 Jul 2013 15:05:52 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2711411E8136 for ; Wed, 24 Jul 2013 15:05:51 -0700 (PDT) Received: from dwkwok-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 2C252250E147; Wed, 24 Jul 2013 18:05:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5AE18549-8D17-4D9E-A81A-83651874A97D" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 24 Jul 2013 18:05:50 -0400 Message-Id: <5C3797C8-E1F9-4B8B-AC33-600816F79D0B@lucidvision.com> References: To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:05:57 -0000 --Apple-Mail=_5AE18549-8D17-4D9E-A81A-83651874A97D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think this is ready for working group adoption.=20 I do not know of any IPR that applies to this document. --Tom > Please review draft-atlas-i2rs-architecture-01 and comment on whether = it should be adopted by I2RS. Detailed technical conversation is also = most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_5AE18549-8D17-4D9E-A81A-83651874A97D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I think = this is ready for working group adoption. 

I do not know of any IPR that = applies to this document.



Please review = draft-atlas-i2rs-architecture-01 and comment on whether it should be = adopted by I2RS.  Detailed technical conversation is also most = welcome.

Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details).

This WG call for adoption will complete on August = 12.

Thanks,
Alia
_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_5AE18549-8D17-4D9E-A81A-83651874A97D-- From jmh@joelhalpern.com Wed Jul 24 15:09:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3511E8121 for ; Wed, 24 Jul 2013 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLjRreYErZ2i for ; Wed, 24 Jul 2013 15:09:06 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE311E8137 for ; Wed, 24 Jul 2013 15:09:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CD7C81C6E7B; Wed, 24 Jul 2013 15:09:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 366A01C9E7D; Wed, 24 Jul 2013 15:09:00 -0700 (PDT) Message-ID: <51F0507A.1030105@joelhalpern.com> Date: Wed, 24 Jul 2013 18:08:58 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:09:12 -0000 Looking again at this document, I have to reluctantly say taht I do not support adoption of this document at this time. The base definition of RIB is still very unclear. A RIB is some collection of routing instances? First, this seems upside-down to me. A routing instance would seem to contain a RIB, not the other way around. Secondly, what defines, describes, or otherwise helps decide what set of routing instances go in the same RIB. If this issue were clarified, I believe the rest of the material is in sufficiently good shape for working group adoption. Yours, Joel M. Halpern On 7/24/13 5:55 PM, Alia Atlas wrote: > Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether > it should be adopted by I2RS. Detailed technical conversation is also > most welcome. > > Authors: Are you aware of any IPR that applies > to draft-nitinb-i2rs-rib-info-model-01 Is so, has this IPR been > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 > and 5378 for more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From tnadeau@lucidvision.com Wed Jul 24 15:09:13 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989A211E8121 for ; Wed, 24 Jul 2013 15:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLKPvZ9et3ek for ; Wed, 24 Jul 2013 15:09:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 71C7E11E80F4 for ; Wed, 24 Jul 2013 15:09:08 -0700 (PDT) Received: from dwkwok-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 49017250E175; Wed, 24 Jul 2013 18:09:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B6268C3-C1E7-456F-9FA5-294F356C243F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 24 Jul 2013 18:09:05 -0400 Message-Id: <6337506D-6C6E-495F-A422-8C5997651CD9@lucidvision.com> References: To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:09:13 -0000 --Apple-Mail=_3B6268C3-C1E7-456F-9FA5-294F356C243F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I have reviewed the earlier version of this draft and its = current form and think its suitable to meet some of the WG's charter = items. I think its in good shape as a starting point for a WG draft.=20 --Tom > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-keyupdate-irs-bgp-usecases-02. Is so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_3B6268C3-C1E7-456F-9FA5-294F356C243F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

I have reviewed the earlier version of this draft and its current form and think its suitable to meet some of the WG's charter items.  I think its in good shape as a starting point for a WG draft. 

--Tom


Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether it should be adopted by I2RS.  Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02.  Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

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

--Apple-Mail=_3B6268C3-C1E7-456F-9FA5-294F356C243F-- From akatlas@gmail.com Wed Jul 24 15:09:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC211E8230 for ; Wed, 24 Jul 2013 15:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-uVhhtBlmTI for ; Wed, 24 Jul 2013 15:09:15 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15811E8147 for ; Wed, 24 Jul 2013 15:09:15 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so2492555oag.28 for ; Wed, 24 Jul 2013 15:09:14 -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=NDzRZQj/Y9XesGqF9cSSGAr2pvP3FonxtLrQRHC2ZS4=; b=i1QPQkN4MPsXCYzrOkh6nQ+8joASH1ApSMwS41QhtTSC2ObchLU8yX83oUYghpNX5O pCeFFE8QMziBvC7qwRkpZdzG3mMQ50fZg/nFhe6MVVZbB5z3aF1wb/dWW3NnjsYsVb8e kjgK/aFnUqvaIWwQJCK+VO9DZ5fryYKalMCXKGXxA6rjZ/Vu1gqBFKs4C3rDUxn8Y6+7 IF/Vb0uF4NCC7Ah0Qu9rOp0yfSp1LTzUpHlmmoJen2L0Tq3prLQFqAL2jJZ6+UnxhYUk 7nPqbKT4AjfSRShEP+/WPfmQEmrUSgtfUhVBzN+mu8y+KprpTc73PwC80FX4UT08EEaM 6JNA== MIME-Version: 1.0 X-Received: by 10.42.80.9 with SMTP id t9mr20238889ick.14.1374703754612; Wed, 24 Jul 2013 15:09:14 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 15:09:14 -0700 (PDT) Date: Wed, 24 Jul 2013 18:09:14 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e52cff7194f04e2492817 Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:09:16 -0000 --20cf300e52cff7194f04e2492817 Content-Type: text/plain; charset=ISO-8859-1 And I've lost the ability to spell - apparently. It's: draft-keyupate-i2rs-bgp-usecases-00 Alia On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas wrote: > Note that: draft-keyupdate-i2rs-bgp-usecases-00 has only the basic > changes from IRS to I2RS compared to draft-keyupdate-irs-bgp-usecases-02. > Feel free to review and comment on draft-keyupdate-i2rs-bgp-usecases-00 > instead. > > Also - in this case, it is particularly important to have good > conversation and discussion on the draft (unless you believe it is perfect) > - to help guide the co-authors on how to improve the draft. > > Regards, > Alia > > > > > On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas wrote: > >> Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether >> it should be adopted by I2RS. Detailed technical conversation is also most >> welcome. >> >> Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02. >> Is so, has this IPR been disclosed in compliance with IETF IPR rules (see >> RFCs 3979, 4879, 3669 and 5378 for more details). >> >> This WG call for adoption will complete on August 12. >> >> Thanks, >> Alia >> > > --20cf300e52cff7194f04e2492817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And I've lost the ability to spell - apparently.=A0It's: =A0draft-keyupate-i2rs-bgp-usecases-00

Alia


On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas <akatlas@gmai= l.com> wrote:
Note that: =A0draft-keyupda= te-i2rs-bgp-usecases-00 has only the basic changes from IRS to I2RS compare= d to draft-keyupdate-irs-bgp-usecases-02. =A0 Feel free to review and comme= nt on draft-keyupdate-i2rs-bgp-usecases-00 instead.

Also - in this case, it is particularly important to have go= od conversation and discussion on the draft (unless you believe it is perfe= ct) - to help guide the co-authors on how to improve the draft.

Regards,
Alia
=A0

=

On Wed, Jul 24, 2013 at 5:59 PM, Alia At= las <akatlas@gmail.com> wrote:
Please review=A0draft-keyupdate-irs-bgp-usecases-02=A0and comment on whether = it should be adopted by I2RS. =A0Detailed technical conversation is also mo= st welcome.

Authors: Are you aware of any IP= R that applies to=A0draft-keyupdate= -irs-bgp-usecases-02.=A0 Is so, has this IPR been disclosed in compliance w= ith IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will c= omplete on August 12.

Thanks,
Alia


--20cf300e52cff7194f04e2492817-- From tnadeau@lucidvision.com Wed Jul 24 15:11:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C3B11E8121 for ; Wed, 24 Jul 2013 15:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YszVpkx4hh1n for ; Wed, 24 Jul 2013 15:11:54 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0011E8137 for ; Wed, 24 Jul 2013 15:11:54 -0700 (PDT) Received: from dwkwok-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id BA521250E1BB; Wed, 24 Jul 2013 18:11:53 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Wed, 24 Jul 2013 18:11:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <176DB78E-C0A0-44B0-BE51-60F23019AAAA@lucidvision.com> References: To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:11:59 -0000 I have reviewed the document in detail. As Joel mentioned, = there are some bumps and warts that need to be fleshed out, but I feel = it is sufficiently well put together as a starting point for the WG to = satisfy part of the chartered items of producing an information model.=20= --Tom On Jul 24, 2013:5:55 PM, at 5:55 PM, Alia Atlas = wrote: > Please review draft-nitinb-i2rs-rib-info-model-01 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-nitinb-i2rs-rib-info-model-01 Is so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Wed Jul 24 15:16:57 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58C11E811E for ; Wed, 24 Jul 2013 15:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5JtC3Sqi3Rh for ; Wed, 24 Jul 2013 15:16:56 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F043811E8137 for ; Wed, 24 Jul 2013 15:16:53 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so14599375obb.29 for ; Wed, 24 Jul 2013 15: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 :cc:content-type; bh=jenPaisi56iixuphlp4zxENxQCbaqI0d34mLkH5LtCg=; b=b0lY+2uq2kZijouI97JTZiZ5Q1ZdVi0s8/S6o3TOa5rw5WzwvOByT5wY/g6rYF+pl1 KlmuAhC4T2dCwOhlkPnaB/8DYEXfL4TRNggVywXrRE/5vcAVcGKgEaPSJRPNjCDS9JCr 08QCQ4zfd6bJh9AKAXILd46hxV1EdqBBkyw3EzgD7l4oehl1ptRlC5ml63/Zmqx3Av+x yHnLLbsDnaTFiRBgJSjojfQGn9a5HcFeaxAGci7nlx3bMWX8WGGr/o21ezspGyMlyXpk rcVz/QKEsME/JrR/09k7JtIVwJBwz/cEz+ED9kt/XIwcNd1umceK3lAk+mc3VVF15Uwf hOvQ== MIME-Version: 1.0 X-Received: by 10.50.164.167 with SMTP id yr7mr697720igb.22.1374704213469; Wed, 24 Jul 2013 15:16:53 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Wed, 24 Jul 2013 15:16:53 -0700 (PDT) In-Reply-To: <51F0507A.1030105@joelhalpern.com> References: <51F0507A.1030105@joelhalpern.com> Date: Wed, 24 Jul 2013 18:16:53 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=089e0122a7fc50af8b04e2494435 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:16:57 -0000 --089e0122a7fc50af8b04e2494435 Content-Type: text/plain; charset=ISO-8859-1 Joel, I understand your concern. Do you have text to suggest to Nitin and co-authors? I think part of this is figuring out how to pull out the RIB bits (routing tables) and what traffic they apply to - as well as the policy of how to create associated containers. Nitin's called that a routing instance... What set of objects would you create? I personally would like to see the info-model described in something other than rBNF - but I view that as a piece that can happen in a future version. Alia On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern wrote: > Looking again at this document, I have to reluctantly say taht I do not > support adoption of this document at this time. > > The base definition of RIB is still very unclear. A RIB is some > collection of routing instances? First, this seems upside-down to me. A > routing instance would seem to contain a RIB, not the other way around. > Secondly, what defines, describes, or otherwise helps decide what set of > routing instances go in the same RIB. > > If this issue were clarified, I believe the rest of the material is in > sufficiently good shape for working group adoption. > > Yours, > Joel M. Halpern > > > On 7/24/13 5:55 PM, Alia Atlas wrote: > >> Please review draft-nitinb-i2rs-rib-info-**model-01 and comment on >> whether >> it should be adopted by I2RS. Detailed technical conversation is also >> most welcome. >> >> Authors: Are you aware of any IPR that applies >> to draft-nitinb-i2rs-rib-info-**model-01 Is so, has this IPR been >> disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >> and 5378 for more details). >> >> This WG call for adoption will complete on August 12. >> >> Thanks, >> Alia >> >> >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> --089e0122a7fc50af8b04e2494435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,

I understand your concern. =A0Do = you have text to suggest to Nitin and co-authors?
I think part of= this is figuring out how to pull out the RIB bits (routing tables) and wha= t traffic they apply to - as well as the policy of how to create associated= containers. =A0Nitin's called that a routing instance... =A0

What set of objects would you create? =A0=A0
=
I personally would like to see the info-model described in s= omething other than rBNF - but I view that as a piece that can happen in a = future version.

Alia



On Wed, Jul 24, 2013 at 6:08 PM, Joel= M. Halpern <jmh@joelhalpern.com> wrote:
Looking again at this document, I have to re= luctantly say taht I do not support adoption of this document at this time.=

The base definition of RIB is still very unclear. =A0A RIB is some collecti= on of routing instances? =A0First, this seems upside-down to me. A routing = instance would seem to contain a RIB, not the other way around. =A0Secondly= , what defines, describes, or otherwise helps decide what set of routing in= stances go in the same RIB.

If this issue were clarified, I believe the rest of the material is in suff= iciently good shape for working group adoption.

Yours,
Joel M. Halpern


On 7/24/13 5:55 PM, Alia Atlas wrote:
Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whe= ther
it should be adopted by I2RS. =A0Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies
to draft-nitinb-i2rs-rib-info-model-01 =A0Is so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia


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


--089e0122a7fc50af8b04e2494435-- From jmh@joelhalpern.com Wed Jul 24 15:20:01 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA1A11E8235 for ; Wed, 24 Jul 2013 15:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m8qBYhqTxsa for ; Wed, 24 Jul 2013 15:19:56 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id A962C11E815E for ; Wed, 24 Jul 2013 15:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 91EAD1C6E7B; Wed, 24 Jul 2013 15:19:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D24211C071C; Wed, 24 Jul 2013 15:19:53 -0700 (PDT) Message-ID: <51F05308.9030100@joelhalpern.com> Date: Wed, 24 Jul 2013 18:19:52 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: <51F0507A.1030105@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 22:20:01 -0000 Asking for a text proposal is quite reasonable. Unfortunately, since my oncern is taht I can not understand what is meant by RIB in this definition, it is really ahrd to propose an alternative set of definitions that do what the authors wanted. Yours, Joel On 7/24/13 6:16 PM, Alia Atlas wrote: > Joel, > > I understand your concern. Do you have text to suggest to Nitin and > co-authors? > I think part of this is figuring out how to pull out the RIB bits > (routing tables) and what traffic they apply to - as well as the policy > of how to create associated containers. Nitin's called that a routing > instance... > > What set of objects would you create? > > I personally would like to see the info-model described in something > other than rBNF - but I view that as a piece that can happen in a future > version. > > Alia > > > > On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern > wrote: > > Looking again at this document, I have to reluctantly say taht I do > not support adoption of this document at this time. > > The base definition of RIB is still very unclear. A RIB is some > collection of routing instances? First, this seems upside-down to > me. A routing instance would seem to contain a RIB, not the other > way around. Secondly, what defines, describes, or otherwise helps > decide what set of routing instances go in the same RIB. > > If this issue were clarified, I believe the rest of the material is > in sufficiently good shape for working group adoption. > > Yours, > Joel M. Halpern > > > On 7/24/13 5:55 PM, Alia Atlas wrote: > > Please review draft-nitinb-i2rs-rib-info-__model-01 and comment > on whether > it should be adopted by I2RS. Detailed technical conversation > is also > most welcome. > > Authors: Are you aware of any IPR that applies > to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR been > disclosed in compliance with IETF IPR rules (see RFCs 3979, > 4879, 3669 > and 5378 for more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia > > > _________________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/__listinfo/i2rs > > > From nitinb@juniper.net Wed Jul 24 19:21:22 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DBB21F9A35 for ; Wed, 24 Jul 2013 19:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcOjJxwOlnLa for ; Wed, 24 Jul 2013 19:21:17 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0B321F9A37 for ; Wed, 24 Jul 2013 19:21:16 -0700 (PDT) Received: from mail69-co1-R.bigfish.com (10.243.78.246) by CO1EHSOBE030.bigfish.com (10.243.66.95) with Microsoft SMTP Server id 14.1.225.22; Thu, 25 Jul 2013 02:21:16 +0000 Received: from mail69-co1 (localhost [127.0.0.1]) by mail69-co1-R.bigfish.com (Postfix) with ESMTP id 77D4F6800AF for ; Thu, 25 Jul 2013 02:21:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h1de096h8275bh8275dhz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail69-co1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=nitinb@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail69-co1 (localhost.localdomain [127.0.0.1]) by mail69-co1 (MessageSwitch) id 1374718874752872_14376; Thu, 25 Jul 2013 02:21:14 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.238]) by mail69-co1.bigfish.com (Postfix) with ESMTP id AAB79AC0048 for ; Thu, 25 Jul 2013 02:21:14 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 25 Jul 2013 02:21:14 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 24 Jul 2013 19:21:13 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 24 Jul 2013 19:21:13 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 24 Jul 2013 19:34:16 -0700 Received: from mail9-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.22; Thu, 25 Jul 2013 02:21:12 +0000 Received: from mail9-co1 (localhost [127.0.0.1]) by mail9-co1-R.bigfish.com (Postfix) with ESMTP id A50C9900121 for ; Thu, 25 Jul 2013 02:21:12 +0000 (UTC) Received: from mail9-co1 (localhost.localdomain [127.0.0.1]) by mail9-co1 (MessageSwitch) id 1374718870694960_14967; Thu, 25 Jul 2013 02:21:10 +0000 (UTC) Received: from CO1EHSMHS007.bigfish.com (unknown [10.243.78.227]) by mail9-co1.bigfish.com (Postfix) with ESMTP id A0EA49E0049; Thu, 25 Jul 2013 02:21:10 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS007.bigfish.com (10.243.66.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 25 Jul 2013 02:21:10 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0329.000; Thu, 25 Jul 2013 02:21:06 +0000 From: Nitin Bahadur To: "Joel M. Halpern" , Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOiLwErF8aRPkwVkGXnQxOro1qa5l0NGsA Date: Thu, 25 Jul 2013 02:21:06 +0000 Message-ID: In-Reply-To: <51F05308.9030100@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <33BAF0E743E75D4D8BB00DA0EAFC5898@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%JOELHALPERN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 02:21:22 -0000 Hi Joel, Maybe this can help clarify what we meant by the RIB. The RIB is the totality of all routing-information in a router. The routing information itself can be sub-divided into multiple objects called routing-instances.=20 Routing-instances allow us to partition the physical router into domains that can operate independently from one another in terms of routing and forwarding.=20 The rest of that section describes what objects are contained in a RIB, like routing tables, routes and nexthops. HTH as a starting point. Nitin Bahadur On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >Asking for a text proposal is quite reasonable. >Unfortunately, since my oncern is taht I can not understand what is >meant by RIB in this definition, it is really ahrd to propose an >alternative set of definitions that do what the authors wanted. > >Yours, >Joel > >On 7/24/13 6:16 PM, Alia Atlas wrote: >> Joel, >> >> I understand your concern. Do you have text to suggest to Nitin and >> co-authors? >> I think part of this is figuring out how to pull out the RIB bits >> (routing tables) and what traffic they apply to - as well as the policy >> of how to create associated containers. Nitin's called that a routing >> instance... >> >> What set of objects would you create? >> >> I personally would like to see the info-model described in something >> other than rBNF - but I view that as a piece that can happen in a future >> version. >> >> Alia >> >> >> >> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern > > wrote: >> >> Looking again at this document, I have to reluctantly say taht I do >> not support adoption of this document at this time. >> >> The base definition of RIB is still very unclear. A RIB is some >> collection of routing instances? First, this seems upside-down to >> me. A routing instance would seem to contain a RIB, not the other >> way around. Secondly, what defines, describes, or otherwise helps >> decide what set of routing instances go in the same RIB. >> >> If this issue were clarified, I believe the rest of the material is >> in sufficiently good shape for working group adoption. >> >> Yours, >> Joel M. Halpern >> >> >> On 7/24/13 5:55 PM, Alia Atlas wrote: >> >> Please review draft-nitinb-i2rs-rib-info-__model-01 and comment >> on whether >> it should be adopted by I2RS. Detailed technical conversation >> is also >> most welcome. >> >> Authors: Are you aware of any IPR that applies >> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR >>been >> disclosed in compliance with IETF IPR rules (see RFCs 3979, >> 4879, 3669 >> and 5378 for more details). >> >> This WG call for adoption will complete on August 12. >> >> Thanks, >> Alia >> >> >> _________________________________________________ >> 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 jmh@joelhalpern.com Wed Jul 24 19:43:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8746621F9A44 for ; Wed, 24 Jul 2013 19:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR3xdsq+pxST for ; Wed, 24 Jul 2013 19:43:36 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCA21F99C2 for ; Wed, 24 Jul 2013 19:43:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CFA651CC37B2; Wed, 24 Jul 2013 19:43:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-244.clppva.east.verizon.net [70.106.134.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EDF9B1CC37B1; Wed, 24 Jul 2013 19:43:35 -0700 (PDT) Message-ID: <51F090D6.8080002@joelhalpern.com> Date: Wed, 24 Jul 2013 22:43:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 02:43:41 -0000 This seems a different use of the term RIB than most of the work I am familiar with. Even without dealing with things like protocol specific RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally discuss them as using separate RIBs. This is why the terminology seems upside-down to me. Yours, Joel On 7/24/13 10:21 PM, Nitin Bahadur wrote: > Hi Joel, > > Maybe this can help clarify what we meant by the RIB. > > The RIB is the totality of all routing-information in a router. The > routing information itself can be sub-divided into multiple objects called > routing-instances. > > Routing-instances allow us to partition the physical router into domains > that can operate independently from one another in terms of routing and > forwarding. > > > The rest of that section describes what objects are contained in a RIB, > like routing tables, routes and nexthops. > > > HTH as a starting point. > Nitin Bahadur > > > > > > On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: > >> Asking for a text proposal is quite reasonable. >> Unfortunately, since my oncern is taht I can not understand what is >> meant by RIB in this definition, it is really ahrd to propose an >> alternative set of definitions that do what the authors wanted. >> >> Yours, >> Joel >> >> On 7/24/13 6:16 PM, Alia Atlas wrote: >>> Joel, >>> >>> I understand your concern. Do you have text to suggest to Nitin and >>> co-authors? >>> I think part of this is figuring out how to pull out the RIB bits >>> (routing tables) and what traffic they apply to - as well as the policy >>> of how to create associated containers. Nitin's called that a routing >>> instance... >>> >>> What set of objects would you create? >>> >>> I personally would like to see the info-model described in something >>> other than rBNF - but I view that as a piece that can happen in a future >>> version. >>> >>> Alia >>> >>> >>> >>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >> > wrote: >>> >>> Looking again at this document, I have to reluctantly say taht I do >>> not support adoption of this document at this time. >>> >>> The base definition of RIB is still very unclear. A RIB is some >>> collection of routing instances? First, this seems upside-down to >>> me. A routing instance would seem to contain a RIB, not the other >>> way around. Secondly, what defines, describes, or otherwise helps >>> decide what set of routing instances go in the same RIB. >>> >>> If this issue were clarified, I believe the rest of the material is >>> in sufficiently good shape for working group adoption. >>> >>> Yours, >>> Joel M. Halpern >>> >>> >>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>> >>> Please review draft-nitinb-i2rs-rib-info-__model-01 and comment >>> on whether >>> it should be adopted by I2RS. Detailed technical conversation >>> is also >>> most welcome. >>> >>> Authors: Are you aware of any IPR that applies >>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR >>> been >>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>> 4879, 3669 >>> and 5378 for more details). >>> >>> This WG call for adoption will complete on August 12. >>> >>> Thanks, >>> Alia >>> >>> >>> _________________________________________________ >>> 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 N.Leymann@telekom.de Thu Jul 25 01:06:29 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78E821F9A33 for ; Thu, 25 Jul 2013 01:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a72EAhA0pJA for ; Thu, 25 Jul 2013 01:06:22 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 237B021F9A16 for ; Thu, 25 Jul 2013 01:06:21 -0700 (PDT) Received: from he113598.emea1.cds.t-internal.com ([10.125.65.117]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jul 2013 10:06:18 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE113598.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 25 Jul 2013 10:06:18 +0200 From: To: , Date: Thu, 25 Jul 2013 10:06:16 +0200 Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: Ac6IuBY8McLMYhMsQQGiG3np1sGpWQAVZr5w Message-ID: <9762ACF04FA26B4388476841256BDE02011ADFB8D03E@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE02011ADFB8D03EHE111543eme_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:06:29 -0000 --_000_9762ACF04FA26B4388476841256BDE02011ADFB8D03EHE111543eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From my point of view the draft is ready for WG adoption. regards Nic ________________________________ Von: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] Im Auftrag von Al= ia Atlas Gesendet: Mittwoch, 24. Juli 2013 23:52 An: i2rs@ietf.org Betreff: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (= ends Aug 12) Please review draft-atlas-i2rs-architecture-01 and comment on whether it sh= ould be adopted by I2RS. Detailed technical conversation is also most welc= ome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architec= ture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --_000_9762ACF04FA26B4388476841256BDE02011ADFB8D03EHE111543eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
From my point of view the draft is ready for WG=20 adoption.
 
  regards
 
    Nic

Von: i2rs-bounces@ietf.org=20 [mailto:i2rs-bounces@ietf.org] Im Auftrag von Alia=20 Atlas
Gesendet: Mittwoch, 24. Juli 2013 23:52
An:=20 i2rs@ietf.org
Betreff: [i2rs] Call for Adoption by WG:=20 draft-atlas-i2rs-architecture-01 (ends Aug 12)

Please review draft-atlas-i2rs-architecture-01 and comment o= n=20 whether it should be adopted by I2RS.  Detailed technical conversation= is=20 also most welcome.

Authors: Are you aware of any IPR that applies to= =20 draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in=20 compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more= =20 details).

This WG call for adoption will complete on August=20 12.

Thanks,
Alia
--_000_9762ACF04FA26B4388476841256BDE02011ADFB8D03EHE111543eme_-- From N.Leymann@telekom.de Thu Jul 25 01:07:34 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4F21F99FB for ; Thu, 25 Jul 2013 01:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc-WiS+-+jp0 for ; Thu, 25 Jul 2013 01:07:26 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEAF21F9A29 for ; Thu, 25 Jul 2013 01:07:25 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Jul 2013 10:07:22 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%14]) with mapi; Thu, 25 Jul 2013 10:07:21 +0200 From: To: , Date: Thu, 25 Jul 2013 10:07:19 +0200 Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: Ac6IuDehGAg62gb2Rz65pCxQ4ExxRQAVXbKw Message-ID: <9762ACF04FA26B4388476841256BDE02011ADFB8D042@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE02011ADFB8D042HE111543eme_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:07:34 -0000 --_000_9762ACF04FA26B4388476841256BDE02011ADFB8D042HE111543eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From my point of view the draft is ready for WG adoption. regards Nic ________________________________ Von: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] Im Auftrag von Al= ia Atlas Gesendet: Mittwoch, 24. Juli 2013 23:53 An: i2rs@ietf.org Betreff: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Please review draft-atlas-i2rs-problem-statement-01 and comment on whether = it should be adopted by I2RS. Detailed technical conversation is also most= welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-= statement-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --_000_9762ACF04FA26B4388476841256BDE02011ADFB8D042HE111543eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
From my point of view the draft is ready for WG=20 adoption.
 
  regards
 
    Nic


Von: i2rs-bounces@ietf.org=20 [mailto:i2rs-bounces@ietf.org] Im Auftrag von Alia=20 Atlas
Gesendet: Mittwoch, 24. Juli 2013 23:53
An:=20 i2rs@ietf.org
Betreff: [i2rs] Call for WG Adoption:=20 draft-atlas-i2rs-problem-statement-01

Please review draft-atlas-i2rs-problem-statement-01 and comm= ent on=20 whether it should be adopted by I2RS.  Detailed technical conversation= is=20 also most welcome.

Authors: Are you aware of any IPR that applies to= =20 draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been disclosed i= n=20 compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more= =20 details).

This WG call for adoption will complete on August=20 12.

Thanks,
Alia
--_000_9762ACF04FA26B4388476841256BDE02011ADFB8D042HE111543eme_-- From acee.lindem@ericsson.com Thu Jul 25 04:25:18 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C395D21F9A74 for ; Thu, 25 Jul 2013 04:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvO9eMD1uoN0 for ; Thu, 25 Jul 2013 04:25:13 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE68F21F9A4A for ; Thu, 25 Jul 2013 04:25:12 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-e5-51f10b13e1cd Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C8.50.13034.41B01F15; Thu, 25 Jul 2013 13:25:08 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 07:25:07 -0400 From: Acee Lindem To: "Joel M. Halpern" , Nitin Bahadur Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOiLpwmyVE6QJjHUysr/9svX4s1pl0qJmAgAAA1QCAAENnAIAABkcAgAAcX4A= Date: Thu, 25 Jul 2013 11:25:07 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> In-Reply-To: <51F090D6.8080002@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <855951EBC5FD9547A252B5B373A535B8@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPlK4I98dAg4ktEhafHl5itlg34wOL xcdTb5gsGnrb2RxYPHbOusvusWTJTyaPc1O+M3pcb7rKHsASxWWTkpqTWZZapG+XwJWxb9sK toI2pYr3q76xNjBOkOpi5OSQEDCROLx0HhuELSZx4d56IJuLQ0jgKKPE4UtLGSGc5YwSjR0/ WUCq2AR0JJ4/+scMYosIBEpce7maEcRmFnCW6L/RzQ5iCwvEShxu6oCqiZNonzibHcL2kzi0 ez6YzSKgKnHj4UKmLkYODl4BX4m7m4RAwpwC+hKPp14Ea2UEOuj7qTVMEOPFJW49mc8EcaiA xJI955khbFGJl4//sYLYogJ6Em3HzrBDxJUlvs95xALRqyOxYPcnNgjbWuL38udQcW2JZQtf g83hFRCUODnzCcsERvFZSNbNQtI+C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYfcck2HR3 MO55aXmIUZqDRUmcd5XemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMb1T9dYfDU6YFiu L/08l/dzvtqC1wfTji8SfRvt4NA9JcqWa9ntTQoyibu0Fd4vqFVc97rF50tYsHaflMGOhudL //76X/TkY9umBG2xCRMWpH3pWr8+iffwzOBNn+bLa7YKdt6vm7f2cauhRdGHhf/l/vbvmRgw wdxag+GX2NNl19T4jVyLupVYijMSDbWYi4oTAYDtHCeMAgAA Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 11:25:18 -0000 I agree with Joel.=20 On 7/24/13 7:43 PM, "Joel M. Halpern" wrote: >This seems a different use of the term RIB than most of the work I am >familiar with. Even without dealing with things like protocol specific >RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally >discuss them as using separate RIBs. This is why the terminology seems >upside-down to me. > >Yours, >Joel > >On 7/24/13 10:21 PM, Nitin Bahadur wrote: >> Hi Joel, >> >> Maybe this can help clarify what we meant by the RIB. >> >> The RIB is the totality of all routing-information in a router. The >> routing information itself can be sub-divided into multiple objects >>called >> routing-instances. >> >> Routing-instances allow us to partition the physical router into domains >> that can operate independently from one another in terms of routing and >> forwarding. >> >> >> The rest of that section describes what objects are contained in a RIB, >> like routing tables, routes and nexthops. >> >> >> HTH as a starting point. >> Nitin Bahadur >> >> >> >> >> >> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >> >>> Asking for a text proposal is quite reasonable. >>> Unfortunately, since my oncern is taht I can not understand what is >>> meant by RIB in this definition, it is really ahrd to propose an >>> alternative set of definitions that do what the authors wanted. >>> >>> Yours, >>> Joel >>> >>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>>> Joel, >>>> >>>> I understand your concern. Do you have text to suggest to Nitin and >>>> co-authors? >>>> I think part of this is figuring out how to pull out the RIB bits >>>> (routing tables) and what traffic they apply to - as well as the >>>>policy >>>> of how to create associated containers. Nitin's called that a routing >>>> instance... >>>> >>>> What set of objects would you create? >>>> >>>> I personally would like to see the info-model described in something >>>> other than rBNF - but I view that as a piece that can happen in a >>>>future >>>> version. >>>> >>>> Alia >>>> >>>> >>>> >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>> > wrote: >>>> >>>> Looking again at this document, I have to reluctantly say taht I >>>>do >>>> not support adoption of this document at this time. >>>> >>>> The base definition of RIB is still very unclear. A RIB is some >>>> collection of routing instances? First, this seems upside-down >>>>to >>>> me. A routing instance would seem to contain a RIB, not the other >>>> way around. Secondly, what defines, describes, or otherwise >>>>helps >>>> decide what set of routing instances go in the same RIB. >>>> >>>> If this issue were clarified, I believe the rest of the material >>>>is >>>> in sufficiently good shape for working group adoption. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> >>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>> >>>> Please review draft-nitinb-i2rs-rib-info-__model-01 and >>>>comment >>>> on whether >>>> it should be adopted by I2RS. Detailed technical >>>>conversation >>>> is also >>>> most welcome. >>>> >>>> Authors: Are you aware of any IPR that applies >>>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR >>>> been >>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>> 4879, 3669 >>>> and 5378 for more details). >>>> >>>> This WG call for adoption will complete on August 12. >>>> >>>> Thanks, >>>> Alia >>>> >>>> >>>> _________________________________________________ >>>> 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 wesley.george@twcable.com Thu Jul 25 13:01:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762121F8FA1 for ; Thu, 25 Jul 2013 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsFoxtpBt3kz for ; Thu, 25 Jul 2013 13:01:21 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 170F721F8445 for ; Thu, 25 Jul 2013 13:01:20 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,745,1367985600"; d="scan'208,217";a="109363245" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2013 15:59:58 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 25 Jul 2013 16:01:20 -0400 From: "George, Wes" To: Alia Atlas , "i2rs@ietf.org" Date: Thu, 25 Jul 2013 16:01:19 -0400 Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: Ac6IuDYf69XA4LHyQoK5QoUZilGZvQAuWvLw Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304393ED9AF@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD592304393ED9AFPRVPEXVS15cor_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:01:27 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393ED9AFPRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable support adoption, good starting point Thanks, Wes From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Wednesday, July 24, 2013 5:53 PM To: i2rs@ietf.org Subject: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Please review draft-atlas-i2rs-problem-statement-01 and comment on whether = it should be adopted by I2RS. Detailed technical conversation is also most= welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-= statement-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia ________________________________ 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. --_000_2671C6CDFBB59E47B64C10B3E0BD592304393ED9AFPRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

support adoption, good st= arting point

 <= /p>

Thanks,=

 <= /p>

Wes

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 5:53 PM
To: i2rs@ietf.org
Subject: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-state= ment-01

 

Please review draft-atlas-i2rs-problem-statement-01 = and comment on whether it should be adopted by I2RS.  Detailed technic= al conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-= statement-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393ED9AFPRVPEXVS15cor_-- From wesley.george@twcable.com Thu Jul 25 13:40:16 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1021F9433 for ; Thu, 25 Jul 2013 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksvLczDMGD8Y for ; Thu, 25 Jul 2013 13:40:11 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3B021F91CA for ; Thu, 25 Jul 2013 13:40:07 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,745,1367985600"; d="scan'208,217";a="109387591" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2013 16:38:39 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 25 Jul 2013 16:40:02 -0400 From: "George, Wes" To: Alia Atlas , "i2rs@ietf.org" Date: Thu, 25 Jul 2013 16:40:01 -0400 Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: Ac6IuBSJUoFN4ikOQmKY3ChJtOIedAAvWgdA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304393EDA61@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDA61PRVPEXVS15cor_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:40:16 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDA61PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have some concerns about 6.1 in terms of whether it could be interpreted = as a definite statement of direction that we'll be building a new protocol = rather than identifying one to modify for use here, which I think is in con= flict with section 5 of the problem statement. I agree that cobbling together several protocols that weren't meant to be i= ntegrated isn't necessarily a good solution when compared with a single pro= tocol, so I think this may be a wording problem in the current text, rather= than a philosophical disagreement, but it's worth confirming that before w= e adopt this draft. If I'm right that it's just a wording issue, it may be = as simple as adding the same words from the problem statement: "Whether such a protocol is built upon extending existing mechanisms or requires a new mechanism requires further investigation." Otherwise I think it's in good shape. Thanks, Wes George From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Wednesday, July 24, 2013 5:52 PM To: i2rs@ietf.org Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (= ends Aug 12) Please review draft-atlas-i2rs-architecture-01 and comment on whether it sh= ould be adopted by I2RS. Detailed technical conversation is also most welc= ome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architec= ture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia ________________________________ 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. --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDA61PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have some concerns abou= t 6.1 in terms of whether it could be interpreted as a definite statement o= f direction that we’ll be building a new protocol rather than identifying one to modify for use here, which I think is in conflict = with section 5 of the problem statement. 

I agree =
that cobbling together several protocols that weren’t meant to be int=
egrated isn’t necessarily a good solution when compared with a single=
 protocol, so I think this may be a wording problem in the current text, ra=
ther than a philosophical disagreement, but it’s worth confirming tha=
t before we adopt this draft. If I’m right that it’s just a wor=
ding issue, it may be as simple as adding the same words from the problem s=
tatement: 
 &n=
bsp;       “Whether such a protocol is built upon extendi=
ng

   existing mechan= isms or requires a new mechanism requires further

   investigation.<= /span>“

 <= /p>

Otherwise I think it̵= 7;s in good shape.

 <= /p>

Thanks,=

 <= /p>

Wes George

 <= /p>

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 5:52 PM
To: i2rs@ietf.org
Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architectu= re-01 (ends Aug 12)

 

Please review draft-atlas-i2rs-architecture-01 and c= omment on whether it should be adopted by I2RS.  Detailed technical co= nversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architec= ture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDA61PRVPEXVS15cor_-- From akatlas@gmail.com Thu Jul 25 13:56:30 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45F321F9396 for ; Thu, 25 Jul 2013 13:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRlZfRq7ipUb for ; Thu, 25 Jul 2013 13:56:30 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D634021F944C for ; Thu, 25 Jul 2013 13:56:29 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so5717294oag.9 for ; Thu, 25 Jul 2013 13:56:29 -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=+FdV4/68QTHjRjBYJU3n8X7+PouP/ayf3bt8uUjgWoQ=; b=qlvzrT/KUqsJdLegrUir1rV/FHUjdyx/f59ewguiLuTV+9L+RqkbZ0m0BGWnEaEnaq AEwgc+rd85c/coEnxsTsp9JT8thszz8tgFZsPMyeZxjN7QRBZQIoAK5ZM07s3XbR4yWZ WF6k7uiHPoKacBRMX4rfl+NR1J/HD89MeMX8cuFEnhcMY0hM8BWlU6P37pWGEc4wrY3b kYXks7a+leEDwJpWMkshCOO0mH6DHvUJnbyn/A6zXGIVeLiOia9MwloJesh7hpPS4TXi U2L3m6IwFXfHjswRtXwAKrpUsQi0P2P41hMxfRBemq2hoEp352vxmfn+7VBUzUaP/G73 cuSQ== MIME-Version: 1.0 X-Received: by 10.43.65.144 with SMTP id xm16mr19924675icb.112.1374785789316; Thu, 25 Jul 2013 13:56:29 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 13:56:29 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Thu, 25 Jul 2013 13:56:29 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592304393EDA61@PRVPEXVS15.corp.twcable.com> References: <2671C6CDFBB59E47B64C10B3E0BD592304393EDA61@PRVPEXVS15.corp.twcable.com> Date: Thu, 25 Jul 2013 16:56:29 -0400 Message-ID: From: Alia Atlas To: Wes George Content-Type: multipart/alternative; boundary=bcaec51b1b6f9d544304e25c42ca Cc: i2rs@ietf.org Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 20:56:30 -0000 --bcaec51b1b6f9d544304e25c42ca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Wes, I'll be happy to add the suggested words. Personally, I hope we can modify an existing protocol... Alia On Jul 25, 2013 4:40 PM, "George, Wes" wrote: > I have some concerns about 6.1 in terms of whether it could be > interpreted as a definite statement of direction that we=92ll be building= a > new protocol rather than identifying one to modify for use here, which I > think is in conflict with section 5 of the problem statement. **** > > I agree that cobbling together several protocols that weren=92t meant to = be integrated isn=92t necessarily a good solution when compared with a sing= le protocol, so I think this may be a wording problem in the current text, = rather than a philosophical disagreement, but it=92s worth confirming that = before we adopt this draft. If I=92m right that it=92s just a wording issue= , it may be as simple as adding the same words from the problem statement: = **** > > =93Whether such a protocol is built upon extending**** > > existing mechanisms or requires a new mechanism requires further**** > > investigation.=93**** > > ** ** > > Otherwise I think it=92s in good shape.**** > > ** ** > > Thanks,**** > > ** ** > > Wes George**** > > ** ** > > ** ** > > *From:* i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] *On Behalf > Of *Alia Atlas > *Sent:* Wednesday, July 24, 2013 5:52 PM > *To:* i2rs@ietf.org > *Subject:* [i2rs] Call for Adoption by WG: > draft-atlas-i2rs-architecture-01 (ends Aug 12)**** > > ** ** > > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for mo= re > details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia**** > > ------------------------------ > 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. > --bcaec51b1b6f9d544304e25c42ca Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Wes,

I'll be happy to add the suggested words.=A0 Personally,= =A0 I hope we can modify an existing protocol...=A0

Alia

On Jul 25, 2013 4:40 PM, "George, Wes"= <wesley.george@twcable.com= > wrote:

I have some concerns abou= t 6.1 in terms of whether it could be interpreted as a definite statement o= f direction that we=92ll be building a new protocol rather than identifying one to modify for use here, which I think is in conflict = with section 5 of the problem statement. 

I agree that cobbling together several prot=
ocols that weren=92t meant to be integrated isn=92t necessarily a good solu=
tion when compared with a single protocol, so I think this may be a wording=
 problem in the current text, rather than a philosophical disagreement, but=
 it=92s worth confirming that before we adopt this draft. If I=92m right th=
at it=92s just a wording issue, it may be as simple as adding the same word=
s from the problem statement: 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=93Whether such a protocol is built upon extending<=
u>

= =A0=A0 existing mechanisms or requires a new mechanism requires further<= /u>

= =A0=A0 investigation.=93

=A0<= /p>

Otherwise I think it=92s = in good shape.

=A0<= /p>

Thanks,

=A0<= /p>

Wes George<= /span>

=A0<= /p>

=A0<= /p>

From: i2rs-bounces@ietf.org [mailto:i2rs-= bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 5:52 PM
To: i2rs@ietf.org=
Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architectu= re-01 (ends Aug 12)

=A0

Please review draft-atlas-i2rs-architecture-01 and c= omment on whether it should be adopted by I2RS. =A0Detailed technical conve= rsation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architec= ture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
--bcaec51b1b6f9d544304e25c42ca-- From wesley.george@twcable.com Thu Jul 25 14:04:06 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2756A21F8C66 for ; Thu, 25 Jul 2013 14:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8CM7Gzhe6IV for ; Thu, 25 Jul 2013 14:04:02 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB36421F864D for ; Thu, 25 Jul 2013 14:04:01 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.89,745,1367985600"; d="scan'208,217";a="109400961" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Jul 2013 17:02:38 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 25 Jul 2013 17:04:01 -0400 From: "George, Wes" To: Alia Atlas , "i2rs@ietf.org" Date: Thu, 25 Jul 2013 17:04:00 -0400 Thread-Topic: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 Thread-Index: Ac6IuomjyY8NvvgCTrei7nykJnUNxgAt/0ew Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6@PRVPEXVS15.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6PRVPEXVS15cor_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:04:06 -0000 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6PRVPEXVS15cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll echo Russ and Joel's comments - we need to resolve the question of sco= pe as it regards section 2 and existing BGP config vs focusing more tightly= on topology-aware routing manipulation and identifying where we can do som= ething to extend our current capabilities instead of simply replacing CLI w= ith [yet another] something else. I think you could even make an argument = that 2.2 makes a valid use case based on improvements to policy configurati= on that you could make with better topology knowledge, while the earlier se= ctions might not be. I do understand that it might be entirely possible (or even better) to stan= dardize on one interface for all BGP config manipulation if you're already = building one for topology-aware manipulation, but I'd view that as a happy = side effect rather than a primary justification or goal, meaning that it wo= uld likely take a reduced form within the use cases draft. I think we need to address this *before* we adopt this as a WG item so that= we can stay focused on the right scope. Thanks, Wes George From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Wednesday, July 24, 2013 6:09 PM To: i2rs@ietf.org Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-0= 2 And I've lost the ability to spell - apparently. It's: draft-keyupate-i2rs-bgp-usecases-00 Alia On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas > wrote: Note that: draft-keyupdate-i2rs-bgp-usecases-00 has only the basic changes= from IRS to I2RS compared to draft-keyupdate-irs-bgp-usecases-02. Feel f= ree to review and comment on draft-keyupdate-i2rs-bgp-usecases-00 instead. Also - in this case, it is particularly important to have good conversation= and discussion on the draft (unless you believe it is perfect) - to help g= uide the co-authors on how to improve the draft. Regards, Alia On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas > wrote: Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether it= should be adopted by I2RS. Detailed technical conversation is also most w= elcome. Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-u= secases-02. Is so, has this IPR been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia ________________________________ 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. --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6PRVPEXVS15cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll echo Russ and = Joel’s comments – we need to resolve the question of scope as i= t regards section 2 and existing BGP config vs focusing more tightly on top= ology-aware routing manipulation and identifying where we can do something to extend o= ur current capabilities instead of simply replacing CLI with [yet another] = something else.  I think you could even make an argument that 2.2 make= s a valid use case based on improvements to policy configuration that you could make with better topology knowledge= , while the earlier sections might not be.

 <= /p>

I do understand that it m= ight be entirely possible (or even better) to standardize on one interface = for all BGP config manipulation if you’re already building one for topology-aware manipulation, but I’d view that as a happy si= de effect rather than a primary justification or goal, meaning that it woul= d likely take a reduced form within the use cases draft.

 <= /p>

I think we need to addres= s this *before* we adopt this as a WG item so that we can stay focus= ed on the right scope.

 <= /p>

Thanks,=

 <= /p>

Wes George

 <= /p>

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 6:09 PM
To: i2rs@ietf.org
Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-use= cases-02

 

And I've lost the ability to spell - apparently.&nbs= p;

 

Alia

 

On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas <akatlas@gmail.com>= ; wrote:

Note that:  draft-keyupdate-i2rs-bgp-usecases-0= 0 has only the basic changes from IRS to I2RS compared to draft-keyupdate-i= rs-bgp-usecases-02.   Feel free to review and comment on draft-keyupda= te-i2rs-bgp-usecases-00 instead.

 

Also - in this case, it is particularly important to= have good conversation and discussion on the draft (unless you believe it = is perfect) - to help guide the co-authors on how to improve the draft.

 

Regards,

Alia

 

 

 

On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas <akatlas@gmail.com>= ; wrote:

Please review draft-keyupdate-irs-b= gp-usecases-02 and comment on whether it should be adopted by I2RS. &n= bsp;Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-keyupdate-i= rs-bgp-usecases-02.  Is so, has this IPR been disclosed in compliance = with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= /span>

This WG call for adoption will complete on August 12.

Thanks,
Alia

 

 


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6PRVPEXVS15cor_-- From keyupate@cisco.com Thu Jul 25 14:55:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88F21F90FD for ; Thu, 25 Jul 2013 14:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfYXovMwjZhM for ; Thu, 25 Jul 2013 14:55:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4088E21F9294 for ; Thu, 25 Jul 2013 14:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15369; q=dns/txt; s=iport; t=1374789320; x=1375998920; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ZL+jUFG/gZtuIGQ56jXp+z3zzi/Bwo15MvEueVxR5SA=; b=ZJrnoT6ZQFGSr7h4r30U08urhBS7bDLHrhcgcblmtS0DhmDw4bURCjV/ Lj+JJktswNa2oyVRJ2VOt/GMk9ghe9QfGW4LgDI01O3Xoj7BnY7lLeXi+ RMKsrGdEm3p9erZGYQOrhwTPCsnfGq6vETjY9MTR5wW4cL0Gcz8xYJ31Z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAFqd8VGtJXG+/2dsb2JhbABagkJENVC9YYEXFnSCJAEBAQQBAQEaEEEEGQEIEQMBAQELHSgGCxQJCAIEARIIh3YDDwywIg2IWgSNFYE5fiAMAQoBgxJuA5V2jhCFJoMUgXE5 X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208,217";a="239410472" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2013 21:55:19 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6PLtJ8V015802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jul 2013 21:55:19 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.8]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 16:55:19 -0500 From: "Keyur Patel (keyupate)" To: "George, Wes" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 Thread-Index: AQHOiLp4eV3t8ptF+0u77nxIQJndjpl2N1QA//+ZZgA= Date: Thu, 25 Jul 2013 21:55:18 +0000 Message-ID: <4931A85EED76CA48BD52F2D94E7FAB0E088973F2@xmb-aln-x09.cisco.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592304393EDAB6@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.33.12.54] Content-Type: multipart/alternative; boundary="_000_4931A85EED76CA48BD52F2D94E7FAB0E088973F2xmbalnx09ciscoc_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 21:55:25 -0000 --_000_4931A85EED76CA48BD52F2D94E7FAB0E088973F2xmbalnx09ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Wes, We can definitely cleanup section 2.1 if the wg believes that the protocol = configuration is outside the scope of i2rs. That would address both, Joel a= nd Russ's concern as well. Best Regards, Keyur From: "George, Wes" > Date: Thu, 25 Jul 2013 17:04:00 -0400 To: Alia Atlas >, "i2rs@ietf.or= g" > Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-0= 2 I=92ll echo Russ and Joel=92s comments =96 we need to resolve the question = of scope as it regards section 2 and existing BGP config vs focusing more t= ightly on topology-aware routing manipulation and identifying where we can = do something to extend our current capabilities instead of simply replacing= CLI with [yet another] something else. I think you could even make an arg= ument that 2.2 makes a valid use case based on improvements to policy confi= guration that you could make with better topology knowledge, while the earl= ier sections might not be. I do understand that it might be entirely possible (or even better) to stan= dardize on one interface for all BGP config manipulation if you=92re alread= y building one for topology-aware manipulation, but I=92d view that as a ha= ppy side effect rather than a primary justification or goal, meaning that i= t would likely take a reduced form within the use cases draft. I think we need to address this *before* we adopt this as a WG item so that= we can stay focused on the right scope. Thanks, Wes George From: i2rs-bounces@ietf.org [mailto:i2rs-boun= ces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, July 24, 2013 6:09 PM To: i2rs@ietf.org Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-0= 2 And I've lost the ability to spell - apparently. It's: draft-keyupate-i2rs-bgp-usecases-00 Alia On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas > wrote: Note that: draft-keyupdate-i2rs-bgp-usecases-00 has only the basic changes= from IRS to I2RS compared to draft-keyupdate-irs-bgp-usecases-02. Feel f= ree to review and comment on draft-keyupdate-i2rs-bgp-usecases-00 instead. Also - in this case, it is particularly important to have good conversation= and discussion on the draft (unless you believe it is perfect) - to help g= uide the co-authors on how to improve the draft. Regards, Alia On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas > wrote: Please review draft-keyupdate-irs-bgp-usecases-02 and comment on whether it= should be adopted by I2RS. Detailed technical conversation is also most w= elcome. Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-u= secases-02. Is so, has this IPR been disclosed in compliance with IETF IPR= rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia ________________________________ 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 https://www.ietf.org/mailman/listinfo/i2rs --_000_4931A85EED76CA48BD52F2D94E7FAB0E088973F2xmbalnx09ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Wes,

We can definitely cleanup section 2.1 if the wg believes that the prot= ocol configuration is outside the scope of i2rs. That would address both, J= oel and Russ's concern as well. 

Best Regards,
Keyur


From: "George, Wes" <<= a href=3D"mailto:wesley.george@twcable.com">wesley.george@twcable.com&g= t;
Date: Thu, 25 Jul 2013 17:04:00 -04= 00
To: Alia Atlas <akatlas@gmail.com>, "i2rs@ietf.org" <i2= rs@ietf.org>
Subject: Re: [i2rs] Call for WG Ado= ption: draft-keyupate-irs-bgp-usecases-02

I=92ll echo Russ and Joel=92s comm= ents =96 we need to resolve the question of scope as it regards section 2 a= nd existing BGP config vs focusing more tightly on topology-aware routing manipulation and identifying where we can do som= ething to extend our current capabilities instead of simply replacing CLI w= ith [yet another] something else.  I think you could even make an argu= ment that 2.2 makes a valid use case based on improvements to policy configuration that you could make with bet= ter topology knowledge, while the earlier sections might not be.=

 

I do understand that it might be e= ntirely possible (or even better) to standardize on one interface for all B= GP config manipulation if you=92re already building one for topology-aware manipulation, but I=92d view that as a hap= py side effect rather than a primary justification or goal, meaning that it= would likely take a reduced form within the use cases draft.

 

I think we need to address this *<= b>before* we adopt this as a WG item so that we can stay focused on the= right scope.

 

Thanks,

 

Wes George

 

 

From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 6:09 PM
To: i2rs@ietf.org
Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-use= cases-02

 

And I've lost the ability to spell - apparently.&nbs= p;

 

Alia

 

On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas <akatlas@gmail.com>= ; wrote:

Note that:  draft-keyupdate-i2rs-bgp-usecases-0= 0 has only the basic changes from IRS to I2RS compared to draft-keyupdate-i= rs-bgp-usecases-02.   Feel free to review and comment on draft-keyupda= te-i2rs-bgp-usecases-00 instead.

 

Also - in this case, it is particularly important to= have good conversation and discussion on the draft (unless you believe it = is perfect) - to help guide the co-authors on how to improve the draft.

 

Regards,

Alia

 

 

 

On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas <akatlas@gmail.com>= ; wrote:

Please review draft-keyupdate-irs-bgp-usecases-02 and comment on wheth= er it should be adopted by I2RS.  Detailed technical conversation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02.&= nbsp; Is so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia

 

 


This E-mail and any of its a= ttachments 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 a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
_______________________________________________ i2rs mailing list i2rs@ietf.org ht= tps://www.ietf.org/mailman/listinfo/i2rs --_000_4931A85EED76CA48BD52F2D94E7FAB0E088973F2xmbalnx09ciscoc_-- From jrmitche@puck.nether.net Thu Jul 25 15:13:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FC21F84CD for ; Thu, 25 Jul 2013 15:13:31 -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=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZf6bNcMSG4Y for ; Thu, 25 Jul 2013 15:13:30 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 529CD21F84BB for ; Thu, 25 Jul 2013 15:13:30 -0700 (PDT) Received: from [10.249.171.250] (75.sub-174-255-32.myvzw.com [174.255.32.75]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6PMDJVF000964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Jul 2013 18:13:21 -0400 References: <2671C6CDFBB59E47B64C10B3E0BD592304393EDA61@PRVPEXVS15.corp.twcable.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592304393EDA61@PRVPEXVS15.corp.twcable.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2A852682-3062-406F-A1BC-D66C3251371B Content-Transfer-Encoding: 7bit Message-Id: <2AFA3622-82FF-4D7F-995F-9DB17B27544E@puck.nether.net> X-Mailer: iPhone Mail (10B329) From: Jon Mitchell Date: Thu, 25 Jul 2013 18:13:17 -0400 To: "George, Wes" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [204.42.254.5]); Thu, 25 Jul 2013 18:13:28 -0400 (EDT) Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 22:13:31 -0000 --Apple-Mail-2A852682-3062-406F-A1BC-D66C3251371B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Support adoption but also agree with Wes's suggestion. -Jon On Jul 25, 2013, at 4:40 PM, "George, Wes" wrote= : > I have some concerns about 6.1 in terms of whether it could be interpreted= as a definite statement of direction that we=E2=80=99ll be building a new p= rotocol rather than identifying one to modify for use here, which I think is= in conflict with section 5 of the problem statement. > I agree that cobbling together several protocols that weren=E2=80=99t mean= t to be integrated isn=E2=80=99t necessarily a good solution when compared w= ith a single protocol, so I think this may be a wording problem in the curre= nt text, rather than a philosophical disagreement, but it=E2=80=99s worth co= nfirming that before we adopt this draft. If I=E2=80=99m right that it=E2=80= =99s just a wording issue, it may be as simple as adding the same words from= the problem statement:=20 > =E2=80=9CWhether such a protocol is built upon extending > existing mechanisms or requires a new mechanism requires further > investigation.=E2=80=9C > =20 > Otherwise I think it=E2=80=99s in good shape. > =20 > Thanks, > =20 > Wes George > =20 > =20 > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Al= ia Atlas > Sent: Wednesday, July 24, 2013 5:52 PM > To: i2rs@ietf.org > Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (= ends Aug 12) > =20 > Please review draft-atlas-i2rs-architecture-01 and comment on whether it s= hould be adopted by I2RS. Detailed technical conversation is also most welc= ome. >=20 > Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-archite= cture-01? Is so, has this IPR been disclosed in compliance with IETF IPR rul= es (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia >=20 > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd 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 immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-2A852682-3062-406F-A1BC-D66C3251371B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Support adoption but al= so agree with Wes's suggestion.

-Jon

On Jul 25, 2013, a= t 4:40 PM, "George, Wes" <we= sley.george@twcable.com> wrote:

=

I have some concerns about 6= .1 in terms of whether it could be interpreted as a definite statement of di= rection that we=E2=80=99ll be building a new protocol rather than identifying one to modify for use here, which I think is in conflict w= ith section 5 of the problem statement. 

I agree th=
at cobbling together several protocols that weren=E2=80=99t meant to be inte=
grated isn=E2=80=99t necessarily a good solution when compared with a single=
 protocol, so I think this may be a wording problem in the current text, rat=
her than a philosophical disagreement, but it=E2=80=99s worth confirming tha=
t before we adopt this draft. If I=E2=80=99m right that it=E2=80=99s just a w=
ording issue, it may be as simple as adding the same words from the problem s=
tatement: 
 &nbs=
p;       =E2=80=9CWhether such a protocol is built upon extending=

   existing mechanis= ms or requires a new mechanism requires further

   investigation.=E2=80=9C

 

Otherwise I think it=E2=80=99= s in good shape.

 

Thanks,

 

Wes George

 

 

From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, July 24, 2013 5:52 PM
To: i2rs@ietf.org
Subject: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architectur= e-01 (ends Aug 12)

 

Please review draft-atlas-i2rs-architecture-01 and co= mment on whether it should be adopted by I2RS.  Detailed technical conv= ersation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-architect= ure-01? Is so, has this IPR been disclosed in compliance with IETF IPR rules= (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia


This E-mail and any of its at= tachments may contain Time Warner Cable proprietary information, which is pr= ivileged, confidential, or subject to copyright belonging to Time Warner Cab= le. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you ar= e not the intended recipient of this E-mail, you are hereby notified that an= y dissemination, distribution, copying, or action taken in relation to the c= ontents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receive= d this E-mail in error, please notify the sender immediately and permanently= delete the original and any copy of this E-mail and any printout.
____________________= ___________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman= /listinfo/i2rs
= --Apple-Mail-2A852682-3062-406F-A1BC-D66C3251371B-- From sriganeshkini@gmail.com Thu Jul 25 16:57:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E904521F84A8 for ; Thu, 25 Jul 2013 16:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGGEGQq2LvVZ for ; Thu, 25 Jul 2013 16:57:48 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A121F8546 for ; Thu, 25 Jul 2013 16:57:42 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so1351781pab.7 for ; Thu, 25 Jul 2013 16:57: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:from:date:message-id:subject:to :cc:content-type; bh=jS/hbsE3EeOiISp2WvV7uGopPheEIrkSRJOUlqJp7Gc=; b=LTWxqu3QXf0wWx1QJpArX/2H3JTJ+lo3vMJMvRtzQ6RpIZYCxXT9Qtth+bVeOZ7iu8 UT27wfU+30SDODSxqrt0NIliQGX+K0hxxxclaEtZzCjAuDQ6b62TIxgxGRJgx9tV5VU0 13OzBfIpZJTmr7DiapakPP1aXif2c3sBuWT0cGKQRj1RzYQvEMAU9rT6ZXp0ab24HLDJ ZqFe7+UNoieDVWWNh+CnWVeURX/ZFYVaVqLrvuwUBgN5RrADi94VZ2ymiUvKGZi9a9ih 0truCZBsfAihRIhWnU4yiBFtE9Keqyir+730LzUMCqQ1S6rLPWN7wwCE7bJjUmy2DKB+ pHcQ== X-Received: by 10.66.218.74 with SMTP id pe10mr44281400pac.177.1374796662410; Thu, 25 Jul 2013 16:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.52.162 with HTTP; Thu, 25 Jul 2013 16:57:12 -0700 (PDT) In-Reply-To: <51F090D6.8080002@joelhalpern.com> References: <51F090D6.8080002@joelhalpern.com> From: Sri Date: Thu, 25 Jul 2013 16:57:12 -0700 Message-ID: To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b5d9de9b3927204e25ecac6 Cc: "i2rs@ietf.org" , Nitin Bahadur , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 23:57:50 -0000 --047d7b5d9de9b3927204e25ecac6 Content-Type: text/plain; charset=UTF-8 Hi Joel, You seem to be pointing to two issues that need a better definition - 1) The RIB whose IM is being described in this doc (as opposed to all other XXX-RIBs in a router) 2) The routing-instance that is defined in this doc as part of the RIB as opposed to a more general understanding of a routing-instance. First let me try to clarify some statements to see if there is agreement and then we can cobble together some wording around it for the draft - 0. A router can be thought of as an I2RS agent endpoint. This definition is outside the scope of this document, but it may help to understand the RIB IM in relation to I2RS. 1. There is a single RIB in a router. When referred to in the context of a router, this RIB is unqualified. The IM in this draft is describing this RIB. 2. A router has zero or more routing instances. Each routing instance will have its own RIB. This RIB is unqualified in the context of that routing instance, but is qualified by the routing-instance name when in the context of the router (e.g. core.RIB or VPN_X.RIB). We can further qualify by the type i.e. the routing-instance (e.g. routing_instance.core.RIB) if there are separate namespaces for routing-instance names and say protocols, but this is a minor point. 3. The collection of the RIBs of all the routing-instances in the router is the RIB (i.e., the RIB defined in 1.) 4. Other RIBs e.g. the BGP RIB-in of a routing instance has to be qualified further within the routing instance and hence is not part of the RIB (i.e. the RIB defined in 1.). So you will have routing_instance.core.bgp-in.RIB to describe BGPs RIB-in for that instance. All such XXX-RIB IMs are outside the scope of this draft. 5. To summarize, the RIB in 1. in words - This document describes the IM of the RIB of a router. A router has a single RIB. A router consists of multiple routing instances and each routing-instance has a RIB. The router's RIB consists of the collection of RIBs of all the routing-instances of the router. A routing-instance's RIB consists of routes added by zero or more routing/signaling/static protocols of that routing instance. Routes added by one instance can be resolved via routes in other instances and this relationship is reflected in the RIB. The RIB-manager manages all the routes in the RIB and executes the policies to recursively resolve the routes according to the capabilities of the forwarding hardware. It also downloads the routes to the FIB. The RIB-manager also executes policies to re-distribute routes across protocols. Let me know if this helps. On Wed, Jul 24, 2013 at 7:43 PM, Joel M. Halpern wrote: > This seems a different use of the term RIB than most of the work I am > familiar with. Even without dealing with things like protocol specific > RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally > discuss them as using separate RIBs. This is why the terminology seems > upside-down to me. > > Yours, > Joel > > > On 7/24/13 10:21 PM, Nitin Bahadur wrote: > >> Hi Joel, >> >> Maybe this can help clarify what we meant by the RIB. >> >> The RIB is the totality of all routing-information in a router. The >> routing information itself can be sub-divided into multiple objects called >> routing-instances. >> >> Routing-instances allow us to partition the physical router into domains >> that can operate independently from one another in terms of routing and >> forwarding. >> >> >> The rest of that section describes what objects are contained in a RIB, >> like routing tables, routes and nexthops. >> >> >> HTH as a starting point. >> Nitin Bahadur >> >> >> >> >> >> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >> >> Asking for a text proposal is quite reasonable. >>> Unfortunately, since my oncern is taht I can not understand what is >>> meant by RIB in this definition, it is really ahrd to propose an >>> alternative set of definitions that do what the authors wanted. >>> >>> Yours, >>> Joel >>> >>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>> >>>> Joel, >>>> >>>> I understand your concern. Do you have text to suggest to Nitin and >>>> co-authors? >>>> I think part of this is figuring out how to pull out the RIB bits >>>> (routing tables) and what traffic they apply to - as well as the policy >>>> of how to create associated containers. Nitin's called that a routing >>>> instance... >>>> >>>> What set of objects would you create? >>>> >>>> I personally would like to see the info-model described in something >>>> other than rBNF - but I view that as a piece that can happen in a future >>>> version. >>>> >>>> Alia >>>> >>>> >>>> >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>> > wrote: >>>> >>>> Looking again at this document, I have to reluctantly say taht I do >>>> not support adoption of this document at this time. >>>> >>>> The base definition of RIB is still very unclear. A RIB is some >>>> collection of routing instances? First, this seems upside-down to >>>> me. A routing instance would seem to contain a RIB, not the other >>>> way around. Secondly, what defines, describes, or otherwise helps >>>> decide what set of routing instances go in the same RIB. >>>> >>>> If this issue were clarified, I believe the rest of the material is >>>> in sufficiently good shape for working group adoption. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> >>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>> >>>> Please review draft-nitinb-i2rs-rib-info-__**model-01 and >>>> comment >>>> on whether >>>> it should be adopted by I2RS. Detailed technical conversation >>>> is also >>>> most welcome. >>>> >>>> Authors: Are you aware of any IPR that applies >>>> to draft-nitinb-i2rs-rib-info-__**model-01 Is so, has this >>>> IPR >>>> been >>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>> 4879, 3669 >>>> and 5378 for more details). >>>> >>>> This WG call for adoption will complete on August 12. >>>> >>>> Thanks, >>>> Alia >>>> >>>> >>>> ______________________________**___________________ >>>> 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 > --047d7b5d9de9b3927204e25ecac6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joel,

You seem to be = pointing to two issues that need a better definition -
1) The RIB= whose IM is being described in this doc (as opposed to all other XXX-RIBs = in a router)=C2=A0
2) The routing-instance that is defined in this = doc as part of the RIB as opposed to a more general understanding of a rout= ing-instance.

First let me try to clarify some statements to see if = there is agreement and then we can cobble together some wording around it f= or the draft -
0. A router can be thought of as an I2RS agent e= ndpoint. This definition is outside the scope of this document, but it may = help to understand the RIB IM in relation to I2RS.
1. There is a single RIB in a router. When referred to in the context of a = router, this RIB is unqualified. The IM in this draft is describing this RI= B.
2. A router has zero or more routing ins= tances. Each routing instance will have its own RIB. This RIB is unqualifie= d in the context of that routing instance, but is qualified by the routing-= instance name when in the context of the router (e.g. core.RIB or VPN_X.RIB= ). We can further qualify by the type i.e. the routing-instance (e.g. routi= ng_instance.core.RIB) if there are separate namespaces for routing-instance= names and say protocols, but this is a minor point.
3. The collection of the RIBs of all the routing= -instances in the router is the RIB (i.e., the RIB defined in 1.)
4. Other RIBs e.g. the BGP RIB-in of a routing insta= nce has to be qualified further within the routing instance and hence is no= t part of the RIB (i.e. the RIB defined in 1.). So you will have routing_in= stance.core.bgp-in.RIB to describe BGPs RIB-in for that instance. All such = XXX-RIB IMs are outside the scope of this draft.
5. To summarize, the RIB in 1. in words - This d= ocument describes the IM of the RIB of a router. A router has a single RIB.= A router consists of multiple routing instances and each routing-instance = has a RIB. The router's RIB consists of the collection of RIBs of all t= he routing-instances of the router. A routing-instance's RIB consists o= f routes added by zero or more routing/signaling/static protocols of that r= outing instance. Routes added by one instance can be resolved via routes in= other instances and this relationship is reflected in the RIB. The RIB-man= ager manages all the routes in the RIB and executes the policies to recursi= vely resolve the routes according to the capabilities of the forwarding har= dware. It also downloads the routes to the FIB. The RIB-manager also execut= es policies to re-distribute routes across protocols.


Let me = know if this helps.


On Wed, Jul 24, 2= 013 at 7:43 PM, Joel M. Halpern <jmh@joelhalpern.com> wrot= e:
This seems a different use of the term RIB t= han most of the work I am familiar with. =C2=A0Even without dealing with th= ings like protocol specific RIBs, and BGP's RIB-in and RIB-out, when we= deal with VRFs we normally discuss them as using separate RIBs. =C2=A0This= is why the terminology seems upside-down to me.

Yours,
Joel


On 7/24/13 10:21 PM, Nitin Bahadur wrote:
Hi Joel,

=C2=A0 =C2=A0 Maybe this can help clarify what we meant by the RIB.

The RIB is the totality of all routing-information in a router. The
routing information itself can be sub-divided into multiple objects called<= br> routing-instances.

Routing-instances allow us to partition the physical router into domains that can operate independently from one another in terms of routing and
forwarding.


The rest of that section describes what objects are contained in a RIB,
like routing tables, routes and nexthops.


HTH as a starting point.
Nitin Bahadur





On 7/24/13 3:19 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

Asking for a text proposal is quite reasonable.
Unfortunately, since my oncern is taht I can not understand what is
meant by RIB in this definition, it is really ahrd to propose an
alternative set of definitions that do what the authors wanted.

Yours,
Joel

On 7/24/13 6:16 PM, Alia Atlas wrote:
Joel,

I understand your concern. =C2=A0Do you have text to suggest to Nitin and co-authors?
I think part of this is figuring out how to pull out the RIB bits
(routing tables) and what traffic they apply to - as well as the policy
of how to create associated containers. =C2=A0Nitin's called that a rou= ting
instance...

What set of objects would you create?

I personally would like to see the info-model described in something
other than rBNF - but I view that as a piece that can happen in a future version.

Alia



On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 =C2=A0Looking again at this document, I have to reluctantly s= ay taht I do
=C2=A0 =C2=A0 =C2=A0not support adoption of this document at this time.

=C2=A0 =C2=A0 =C2=A0The base definition of RIB is still very unclear. =C2= =A0A RIB is some
=C2=A0 =C2=A0 =C2=A0collection of routing instances? =C2=A0First, this seem= s upside-down to
=C2=A0 =C2=A0 =C2=A0me. A routing instance would seem to contain a RIB, not= the other
=C2=A0 =C2=A0 =C2=A0way around. =C2=A0Secondly, what defines, describes, or= otherwise helps
=C2=A0 =C2=A0 =C2=A0decide what set of routing instances go in the same RIB= .

=C2=A0 =C2=A0 =C2=A0If this issue were clarified, I believe the rest of the= material is
=C2=A0 =C2=A0 =C2=A0in sufficiently good shape for working group adoption.<= br>
=C2=A0 =C2=A0 =C2=A0Yours,
=C2=A0 =C2=A0 =C2=A0Joel M. Halpern


=C2=A0 =C2=A0 =C2=A0On 7/24/13 5:55 PM, Alia Atlas wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please review draft-nitinb-i2rs-rib-info-= __model-01 and comment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on whether
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it should be adopted by I2RS. =C2=A0Detai= led technical conversation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is also
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0most welcome.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors: Are you aware of any IPR that ap= plies
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to draft-nitinb-i2rs-rib-info-__mo= del-01 =C2=A0Is so, has this IPR
been
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0disclosed in compliance with IETF IPR rul= es (see RFCs 3979,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04879, 3669
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 5378 for more details).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This WG call for adoption will complete o= n August 12.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alia


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__________________________________= _______________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i2rs@ietf.org <mailto:i2rs@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/__lis= tinfo/i2rs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/lis= tinfo/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

--047d7b5d9de9b3927204e25ecac6-- From ietfc@btconnect.com Fri Jul 26 08:40:44 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6A21F99AB for ; Fri, 26 Jul 2013 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm0t6c0kfYQF for ; Fri, 26 Jul 2013 08:40:32 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 68DDA11E80F3 for ; Fri, 26 Jul 2013 08:40:32 -0700 (PDT) Received: from mail22-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 26 Jul 2013 15:40:31 +0000 Received: from mail22-tx2 (localhost [127.0.0.1]) by mail22-tx2-R.bigfish.com (Postfix) with ESMTP id 6ED924200F3; Fri, 26 Jul 2013 15:40:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL1de097h1de096h8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail22-tx2 (localhost.localdomain [127.0.0.1]) by mail22-tx2 (MessageSwitch) id 1374853228765670_25099; Fri, 26 Jul 2013 15:40:28 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.229]) by mail22-tx2.bigfish.com (Postfix) with ESMTP id B5126260049; Fri, 26 Jul 2013 15:40:28 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 26 Jul 2013 15:40:28 +0000 Received: from DB3PRD0511HT004.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 26 Jul 2013 15:40:16 +0000 Message-ID: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> From: t.petch To: Nitin Bahadur References: <51F090D6.8080002@joelhalpern.com> Date: Fri, 26 Jul 2013 16:39:30 +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.254.213] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: i2rs@ietf.org, Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:40:44 -0000 I oppose adoption of this I-D. The use of terminology seems incompatible with the use of the same terminology elsewhere and, arguably, contradicts the charter. For example, this I-D says " A RIB contains one or more routing instances. A routing instance, in the context of the RIB information model, is a collection of routing tables, interfaces, and routing parameters. The routing tables specify how incoming traffic is to be forwarded." whereas the charter clearly differentiates the RIB, which is the subject of this WG, from the FIB, which is not. The reference here to routing tables sounds rather like a FIB. (Of course, the charter fails to define RIB and FIB which is likely to be a recurrent problem for all the work of this WG unless and until rough consensus is achieved thereon.) And the I-D places heavy emphasis on interfaces which again seems to have nothing to do with the charter. This topic has surfaced several times on several WG lists, none of which has produced an agreed document, but the best one would appear to me to agree that there are processes, not just data, and that these processes are tied to routing protocols, and that the data thereof needs to be split into three - a RIB (in the sense that I most often see it used) containing the data used by a protocol process instance - a central database of consolidated routes, sometime referred to as RIB2 - what gets used in forwarding, usually by the silicon. Routing table and FIB I see used arbitrarily and so confusingly used for the second and third data structures. (I have no idea what the charter means in this regard). Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: "Nitin Bahadur" Cc: ; "Alia Atlas" Sent: Thursday, July 25, 2013 3:43 AM Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) > This seems a different use of the term RIB than most of the work I am > familiar with. Even without dealing with things like protocol specific > RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally > discuss them as using separate RIBs. This is why the terminology seems > upside-down to me. > > Yours, > Joel > > On 7/24/13 10:21 PM, Nitin Bahadur wrote: > > Hi Joel, > > > > Maybe this can help clarify what we meant by the RIB. > > > > The RIB is the totality of all routing-information in a router. The > > routing information itself can be sub-divided into multiple objects called > > routing-instances. > > > > Routing-instances allow us to partition the physical router into domains > > that can operate independently from one another in terms of routing and > > forwarding. > > > > > > The rest of that section describes what objects are contained in a RIB, > > like routing tables, routes and nexthops. > > > > > > HTH as a starting point. > > Nitin Bahadur > > > > > > > > > > > > On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: > > > >> Asking for a text proposal is quite reasonable. > >> Unfortunately, since my oncern is taht I can not understand what is > >> meant by RIB in this definition, it is really ahrd to propose an > >> alternative set of definitions that do what the authors wanted. > >> > >> Yours, > >> Joel > >> > >> On 7/24/13 6:16 PM, Alia Atlas wrote: > >>> Joel, > >>> > >>> I understand your concern. Do you have text to suggest to Nitin and > >>> co-authors? > >>> I think part of this is figuring out how to pull out the RIB bits > >>> (routing tables) and what traffic they apply to - as well as the policy > >>> of how to create associated containers. Nitin's called that a routing > >>> instance... > >>> > >>> What set of objects would you create? > >>> > >>> I personally would like to see the info-model described in something > >>> other than rBNF - but I view that as a piece that can happen in a future > >>> version. > >>> > >>> Alia > >>> > >>> > >>> > >>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>> > wrote: > >>> > >>> Looking again at this document, I have to reluctantly say taht I do > >>> not support adoption of this document at this time. > >>> > >>> The base definition of RIB is still very unclear. A RIB is some > >>> collection of routing instances? First, this seems upside-down to > >>> me. A routing instance would seem to contain a RIB, not the other > >>> way around. Secondly, what defines, describes, or otherwise helps > >>> decide what set of routing instances go in the same RIB. > >>> > >>> If this issue were clarified, I believe the rest of the material is > >>> in sufficiently good shape for working group adoption. > >>> > >>> Yours, > >>> Joel M. Halpern > >>> > >>> > >>> On 7/24/13 5:55 PM, Alia Atlas wrote: > >>> > >>> Please review draft-nitinb-i2rs-rib-info-__model-01 and comment > >>> on whether > >>> it should be adopted by I2RS. Detailed technical conversation > >>> is also > >>> most welcome. > >>> > >>> Authors: Are you aware of any IPR that applies > >>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR > >>> been > >>> disclosed in compliance with IETF IPR rules (see RFCs 3979, > >>> 4879, 3669 > >>> and 5378 for more details). > >>> > >>> This WG call for adoption will complete on August 12. > >>> > >>> Thanks, > >>> Alia > >>> > >>> > >>> _________________________________________________ > >>> 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 jrmitche@puck.nether.net Fri Jul 26 11:10:38 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3A811E8128 for ; Fri, 26 Jul 2013 11:10:38 -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=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzvTKDWHXFvt for ; Fri, 26 Jul 2013 11:10:37 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 60D8411E80F6 for ; Fri, 26 Jul 2013 11:10:37 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6QIAY9g010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2013 14:10:34 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6QIAXp3010695; Fri, 26 Jul 2013 14:10:33 -0400 Date: Fri, 26 Jul 2013 14:10:33 -0400 From: Jon Mitchell To: Sri Message-ID: <20130726181032.GA4322@puck.nether.net> References: <51F090D6.8080002@joelhalpern.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) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Fri, 26 Jul 2013 14:10:34 -0400 (EDT) Cc: "i2rs@ietf.org" , Nitin Bahadur , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:10:38 -0000 I also oppose WG adoption for some of the same reasons that Joel stated earlier. That said, there is some useful content in this document but I had some additional questions or concerns that could just be mis-reading of intent: Thanks, -Jon Section 2.1: paragraph 2 - "if the intersection MUST be the null set, then an interface MUST NOT be present in", current text using "should" seems inconsistent. fields - 1. If INSTANCE_NAME is required and the distinguisher by which you keep these tables seperate, why is INSTANCE_DISTINGUISHER also a required field? I could understand if you said INSTANCE_DISTINGUISHER actually was exactly the BGP RD instead of could be mapped "well" to it. However even then it's not clear this is required outside of a L3VPN context. On the other hand if INSTANCE_NAME is NOT required and is really meant to be an optional user friendly name, then perhaps you mean INSTANCE_DISTINGUISHER MUST be unique rather than SHOULD be. 2. A paragraph break seperating mandatory and optional fields would be really helpful, I thought this was one bullet list on first pass. 3. ROUTER_ID seems protocol specific (although many implementations allow you to set one globally to apply to multiple protocols). Does it make sense to expose this to the data model if protocol manipulation and configuration are out of scope? Also the mention of virtual routers here seems odd in that one could also imagine virtual routers would have seperate i2rs interfaces. ISO_SYSTEM_ID seems even more circumspect, if that, why not BGP ASN and all kinds of other protocol details? 4. as_data doesn't make any sense to me here, can you elaborate? If the goal is to apply some sort of generic tag to routes in this routing instance maybe a local implementation tag/color/blah is what you meant here? Unless i2rs is focused on BGP protocol manipulation it doesn't seem that RIB manager is likely to use AS length as a determining factor for route selection (later in the doc it appears route preference and metric are the deciding factor which seems more consistent with my understanding of a RIB). Section 2.3: 1. LOCAL_ONLY - I wonder if the word RIB in this description is used in the common meaning rather than the document's definition? 2. as-path - This makes me wonder if this draft is optimized around specific vendor implementations that export BGP attributes to the RIB (common definition) rather than keeping them in the bRIB. Even if this is the case, does this imply we should include other BGP attributes as well, why limit it to as-path? Section 2.4.1: A large portion of this section seems to suggest things that are FIB, not RIB manipulation, for instance recursive next hops and the mention of multiple headers. Multiple headers may have to be installed in the FIB as a router consults a RIB and finds a nexthop that also leads to the RIB (and not a local interface of some kind) but this wording seems to suggest it can be programmed directly in one entry rather than by consulting the RIB again when it's non-local. This seems to be out of scope for i2rs? Section 2.4.2: I'm a bit unclear if this is in scope for RIB or FIB either, but assuming it is in scope, should LOAD_BALANCE_WEIGHT mention that PROTECTION_PREFERENCE must be equal? In other words, these two items don't appear to be mutually exclusive to me, however it doesn't explicitely state if they are in this model or if they aren't, how to deal a set of nexthops with both attributes. Section 2.4.3: Is writing destination MAC in scope for this WG? Or is this mean to be a specified nexthop IP like you may have for a static route in traditioanl CLI config? If it's an IPv4 entry and only a MAC is specified what is written in the destination IP address? Section 2.4.4.1: These seem MPLS specific and typically is a signalling function? On 25/07/13 16:57 -0700, Sri wrote: > > You seem to be pointing to two issues that need a better definition - > 1) The RIB whose IM is being described in this doc (as opposed to all other > XXX-RIBs in a router) > 2) The routing-instance that is defined in this doc as part of the RIB as > opposed to a more general understanding of a routing-instance. > > First let me try to clarify some statements to see if there is agreement > and then we can cobble together some wording around it for the draft - > 0. A router can be thought of as an I2RS agent endpoint. This definition is > outside the scope of this document, but it may help to understand the RIB > IM in relation to I2RS. > 1. There is a single RIB in a router. When referred to in the context of a > router, this RIB is unqualified. The IM in this draft is describing this > RIB. > 2. A router has zero or more routing instances. Each routing instance will > have its own RIB. This RIB is unqualified in the context of that routing > instance, but is qualified by the routing-instance name when in the context > of the router (e.g. core.RIB or VPN_X.RIB). We can further qualify by the > type i.e. the routing-instance (e.g. routing_instance.core.RIB) if there > are separate namespaces for routing-instance names and say protocols, but > this is a minor point. > 3. The collection of the RIBs of all the routing-instances in the router is > the RIB (i.e., the RIB defined in 1.) > 4. Other RIBs e.g. the BGP RIB-in of a routing instance has to be qualified > further within the routing instance and hence is not part of the RIB (i.e. > the RIB defined in 1.). So you will have routing_instance.core.bgp-in.RIB > to describe BGPs RIB-in for that instance. All such XXX-RIB IMs are outside > the scope of this draft. > 5. To summarize, the RIB in 1. in words - This document describes the IM of > the RIB of a router. A router has a single RIB. A router consists of > multiple routing instances and each routing-instance has a RIB. The > router's RIB consists of the collection of RIBs of all the > routing-instances of the router. A routing-instance's RIB consists of > routes added by zero or more routing/signaling/static protocols of that > routing instance. Routes added by one instance can be resolved via routes > in other instances and this relationship is reflected in the RIB. The > RIB-manager manages all the routes in the RIB and executes the policies to > recursively resolve the routes according to the capabilities of the > forwarding hardware. It also downloads the routes to the FIB. The > RIB-manager also executes policies to re-distribute routes across protocols. > > > Let me know if this helps. > > > On Wed, Jul 24, 2013 at 7:43 PM, Joel M. Halpern wrote: > > > This seems a different use of the term RIB than most of the work I am > > familiar with. Even without dealing with things like protocol specific > > RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally > > discuss them as using separate RIBs. This is why the terminology seems > > upside-down to me. > > > > Yours, > > Joel > > > > > > On 7/24/13 10:21 PM, Nitin Bahadur wrote: > > > >> Hi Joel, > >> > >> Maybe this can help clarify what we meant by the RIB. > >> > >> The RIB is the totality of all routing-information in a router. The > >> routing information itself can be sub-divided into multiple objects called > >> routing-instances. > >> > >> Routing-instances allow us to partition the physical router into domains > >> that can operate independently from one another in terms of routing and > >> forwarding. > >> > >> > >> The rest of that section describes what objects are contained in a RIB, > >> like routing tables, routes and nexthops. > >> > >> > >> HTH as a starting point. > >> Nitin Bahadur > >> > >> > >> > >> > >> > >> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: > >> > >> Asking for a text proposal is quite reasonable. > >>> Unfortunately, since my oncern is taht I can not understand what is > >>> meant by RIB in this definition, it is really ahrd to propose an > >>> alternative set of definitions that do what the authors wanted. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/24/13 6:16 PM, Alia Atlas wrote: > >>> > >>>> Joel, > >>>> > >>>> I understand your concern. Do you have text to suggest to Nitin and > >>>> co-authors? > >>>> I think part of this is figuring out how to pull out the RIB bits > >>>> (routing tables) and what traffic they apply to - as well as the policy > >>>> of how to create associated containers. Nitin's called that a routing > >>>> instance... > >>>> > >>>> What set of objects would you create? > >>>> > >>>> I personally would like to see the info-model described in something > >>>> other than rBNF - but I view that as a piece that can happen in a future > >>>> version. > >>>> > >>>> Alia > >>>> > >>>> > >>>> > >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>>> > wrote: > >>>> > >>>> Looking again at this document, I have to reluctantly say taht I do > >>>> not support adoption of this document at this time. > >>>> > >>>> The base definition of RIB is still very unclear. A RIB is some > >>>> collection of routing instances? First, this seems upside-down to > >>>> me. A routing instance would seem to contain a RIB, not the other > >>>> way around. Secondly, what defines, describes, or otherwise helps > >>>> decide what set of routing instances go in the same RIB. > >>>> > >>>> If this issue were clarified, I believe the rest of the material is > >>>> in sufficiently good shape for working group adoption. > >>>> > >>>> Yours, > >>>> Joel M. Halpern > >>>> > >>>> > >>>> On 7/24/13 5:55 PM, Alia Atlas wrote: > >>>> > >>>> Please review draft-nitinb-i2rs-rib-info-__**model-01 and > >>>> comment > >>>> on whether > >>>> it should be adopted by I2RS. Detailed technical conversation > >>>> is also > >>>> most welcome. > >>>> > >>>> Authors: Are you aware of any IPR that applies > >>>> to draft-nitinb-i2rs-rib-info-__**model-01 Is so, has this > >>>> IPR > >>>> been > >>>> disclosed in compliance with IETF IPR rules (see R > D"_blank">https://www.ietf.org/mailman/lis= > tinfo/i2rs>
>
>
> > _________________________ From shares@ndzh.com Sat Jul 27 13:52:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE311E80FD for ; Sat, 27 Jul 2013 13:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, J_CHICKENPOX_13=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHgQ3lTr+2cC for ; Sat, 27 Jul 2013 13:52: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 59B1B11E80F9 for ; Sat, 27 Jul 2013 13:52:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=46.189.28.56; From: "Susan Hares" To: "'Jon Mitchell'" , "'Sri'" References: <51F090D6.8080002@joelhalpern.com> <20130726181032.GA4322@puck.nether.net> In-Reply-To: <20130726181032.GA4322@puck.nether.net> Date: Sat, 27 Jul 2013 16:52:30 -0400 Message-ID: <025e01ce8b0b$36ca6ce0$a45f46a0$@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: AQHhh6Fz5FYVhh+QA6FoN0NB9TRNuANCy2kzAxd8pzABkatoIJkTmkaQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: i2rs@ietf.org, 'Nitin Bahadur' , "'Joel M. Halpern'" , 'Alia Atlas' Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:52:59 -0000 Jon, Nitin, and Joel: I too agree this draft is not ready for WG adoption. To move this forward, I would suggest that the draft get broken into two pieces: 1) What is a RIB and how i2rs will deal with it, and 2) RIB information model based on the first part. The difficulty with the merging of the two is that the work is that the WG needs to confirm #1 in order to get clarity with #2. Does this help? Sue -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Friday, July 26, 2013 2:11 PM To: Sri Cc: i2rs@ietf.org; Nitin Bahadur; Joel M. Halpern; Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) I also oppose WG adoption for some of the same reasons that Joel stated earlier. That said, there is some useful content in this document but I had some additional questions or concerns that could just be mis-reading of intent: Thanks, -Jon Section 2.1: paragraph 2 - "if the intersection MUST be the null set, then an interface MUST NOT be present in", current text using "should" seems inconsistent. fields - 1. If INSTANCE_NAME is required and the distinguisher by which you keep these tables seperate, why is INSTANCE_DISTINGUISHER also a required field? I could understand if you said INSTANCE_DISTINGUISHER actually was exactly the BGP RD instead of could be mapped "well" to it. However even then it's not clear this is required outside of a L3VPN context. On the other hand if INSTANCE_NAME is NOT required and is really meant to be an optional user friendly name, then perhaps you mean INSTANCE_DISTINGUISHER MUST be unique rather than SHOULD be. 2. A paragraph break seperating mandatory and optional fields would be really helpful, I thought this was one bullet list on first pass. 3. ROUTER_ID seems protocol specific (although many implementations allow you to set one globally to apply to multiple protocols). Does it make sense to expose this to the data model if protocol manipulation and configuration are out of scope? Also the mention of virtual routers here seems odd in that one could also imagine virtual routers would have seperate i2rs interfaces. ISO_SYSTEM_ID seems even more circumspect, if that, why not BGP ASN and all kinds of other protocol details? 4. as_data doesn't make any sense to me here, can you elaborate? If the goal is to apply some sort of generic tag to routes in this routing instance maybe a local implementation tag/color/blah is what you meant here? Unless i2rs is focused on BGP protocol manipulation it doesn't seem that RIB manager is likely to use AS length as a determining factor for route selection (later in the doc it appears route preference and metric are the deciding factor which seems more consistent with my understanding of a RIB). Section 2.3: 1. LOCAL_ONLY - I wonder if the word RIB in this description is used in the common meaning rather than the document's definition? 2. as-path - This makes me wonder if this draft is optimized around specific vendor implementations that export BGP attributes to the RIB (common definition) rather than keeping them in the bRIB. Even if this is the case, does this imply we should include other BGP attributes as well, why limit it to as-path? Section 2.4.1: A large portion of this section seems to suggest things that are FIB, not RIB manipulation, for instance recursive next hops and the mention of multiple headers. Multiple headers may have to be installed in the FIB as a router consults a RIB and finds a nexthop that also leads to the RIB (and not a local interface of some kind) but this wording seems to suggest it can be programmed directly in one entry rather than by consulting the RIB again when it's non-local. This seems to be out of scope for i2rs? Section 2.4.2: I'm a bit unclear if this is in scope for RIB or FIB either, but assuming it is in scope, should LOAD_BALANCE_WEIGHT mention that PROTECTION_PREFERENCE must be equal? In other words, these two items don't appear to be mutually exclusive to me, however it doesn't explicitely state if they are in this model or if they aren't, how to deal a set of nexthops with both attributes. Section 2.4.3: Is writing destination MAC in scope for this WG? Or is this mean to be a specified nexthop IP like you may have for a static route in traditioanl CLI config? If it's an IPv4 entry and only a MAC is specified what is written in the destination IP address? Section 2.4.4.1: These seem MPLS specific and typically is a signalling function? On 25/07/13 16:57 -0700, Sri wrote: > > You seem to be pointing to two issues that need a better definition - > 1) The RIB whose IM is being described in this doc (as opposed to all > other XXX-RIBs in a router) > 2) The routing-instance that is defined in this doc as part of the RIB > as opposed to a more general understanding of a routing-instance. > > First let me try to clarify some statements to see if there is > agreement and then we can cobble together some wording around it for > the draft - 0. A router can be thought of as an I2RS agent endpoint. > This definition is outside the scope of this document, but it may help > to understand the RIB IM in relation to I2RS. > 1. There is a single RIB in a router. When referred to in the context > of a router, this RIB is unqualified. The IM in this draft is > describing this RIB. > 2. A router has zero or more routing instances. Each routing instance > will have its own RIB. This RIB is unqualified in the context of that > routing instance, but is qualified by the routing-instance name when > in the context of the router (e.g. core.RIB or VPN_X.RIB). We can > further qualify by the type i.e. the routing-instance (e.g. > routing_instance.core.RIB) if there are separate namespaces for > routing-instance names and say protocols, but this is a minor point. > 3. The collection of the RIBs of all the routing-instances in the > router is the RIB (i.e., the RIB defined in 1.) 4. Other RIBs e.g. the > BGP RIB-in of a routing instance has to be qualified further within > the routing instance and hence is not part of the RIB (i.e. > the RIB defined in 1.). So you will have > routing_instance.core.bgp-in.RIB to describe BGPs RIB-in for that > instance. All such XXX-RIB IMs are outside the scope of this draft. > 5. To summarize, the RIB in 1. in words - This document describes the > IM of the RIB of a router. A router has a single RIB. A router > consists of multiple routing instances and each routing-instance has a > RIB. The router's RIB consists of the collection of RIBs of all the > routing-instances of the router. A routing-instance's RIB consists of > routes added by zero or more routing/signaling/static protocols of > that routing instance. Routes added by one instance can be resolved > via routes in other instances and this relationship is reflected in > the RIB. The RIB-manager manages all the routes in the RIB and > executes the policies to recursively resolve the routes according to > the capabilities of the forwarding hardware. It also downloads the > routes to the FIB. The RIB-manager also executes policies to re-distribute routes across protocols. > > > Let me know if this helps. > > > On Wed, Jul 24, 2013 at 7:43 PM, Joel M. Halpern wrote: > > > This seems a different use of the term RIB than most of the work I > > am familiar with. Even without dealing with things like protocol > > specific RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs > > we normally discuss them as using separate RIBs. This is why the > > terminology seems upside-down to me. > > > > Yours, > > Joel > > > > > > On 7/24/13 10:21 PM, Nitin Bahadur wrote: > > > >> Hi Joel, > >> > >> Maybe this can help clarify what we meant by the RIB. > >> > >> The RIB is the totality of all routing-information in a router. The > >> routing information itself can be sub-divided into multiple objects > >> called routing-instances. > >> > >> Routing-instances allow us to partition the physical router into > >> domains that can operate independently from one another in terms of > >> routing and forwarding. > >> > >> > >> The rest of that section describes what objects are contained in a > >> RIB, like routing tables, routes and nexthops. > >> > >> > >> HTH as a starting point. > >> Nitin Bahadur > >> > >> > >> > >> > >> > >> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: > >> > >> Asking for a text proposal is quite reasonable. > >>> Unfortunately, since my oncern is taht I can not understand what > >>> is meant by RIB in this definition, it is really ahrd to propose > >>> an alternative set of definitions that do what the authors wanted. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 7/24/13 6:16 PM, Alia Atlas wrote: > >>> > >>>> Joel, > >>>> > >>>> I understand your concern. Do you have text to suggest to Nitin > >>>> and co-authors? > >>>> I think part of this is figuring out how to pull out the RIB bits > >>>> (routing tables) and what traffic they apply to - as well as the > >>>> policy of how to create associated containers. Nitin's called > >>>> that a routing instance... > >>>> > >>>> What set of objects would you create? > >>>> > >>>> I personally would like to see the info-model described in > >>>> something other than rBNF - but I view that as a piece that can > >>>> happen in a future version. > >>>> > >>>> Alia > >>>> > >>>> > >>>> > >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern > >>>> > wrote: > >>>> > >>>> Looking again at this document, I have to reluctantly say taht I do > >>>> not support adoption of this document at this time. > >>>> > >>>> The base definition of RIB is still very unclear. A RIB is some > >>>> collection of routing instances? First, this seems upside-down to > >>>> me. A routing instance would seem to contain a RIB, not the other > >>>> way around. Secondly, what defines, describes, or otherwise helps > >>>> decide what set of routing instances go in the same RIB. > >>>> > >>>> If this issue were clarified, I believe the rest of the material is > >>>> in sufficiently good shape for working group adoption. > >>>> > >>>> Yours, > >>>> Joel M. Halpern > >>>> > >>>> > >>>> On 7/24/13 5:55 PM, Alia Atlas wrote: > >>>> > >>>> Please review draft-nitinb-i2rs-rib-info-__**model-01 > >>>> and comment > >>>> on whether > >>>> it should be adopted by I2RS. Detailed technical conversation > >>>> is also > >>>> most welcome. > >>>> > >>>> Authors: Are you aware of any IPR that applies > >>>> to draft-nitinb-i2rs-rib-info-__**model-01 Is so, has > >>>> this IPR been > >>>> disclosed in compliance with IETF IPR rules (see R > D"_blank">https://www.ietf.org/mailman/lis= > tinfo/i2rs>
>
>
> > _________________________ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nitinb@juniper.net Sat Jul 27 22:31:26 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B321A21F9D09 for ; Sat, 27 Jul 2013 22:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+fFhnF8L5ap for ; Sat, 27 Jul 2013 22:31:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id D830E21F9D04 for ; Sat, 27 Jul 2013 22:31:19 -0700 (PDT) Received: from mail162-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 05:31:18 +0000 Received: from mail162-va3 (localhost [127.0.0.1]) by mail162-va3-R.bigfish.com (Postfix) with ESMTP id 687791601AA for ; Sun, 28 Jul 2013 05:31:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h18c673h8275bh1de097hz2fh2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail162-va3: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=nitinb@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail162-va3 (localhost.localdomain [127.0.0.1]) by mail162-va3 (MessageSwitch) id 1374989476518002_28827; Sun, 28 Jul 2013 05:31:16 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.254]) by mail162-va3.bigfish.com (Postfix) with ESMTP id 7093F100059 for ; Sun, 28 Jul 2013 05:31:16 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.53) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 28 Jul 2013 05:31:16 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 27 Jul 2013 22:31:15 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sat, 27 Jul 2013 22:31:15 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 27 Jul 2013 22:35:28 -0700 Received: from mail120-tx2-R.bigfish.com (10.9.14.234) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 05:31:13 +0000 Received: from mail120-tx2 (localhost [127.0.0.1]) by mail120-tx2-R.bigfish.com (Postfix) with ESMTP id 9C3244C007E for ; Sun, 28 Jul 2013 05:31:13 +0000 (UTC) Received: from mail120-tx2 (localhost.localdomain [127.0.0.1]) by mail120-tx2 (MessageSwitch) id 13749894716976_11174; Sun, 28 Jul 2013 05:31:11 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.234]) by mail120-tx2.bigfish.com (Postfix) with ESMTP id F1A6A20049; Sun, 28 Jul 2013 05:31:10 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 05:31:10 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0341.000; Sun, 28 Jul 2013 05:31:10 +0000 From: Nitin Bahadur To: "George, Wes" , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: Ac6IuDYfGAg62gb2Rz65pCxQ4ExxRQAuWvLwAHyvUYA= Date: Sun, 28 Jul 2013 05:31:09 +0000 Message-ID: In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD592304393ED9AF@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: multipart/alternative; boundary="_000_CE1A79222B9A1nitinbjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TWCABLE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 05:31:26 -0000 --_000_CE1A79222B9A1nitinbjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. --_000_CE1A79222B9A1nitinbjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <03AB0136EC4D584FB59257835F2CC9B8@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Support.
--_000_CE1A79222B9A1nitinbjunipernet_-- From wassim.haddad@ericsson.com Sat Jul 27 22:41:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C04B21F9D04 for ; Sat, 27 Jul 2013 22:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjLZQMBlV+I4 for ; Sat, 27 Jul 2013 22:41:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 129F521F9D01 for ; Sat, 27 Jul 2013 22:41:27 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-26-51f4af059252 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 12.27.31362.50FA4F15; Sun, 28 Jul 2013 07:41:25 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Sun, 28 Jul 2013 01:41:24 -0400 From: Wassim Haddad To: "i2rs@ietf.org" , Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: AQHOiLg7/lCv11jKr0yE0noyF7aTypl2FRKAgAPD34CAAALdAA== Date: Sun, 28 Jul 2013 05:41:24 +0000 Message-ID: <0080E5AC-E540-4F76-9D5F-ADEA1A4600E3@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; micalg=sha1; boundary="Apple-Mail-D05FADA6-A217-4627-ADFF-7EE9A9E3853C"; protocol="application/pkcs7-signature" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPuC7r+i+BBquOy1h8eniJ2WLdjA8s DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGnoVtrAXdEhU9s8+zNzDOEO9i5OSQEDCR aNrxhw3CFpO4cG89mC0kcJRR4temoC5GLiB7OaPErCkn2UESbAIGEl+Xn2UFsUUEnCXet9wD s5kF9CQe3e5lBrGFBQIlFi68wQhREyTR9OAOVL2TxKTrs1lAbBYBVYmZKw6CzeQVsJdYfvIw K8RifYlvH/vBajiBdq1Zdw5sJiPQcd9PrWGC2CUucevJfCaIo0UkHl48DfWAqMTLx/9YQY5m FpjMKLHk6momiAWCEidnPmGZwCgyC0n/LGR1s5DUzWLkAEroSExeyAhRLy+x/e0cZgjbWmLG r4NsELapxOujH6FqFCWmdD9kX8DIsYqRo7Q4tSw33chwEyMwro5JsDnuYFzwyfIQozQHi5I4 7wa9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGA08lCfeOJh42fnOn+u/fh+YeHvdTb5o 3dm94SzLJl35Msl4bscmAb0zwZNePSjVF2U+VvswzTP1RKXOv8st4gJeL378WqWy79tJObcj Tv2Ccb/vyy9et+RxZ8fczlXSgtpb54fyhWsy2WxleOK8TLpCX0L77Hv7jzJWu2KfrRAP2FW1 lj3Sc78SS3FGoqEWc1FxIgAPzYaReQIAAA== Cc: Wassim Haddad Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 05:41:40 -0000 --Apple-Mail-D05FADA6-A217-4627-ADFF-7EE9A9E3853C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Support WG adoption Regards, Wassim H. --Apple-Mail-D05FADA6-A217-4627-ADFF-7EE9A9E3853C Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEuDCCBLQw ggOcoAMCAQICEQCUojyajRUmbGxGFxGXVNpZMA0GCSqGSIb3DQEBBQUAMDkxETAPBgNVBAoMCEVy aWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcNMTMwMzMxMTIx MDMzWhcNMTYwMzMxMTIxMDI4WjBoMREwDwYDVQQKDAhFcmljc3NvbjEWMBQGA1UEAwwNV2Fzc2lt IEhhZGRhZDEQMA4GA1UEBRMHZXdhc2hhZDEpMCcGCSqGSIb3DQEJARYad2Fzc2ltLmhhZGRhZEBl cmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxp/3FiWiazzKVr7PU v0s7/dQkmYrkft04l8+3Jo8vIZu9atKoYit1oXot5BhncNppa5uEJ3iuq7bX0cKfseS3EzMHkzgj xbljpVu68DBi0WpTagnCU6FFf+zE6kEZdoGFUXlU5VyWwiuuEizoubTZKyGhPcM+dyULu716KWNG WjoTmAyl9icj+DRK89GEBnuHF+2d4LVlwenpQYWwIULmU5nQ96EBbHqGA2ToL1KOCzyN5J2bMzSx ghiSXmh9L0ZmRlaocpzAUQyBpJi1yzEjD1cfVwAP7dYzerdVm1abs/nOE6+iuoNpaXZcBmBO+5m4 b6e1bukPRPHBacc1zcMtAgMBAAGjggGGMIIBgjCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFw Oi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBD QTAxLG89RXJpY3Nzb24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAlBgNV HREEHjAcgRp3YXNzaW0uaGFkZGFkQGVyaWNzc29uLmNvbTBGBgNVHSAEPzA9MDsGBiqFcGsBATAx MC8GCCsGAQUFBwIBFiNodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9sZWdhbC5zaHRtbDAdBgNVHQ4E FgQUWR/fGp12XaJ4zPsk5RYfG0+z8KowHwYDVR0jBBgwFoAUlifDuN6lX11EPjlS5UWxdl9jMJsw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4IBAQAOloIXs5llngHiWcsleNHGcD247uoZ Z2Gv8xBWBZzZZr+3jgIw9l/6QRDqIo2JmcN7YWJokxYw1shBUv3VMZZcuHSZvibXiEYquUYhRkBV jzyaTYWoZiECBv9p8eabf9VhKjPQ/u8eFbPlcB592AVZ1o0Vuqim/61exXnoz1gbIGdS7pa82LHT /HSSL+Ct1LTje54TJr3nOy+rhKgobc2fd9S017GfaRx8bMFBF0goMuNuxJtok5QzS7l6xozsyP+K aDTgAQsglBIfvsu9LkwQ/N2e+SFCXtnaoehxfc6F5ACoPi3LSxh/aVjgDM7e2UblyjXKqr/OHhcy a0W0hgkwMYICljCCApICAQEwTjA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAlKI8mo0VJmxsRhcRl1TaWTAJBgUrDgMCGgUAoIIBHTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA3MjgwNTQxMjRaMCMG CSqGSIb3DQEJBDEWBBRwvV6NVsG8LPJbXtCa2AuwOHU01DBdBgkrBgEEAYI3EAQxUDBOMDkxETAP BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDECEQCU ojyajRUmbGxGFxGXVNpZMF8GCyqGSIb3DQEJEAILMVCgTjA5MREwDwYDVQQKDAhFcmljc3NvbjEk MCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAlKI8mo0VJmxsRhcRl1TaWTAN BgkqhkiG9w0BAQEFAASCAQCJY9H5/tPmN8pdmzBz/+2EvRg8i01uql9JOXOiTxVMyby5QXuAQ8sH OzbW3QBTUZuZkDkLU7YzN1f8tdximcCXwWeOXht16XIqPO3lYWG4oTG7Ij3LtKbtkJ9BuG67yT2v 3E+DQzdhiYlQwOvj9yh6JWkMHddKoMSYlhv8IBtqHBf0lt0xWyHtsbvGXNG6c9UOJPMEwou7Z2/o zlIFJOD3SBsZ+220kZ8aOQOzVE/88LU5jCHlHvRndxKM6mG95dl/kqxOb+xkFHdO/5EXHGfFbfxn rLtMeXFb9QFziZpG1RNpNoqsBXNBOo73tVPy7kyOM/Tr6lIW94y8uOYmaud4AAAAAAAA --Apple-Mail-D05FADA6-A217-4627-ADFF-7EE9A9E3853C-- From jeff.tantsura@ericsson.com Sat Jul 27 23:56:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D12A21F9D56 for ; Sat, 27 Jul 2013 23:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgQOJuovIvIH for ; Sat, 27 Jul 2013 23:56:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4B21F9C6A for ; Sat, 27 Jul 2013 23:56:04 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-99-51f4c082e77b Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4D.95.13034.280C4F15; Sun, 28 Jul 2013 08:56:03 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Sun, 28 Jul 2013 02:56:01 -0400 From: Jeff Tantsura To: Wassim Haddad Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: AQHOiLg7rf8w3iK2gEmYEBmdz64TDpl2FRKAgAPD34CAAALdAP//0coV Date: Sun, 28 Jul 2013 06:56:00 +0000 Message-ID: <92694A00-E76A-4E98-95A4-0B83B95F05DE@ericsson.com> References: , <0080E5AC-E540-4F76-9D5F-ADEA1A4600E3@ericsson.com> In-Reply-To: <0080E5AC-E540-4F76-9D5F-ADEA1A4600E3@ericsson.com> 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+NgFjrILMWRmVeSWpSXmKPExsUyuXSPt27zgS+BBlMlLD49vMRssW7GBxYH Jo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK6Pv6m/2goNMFW+XvGVvYGxn6mLk5JAQMJGY OXcjI4QtJnHh3nq2LkYuDiGBo4wSUx92QjnLGSVa3t1kBqliEzCQ+P/tOAuILSKgJ7G0bzlY nFmgWOLcyc9sILawQKDEwoU3GCFqgiSaHtxhhbDdJD50zmUHsVkEVCUWrn4L1ssrYC9xfsdV sLiQQLLE87+rweZwCjhIPJ/xBCzOCHTd91NrmCB2iUvcejIf6gMBiSV7zjND2KISLx//Y4Wo 0ZFYsPsTG4StLbFs4WuoXYISJ2c+YZnAKDoLyahZSFpmIWmZhaRlASPLKkaO0uLUstx0I4NN jMBoOCbBpruDcc9Ly0OM0hwsSuK8q/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgNNVO P2tW69zQst7L8cNPqe21jQe1ZmyY/KDT9la0RaNx7xPGje9UIi1Kv/5sYP6vlbfmadjvtN6P h+Vqb3a+OeU541tF3uIWyR8LVY+G7LmTUL9GMvPPYiX2TtOVen8N/71w5pjC/8XHU3TSb4X3 F157zVCM6xDVs/GSNdR6f+RcxOsJRmtdlFiKMxINtZiLihMBTfwqGlQCAAA= Cc: "i2rs@ietf.org" , Wassim Haddad , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 06:56:09 -0000 Yes/support Regards, Jeff On Jul 28, 2013, at 7:41 AM, "Wassim Haddad" w= rote: > Support WG adoption >=20 >=20 > Regards, >=20 > Wassim H. > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From ramk@Brocade.com Sun Jul 28 00:32:55 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5621F9633 for ; Sun, 28 Jul 2013 00:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MExKrdXQhR-z for ; Sun, 28 Jul 2013 00:32:51 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 223AB21F889C for ; Sun, 28 Jul 2013 00:32:51 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r6S7VwnP019327; Sun, 28 Jul 2013 00:32:44 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1dvy01r00h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 28 Jul 2013 00:32:44 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 28 Jul 2013 00:32:43 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Sun, 28 Jul 2013 00:32:43 -0700 From: ramki Krishnan To: Jeff Tantsura , Wassim Haddad Date: Sun, 28 Jul 2013 00:32:42 -0700 Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: AQHOiLg7rf8w3iK2gEmYEBmdz64TDpl2FRKAgAPD34CAAALdAP//0coVgAAKGnA= Message-ID: References: , <0080E5AC-E540-4F76-9D5F-ADEA1A4600E3@ericsson.com> <92694A00-E76A-4E98-95A4-0B83B95F05DE@ericsson.com> In-Reply-To: <92694A00-E76A-4E98-95A4-0B83B95F05DE@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-28_02:2013-07-26, 2013-07-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307270227 Cc: "i2rs@ietf.org" , Wassim Haddad , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 07:32:56 -0000 Support WG adoption. Thanks, Ramki -----Original Message----- From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Jef= f Tantsura Sent: Sunday, July 28, 2013 8:56 AM To: Wassim Haddad Cc: i2rs@ietf.org; Wassim Haddad; Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statemen= t-01 Yes/support Regards, Jeff On Jul 28, 2013, at 7:41 AM, "Wassim Haddad" w= rote: > Support WG adoption >=20 >=20 > Regards, >=20 > Wassim H. > _______________________________________________ > 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 lufang@cisco.com Sun Jul 28 01:18:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3D21F8C20 for ; Sun, 28 Jul 2013 01:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8svKEexrZ3nx for ; Sun, 28 Jul 2013 01:18:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CC5C721F9D39 for ; Sun, 28 Jul 2013 01:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3030; q=dns/txt; s=iport; t=1374999518; x=1376209118; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=melVkX5ieHGSysMopxxjQeiOMgwjnx3WRW16yfBTmFA=; b=DOEpP25MKb2+RQZwitFEZ2HRoPC9METY42P+e3NYpmm+4U0NiHRPyONe O8AimHERDsnzSzSNUpcCBLEnHStn7psAD/aCWvBYRSHBNQGXe8joiPvxr Qm2blz1+lrSpe0gqJKQJi7FFpgoeWhyV/fQquRh03OC1Qds+FkyIKL/Ln s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAMrS9FGtJV2c/2dsb2JhbABagkJEgQW9UoEXFnSCJAEBAQQdbgEIBAoDAwECCx0oERQJCAIEARIIh3YDD659DYhejRWCNyAYgxZvA5V2jg+FJoMUgio X-IronPort-AV: E=Sophos;i="4.89,762,1367971200"; d="scan'208,217";a="240425390" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jul 2013 08:18:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6S8IYIL011123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 08:18:34 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 03:18:34 -0500 From: "Luyuan Fang (lufang)" To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: AQHOiLg3TdWFpWwZd0ymnjQppSpTMJl51W8A Date: Sun, 28 Jul 2013 08:18:33 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD9310470F18@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.21.150.184] Content-Type: multipart/alternative; boundary="_000_0DB8F45437AB844CBB5102F807A0AD9310470F18xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:18:47 -0000 --_000_0DB8F45437AB844CBB5102F807A0AD9310470F18xmbrcdx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support for WG adoption.. Luyuan From: Alia Atlas > Date: Wednesday, July 24, 2013 5:53 PM To: "i2rs@ietf.org" > Subject: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Please review draft-atlas-i2rs-problem-statement-01 and comment on whether = it should be adopted by I2RS. Detailed technical conversation is also most= welcome. Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-= statement-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This WG call for adoption will complete on August 12. Thanks, Alia --_000_0DB8F45437AB844CBB5102F807A0AD9310470F18xmbrcdx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <30BB533A04132B4ABE35241E18305582@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Support for WG adoption..
Luyuan

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, July 24, 2013 5:53= PM
To: "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: [i2rs] Call for WG Adoptio= n: draft-atlas-i2rs-problem-statement-01

Please review draft-atlas-i2rs-problem-statement-01 and co= mment on whether it should be adopted by I2RS.  Detailed technical con= versation is also most welcome.

Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem-= statement-01? Is so, has this IPR been disclosed in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This WG call for adoption will complete on August 12.

Thanks,
Alia
 --_000_0DB8F45437AB844CBB5102F807A0AD9310470F18xmbrcdx03ciscoc_-- From akatlas@gmail.com Sun Jul 28 06:03:09 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1421F9546 for ; Sun, 28 Jul 2013 06:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0S+TzPU27mV for ; Sun, 28 Jul 2013 06:03:08 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE2D21F9406 for ; Sun, 28 Jul 2013 06:03:08 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so11264894oag.9 for ; Sun, 28 Jul 2013 06:03:08 -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=15N0vKK8knCfby5zp9UaNmDmUM9m18ck3WVfhq1MPDs=; b=v+kFKHByHdeS3g+jKzkXnfFfiE7XUvz5Epv1ZF75PXIMVKCNKmx/141XgpVcyUu0BZ 3wq9rURbHN+jKsDXBiXCKycwIUcm3G69zoiHxOgy8YEyJ51iKRcSngH+Xv9RHal7uGUn RyXB9MH7UdYNpOOVq+A1UaUTl1lLvA6qH4qMM2UEN67qdC0fl1D26KPxAUGUfJMHlO3l Gdjw2QlB0qxHyoxfchztnJVwyy/0X6yFq0n7CNTVGyN3499AhC+FxEQ260biSEgBFbCJ T2iJhYMiaOhKI5fFEieo4jgtAz0t4fV5CHINXLfNAfGwTRl1cyuF7F8jP7HSSu8XebPx JEBg== MIME-Version: 1.0 X-Received: by 10.43.112.198 with SMTP id et6mr21260010icc.4.1375016588130; Sun, 28 Jul 2013 06:03:08 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Sun, 28 Jul 2013 06:03:08 -0700 (PDT) Date: Sun, 28 Jul 2013 09:03:08 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec517204f4bc39704e291fffe Subject: [i2rs] scribe and jabber scribe needed X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 13:03:09 -0000 --bcaec517204f4bc39704e291fffe Content-Type: text/plain; charset=ISO-8859-1 We need volunteers for scribe and for jabber scribe. The meeting will start more quickly and comfortably with volunteers. Thanks, Alia --bcaec517204f4bc39704e291fffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We need volunteers for scribe and for jabber scribe. =A0Th= e meeting will start more quickly and comfortably with volunteers.

=
Thanks,
Alia
--bcaec517204f4bc39704e291fffe-- From jclarke@cisco.com Sun Jul 28 09:30:33 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2706021F9C16 for ; Sun, 28 Jul 2013 09:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktSTIb7qhqZs for ; Sun, 28 Jul 2013 09:30:28 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id B015D21F9C53 for ; Sun, 28 Jul 2013 09:30:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6SGUL34019186; Sun, 28 Jul 2013 12:30:21 -0400 (EDT) Received: from rtp-jclarke-8916.cisco.com (rtp-jclarke-8916.cisco.com [10.117.46.167]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6SGULeJ029057; Sun, 28 Jul 2013 12:30:21 -0400 (EDT) Message-ID: <51F5471D.5080404@cisco.com> Date: Sun, 28 Jul 2013 12:30:21 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] scribe and jabber scribe needed X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 16:30:33 -0000 On 7/28/13 9:03 AM, Alia Atlas wrote: > We need volunteers for scribe and for jabber scribe. The meeting will > start more quickly and comfortably with volunteers. This is for Thursday? Happy to volunteer for Jabber scribe. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From nitinb@juniper.net Sun Jul 28 11:15:20 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC28121F9CB3 for ; Sun, 28 Jul 2013 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLDfpburuss7 for ; Sun, 28 Jul 2013 11:15:15 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 815C121F999A for ; Sun, 28 Jul 2013 11:15:14 -0700 (PDT) Received: from mail126-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 18:15:12 +0000 Received: from mail126-db8 (localhost [127.0.0.1]) by mail126-db8-R.bigfish.com (Postfix) with ESMTP id 97DDA4402BB for ; Sun, 28 Jul 2013 18:15:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail126-db8: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=nitinb@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail126-db8 (localhost.localdomain [127.0.0.1]) by mail126-db8 (MessageSwitch) id 1375035311144482_7071; Sun, 28 Jul 2013 18:15:11 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.225]) by mail126-db8.bigfish.com (Postfix) with ESMTP id 0BC5F240046 for ; Sun, 28 Jul 2013 18:15:11 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.53) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 18:15:10 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 28 Jul 2013 11:15:07 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Sun, 28 Jul 2013 11:15:07 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 28 Jul 2013 11:28:06 -0700 Received: from mail134-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 18:15:06 +0000 Received: from mail134-tx2 (localhost [127.0.0.1]) by mail134-tx2-R.bigfish.com (Postfix) with ESMTP id 643C71600BB for ; Sun, 28 Jul 2013 18:15:06 +0000 (UTC) Received: from mail134-tx2 (localhost.localdomain [127.0.0.1]) by mail134-tx2 (MessageSwitch) id 1375035303318498_24305; Sun, 28 Jul 2013 18:15:03 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.227]) by mail134-tx2.bigfish.com (Postfix) with ESMTP id 3DBB0A004B; Sun, 28 Jul 2013 18:15:03 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 18:15:03 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0341.000; Sun, 28 Jul 2013 18:15:02 +0000 From: Nitin Bahadur To: Acee Lindem , "Joel M. Halpern" Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOiLwErF8aRPkwVkGXnQxOro1qa5l0NGsAgAB7nwCAAJG5gIAFSweA Date: Sun, 28 Jul 2013 18:15:01 +0000 Message-ID: In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6B83EDA17221D141A1564D6518E7505C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%JOELHALPERN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:15:20 -0000 My original intent here was to provide "a name" to something that aggregated all the routing-instances. Obviously as many have pointed out, giving it the name of "rib" was a bad choice. So we have 2 choices: - Remove the top-level object in the grammar (rib) completely=8Aand instead start off with routing-instance. - Rename "rib" (in the grammar) to something better :) Thanks Nitin Bahadur On 7/25/13 4:25 AM, "Acee Lindem" wrote: >I agree with Joel. > >On 7/24/13 7:43 PM, "Joel M. Halpern" wrote: > >>This seems a different use of the term RIB than most of the work I am >>familiar with. Even without dealing with things like protocol specific >>RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally >>discuss them as using separate RIBs. This is why the terminology seems >>upside-down to me. >> >>Yours, >>Joel >> >>On 7/24/13 10:21 PM, Nitin Bahadur wrote: >>> Hi Joel, >>> >>> Maybe this can help clarify what we meant by the RIB. >>> >>> The RIB is the totality of all routing-information in a router. The >>> routing information itself can be sub-divided into multiple objects >>>called >>> routing-instances. >>> >>> Routing-instances allow us to partition the physical router into >>>domains >>> that can operate independently from one another in terms of routing and >>> forwarding. >>> >>> >>> The rest of that section describes what objects are contained in a RIB, >>> like routing tables, routes and nexthops. >>> >>> >>> HTH as a starting point. >>> Nitin Bahadur >>> >>> >>> >>> >>> >>> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >>> >>>> Asking for a text proposal is quite reasonable. >>>> Unfortunately, since my oncern is taht I can not understand what is >>>> meant by RIB in this definition, it is really ahrd to propose an >>>> alternative set of definitions that do what the authors wanted. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>>>> Joel, >>>>> >>>>> I understand your concern. Do you have text to suggest to Nitin and >>>>> co-authors? >>>>> I think part of this is figuring out how to pull out the RIB bits >>>>> (routing tables) and what traffic they apply to - as well as the >>>>>policy >>>>> of how to create associated containers. Nitin's called that a >>>>>routing >>>>> instance... >>>>> >>>>> What set of objects would you create? >>>>> >>>>> I personally would like to see the info-model described in something >>>>> other than rBNF - but I view that as a piece that can happen in a >>>>>future >>>>> version. >>>>> >>>>> Alia >>>>> >>>>> >>>>> >>>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>>> > wrote: >>>>> >>>>> Looking again at this document, I have to reluctantly say taht I >>>>>do >>>>> not support adoption of this document at this time. >>>>> >>>>> The base definition of RIB is still very unclear. A RIB is some >>>>> collection of routing instances? First, this seems upside-down >>>>>to >>>>> me. A routing instance would seem to contain a RIB, not the >>>>>other >>>>> way around. Secondly, what defines, describes, or otherwise >>>>>helps >>>>> decide what set of routing instances go in the same RIB. >>>>> >>>>> If this issue were clarified, I believe the rest of the material >>>>>is >>>>> in sufficiently good shape for working group adoption. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> >>>>> >>>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>>> >>>>> Please review draft-nitinb-i2rs-rib-info-__model-01 and >>>>>comment >>>>> on whether >>>>> it should be adopted by I2RS. Detailed technical >>>>>conversation >>>>> is also >>>>> most welcome. >>>>> >>>>> Authors: Are you aware of any IPR that applies >>>>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this >>>>>IPR >>>>> been >>>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>>> 4879, 3669 >>>>> and 5378 for more details). >>>>> >>>>> This WG call for adoption will complete on August 12. >>>>> >>>>> Thanks, >>>>> Alia >>>>> >>>>> >>>>> _________________________________________________ >>>>> 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 cpignata@cisco.com Sun Jul 28 14:07:28 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B9621F9E67 for ; Sun, 28 Jul 2013 14:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYJT4psbPadX for ; Sun, 28 Jul 2013 14:07:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 486BC21F9E28 for ; Sun, 28 Jul 2013 14:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4629; q=dns/txt; s=iport; t=1375045633; x=1376255233; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SPONeGCaOL8y0Cm8HY1EnspYey+XQmh/WzIbwGM47qA=; b=QUR0EtNMCJAcs+Xj5CaVrKh4Z47xP18peq276Bc5EzN/kjJ2KaOPPE4L qBcQNUqJReCuMLVvOpiOFBh5qUCux+J1b83fbVLqtfdTzX4bCnvVM8Ut1 Mmg3686kl36OKZ5aaZOKtMjCZVywSBOo7MgnJKZVUrndeYmlwfHJEPEqw 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFOH9VGtJV2Y/2dsb2JhbABbgwY1UL1SgRcWdIIkAQEBAwEBAQEaCkcLBQsCAQgOFCQhBgslAgQOBQgGh3ADCQYMriwNiFoEjRWCNzEHgxZvA5ASgS2CSYFujg+FJoMUgio X-IronPort-AV: E=Sophos;i="4.89,764,1367971200"; d="asc'?scan'208";a="240549862" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jul 2013 21:07:10 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6SL7APf002623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 21:07:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 16:07:09 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 Thread-Index: AQHOi9ZrGAg62gb2Rz65pCxQ4ExxRQ== Date: Sun, 28 Jul 2013 21:07:08 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D5EA54@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_72EA319F-2F34-44C4-BF8B-14D6E192435E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:07:29 -0000 --Apple-Mail=_72EA319F-2F34-44C4-BF8B-14D6E192435E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I support I2RS adoption of this document.=20 This is a very nice document. I also wanted to provide a small set of = review feedback comments (marked with "CMP"): Interface to the Routing System Problem Statement draft-atlas-i2rs-problem-statement-01 Abstract In order to enable 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 CMP: Where it says "In order to enable applications", I wonder if we = need to further qualify "network applications", to differentiate a = custom routing app versus a db query. Note this comment applies also to = the Introduction. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Internet Routing System (I2RS). CMP: The acronym does not expand, "Interface to the Internet Routing = System" seems to be "I2IRS" (extra Internet). 2. I2RS Model and Problem Area for The IETF Figure 1: I2RS model and Problem Area CMP: Figure 1 shows a single interface from an I2RS Client into an I2RS = Agent. For model completeness, would it make sense to add another "<-->" = (i.e., within scope) interface from the leftmost I2RS client into a = different I2RS Agent? Even something like "<-----> To another I2RS = Agent". 3. Standard Data-Models of Routing State for Installation There is a need to be able to precisely control routing and signaling state based upon policy or external measures. This can range from and In addition to interfaces to the RIB layer, there is a need to configure the various routing and signaling protocols with differing dynamic state based upon application-level policy decisions. The CMP: It is not clear to me what "signaling" specifically refers to here.=20= 3. Standard Data-Models of Routing State for Installation This means that, to usefully model next-hops, the data model employed needs to handle next-hop indirection (e.g. a prefix X is routed like prefix Y) as well as different types of tunneling and encapsulation. CMP: a nit: "indirection", or "indirection and recursion"? 5. Desired Aspects of a Protocol for I2RS Multiple Simultaneous Asynchronous Operations: A single application should be able to send multiple operations to I2RS without being required to wait for each to complete before sending the next. CMP: "via I2RS" instead of "to I2RS". Duplex: Communications can be established by either the I2RS client (i.e.: that resides within the application or is used by it to communicate with the I2RS server), or the I2RS server. Similarly, CMP: Should "I2RS agent" be used instead of "I2RS Server", for = nomenclature consistency? 5. Desired Aspects of a Protocol for I2RS CMP: I think there are some aspects potentially missing. Specifically: CMP: 1. Conflict resolution or Conflict notification (2 Apps fighting = for the same route) CMP: 2. Security (and specifically integrity) CMP: 3. Accounting. Thanks! -- Carlos. On Jul 24, 2013, at 11:53 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-problem-statement-01 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-problem-statement-01? Is so, has this IPR been = disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 = and 5378 for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_72EA319F-2F34-44C4-BF8B-14D6E192435E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH1h/wACgkQtfDPGTp3USwWKwCbBd2W3StOnSIVTVQekYihy8Ah k+8An0qiIh1qn/iBR7aixHHUMYXZ+84/ =TqV5 -----END PGP SIGNATURE----- --Apple-Mail=_72EA319F-2F34-44C4-BF8B-14D6E192435E-- From cpignata@cisco.com Sun Jul 28 14:26:19 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461B21F9EBE for ; Sun, 28 Jul 2013 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM79mEGDcnfF for ; Sun, 28 Jul 2013 14:26:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9721F9EB8 for ; Sun, 28 Jul 2013 14:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7746; q=dns/txt; s=iport; t=1375046770; x=1376256370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TImIu370AmUtZWOB5bIpbKXf86C+1UCqpE/7ijI3ipM=; b=OrFaVNZ2V2GVGYQPbkWD8iD6ol37Bxood2HApzFKDkI7Mp36lUsWtC5r pXXybQP+ItUEpIILEhlQDZ9MtSU/M1xpNd1rLJt/M8boWo4ifuto6Uxn7 Gd0e0H/zNsPlISzhZKT6BsqLkY6TyyWkCsaDvmbYBjXVB2B7iR+ZkGK5h M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAL6L9VGtJV2a/2dsb2JhbABbgkJENVC9UoEXFnSCJAEBAQMBAQEBGlELBQsCAQgOCgokIQYLJQIEDgUIBodwAwkGDK4zDYhaBI0VgjctBAeDFm8DkBKBLYQ3jg+FJoMUgio X-IronPort-AV: E=Sophos;i="4.89,765,1367971200"; d="asc'?scan'208,217";a="240580074" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jul 2013 21:26:09 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6SLQ99v011042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 21:26:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 16:26:08 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 Thread-Index: AQHOi9kSmKu0V/1FPEais0WRTlMRPQ== Date: Sun, 28 Jul 2013 21:26:07 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D5EB8E@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_84DCFC75-088A-48BC-8CC4-64101D1C9C65"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-keyupate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:26:19 -0000 --Apple-Mail=_84DCFC75-088A-48BC-8CC4-64101D1C9C65 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BF0CDEF-A827-4D8C-82E2-3AD683863ED3" --Apple-Mail=_8BF0CDEF-A827-4D8C-82E2-3AD683863ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I support the adoption of this document by I2RS. As the first "routing protocol" use-case document up for adoption, this = will be a test of where the WG ought to focus. I do believe there is = still an opportunity in this document to peel the onion more and also = look at what things we cannot get easily with other interfaces, and (as = others have said) topology (esp. virtual topologies) as well as policy, = and less on config to bring up a neighbor. That said, this is a good = start IMHO. I have a large set of minor comments that I will send directly to the = authors. Thanks, -- Carlos. On Jul 25, 2013, at 12:09 AM, Alia Atlas wrote: > And I've lost the ability to spell - apparently.=20 > It's: draft-keyupate-i2rs-bgp-usecases-00 >=20 > Alia >=20 >=20 > On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas wrote: > Note that: draft-keyupdate-i2rs-bgp-usecases-00 has only the basic = changes from IRS to I2RS compared to = draft-keyupdate-irs-bgp-usecases-02. Feel free to review and comment = on draft-keyupdate-i2rs-bgp-usecases-00 instead. >=20 > Also - in this case, it is particularly important to have good = conversation and discussion on the draft (unless you believe it is = perfect) - to help guide the co-authors on how to improve the draft. >=20 > Regards, > Alia > =20 >=20 >=20 >=20 > On Wed, Jul 24, 2013 at 5:59 PM, Alia Atlas wrote: > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-keyupdate-irs-bgp-usecases-02. Is so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_8BF0CDEF-A827-4D8C-82E2-3AD683863ED3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = support the adoption of this document by I2RS.

As the = first "routing protocol" use-case document up for adoption, this will be = a test of where the WG ought to focus. I do believe there is still an = opportunity in this document to peel the onion more and also look at = what things we cannot get easily with other interfaces, and (as others = have said) topology (esp. virtual topologies) as well as policy, and = less on config to bring up a neighbor. That said, this is a good start = IMHO.

I have a large set of minor comments that = I will send directly to the = authors.

Thanks,

-- = Carlos.

On Jul 25, 2013, at 12:09 AM, Alia Atlas = <akatlas@gmail.com> = wrote:

And I've lost the ability to = spell - apparently. 

Alia


On Wed, Jul 24, 2013 at 6:04 PM, Alia Atlas <akatlas@gmail.com> wrote:
Note = that:  draft-keyupdate-i2rs-bgp-usecases-00 has only the basic = changes from IRS to I2RS compared to = draft-keyupdate-irs-bgp-usecases-02.   Feel free to review and = comment on draft-keyupdate-i2rs-bgp-usecases-00 instead.

Also - in this case, it is particularly important to have = good conversation and discussion on the draft (unless you believe it is = perfect) - to help guide the co-authors on how to improve the = draft.
=
Regards,
Alia
 

=


On Wed, Jul 24, = 2013 at 5:59 PM, Alia Atlas <akatlas@gmail.com> wrote:
Please = review draft-keyupdate-irs-bgp-usecases-02 and comment on = whether it should be adopted by I2RS.  Detailed technical = conversation is also most welcome.

Authors: Are you = aware of any IPR that applies to draft-keyupdate-irs-bgp-usecases-02.  Is so, has this = IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, = 4879, 3669 and 5378 for more details).

This WG call for = adoption will complete on August 12.

Thanks,
Alia


_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_8BF0CDEF-A827-4D8C-82E2-3AD683863ED3-- --Apple-Mail=_84DCFC75-088A-48BC-8CC4-64101D1C9C65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH1jG8ACgkQtfDPGTp3USw2iwCgvLrqdB2BNnPKu+EL3j162C5h AYAAn0rqh11CTQlCXqOormM6+P4M8Qfp =O1CQ -----END PGP SIGNATURE----- --Apple-Mail=_84DCFC75-088A-48BC-8CC4-64101D1C9C65-- From cpignata@cisco.com Sun Jul 28 15:05:31 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4029221F9E8B for ; Sun, 28 Jul 2013 15:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHt5NC1DqNT3 for ; Sun, 28 Jul 2013 15:05:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C686A21F9C41 for ; Sun, 28 Jul 2013 15:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6343; q=dns/txt; s=iport; t=1375049125; x=1376258725; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0GocaQJH4XjnN3m1DYpYDnBeXkr5Qd2RccrB3WsdEbs=; b=YrJCa1gkz3a2OL11MfcSJiLfN8ci51bV4UVgnaidRi0q6/faGxoHb5Op 1kKWOko0ZrsZprn/7arh96iTOttDFhEgs1jbdA+7LJEiRajEY/L55kHB0 vuYhy4dvFYYJeQRVX+BJCkl3iYJ+JGzRrwnl4yOQWFP1b0u7n0Y8YtXXQ 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADeU9VGtJXG+/2dsb2JhbABbgwY1UL1SgRcWdIIkAQEBAwEBAQEaUQsFCwIBCA4UJCEGCyUCBA4FCAaHcAMJBgyuKw2IWgSNFYI3MQcCgxRvA5ASgS2EN4wYgXeFJoFbgTmCKg X-IronPort-AV: E=Sophos;i="4.89,765,1367971200"; d="asc'?scan'208";a="240560275" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jul 2013 22:05:22 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6SM5MHp007031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 22:05:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 17:05:22 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOi96NZ/I25T68qE+ZH95XxciWwg== Date: Sun, 28 Jul 2013 22:05:21 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D5EDCF@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_A0C7C4C5-F61B-4CA7-A81C-2EA67AAEEC53"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 22:05:31 -0000 --Apple-Mail=_A0C7C4C5-F61B-4CA7-A81C-2EA67AAEEC53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, I have concerns with adopting this document. As others have mentioned on the list, the concepts of RIB and routing = instance seem to be inverted. But in addition to that, there seem to be = two other issues with the document in its current shape: 1. It's not clear the scope of what's within the Routing Information = Base information model. Specifically, elements defined seem to belong in = the FIB and not the RIB. 2. The document structure seems to have gaps and overlaps, and lacks a = compiled set of definitions of RIB elements. Please find below some additional questions and observations on the = document, marked with "CMP".=20 I hope these are clear and useful. Routing Information Base Info Model draft-nitinb-i2rs-rib-info-model-01 1. Introduction The rest of this document is organized as follows. Section 2.1 goes into the details of what constitutes and can be programmed in a RIB. Section 5 provides a high-level view of the events and notifications going from a network device to an external entity, to update the external entity on asynchronous events. The RIB grammar is specified in Section 6. Examples of using the RIB grammar are shown in Section 7. CMP: What about other Sections? =46rom 2.1 it jumps to Section 5 and not proactive push (from the router) mechanisms. Screen scraping is error prone (since output can change) and vendor dependent. CMP: A nit -- the output will change. I think "since the output format = can change" is what's meant. 2.1. RIB definition A RIB is a logical construct controlled by an external entity. A RIB contains one or more routing instances. On a network device, a RIB is uniquely identified by its name. A routing instance can be in only 1 RIB. A routing instance, in the context of the RIB information model, is a collection of routing tables, interfaces, and routing parameters. A routing instance creates a logical slice of the router and allows different logical slices; across a set of routers; to communicate with other each. CMP: I think these set of definitions could use a visual to describe = what's a RIB, routing instance, routing tables and their high-level = elements, in addition to itemized definitions. Layer 3 Virtual Private Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service (VPLS) can be modeled as routing instances.=20 CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as = routing instances. Which L3 elements are there in an L2VPN? Note that modeling a Layer 2 VPN using a routing instance only models the Layer-3 (RIB) aspect and does not model any layer-2 information (like ARP) that might be associated with the L2VPN. CMP: DOes this mean that ARP should be out of the RIB model? 2.2. Routing tables A routing table is an entity that contains routes. A routing table is identified by its name. The name MUST be unique within a RIB. All routes in a given routing table MUST be of the same type (e.g. IPv4). Each routing table MUST belong to some routing instance. CMP: Should you also differentiate, in addition to the AF, by unicast = versus multicast? Each route table can be optionally associated with a ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding (RPF) checks on all IP routes in that table. Reverse path forwarding CMP: Is RPF an attribute of the routing table? 2.3. Route 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. This document specifies the following match types: CMP: What is an "MPLS Route" in the context of a routing table? o IPv4: Match on destination IP in IPv4 header o IPv6: Match on destination IP in IPv6 header o MPLS: Match on a MPLS tag o MAC: Match on ethernet destination addresses CMP: Is the MAC address a match element within routing? Or what types of = address families and identifiers are input to defining the elements = included? 2.4.1. Nexthop types o Special nexthops - for performing specific well-defined functions CMP: Are things like the drop/null route fitting here? Are there many = different kinds of specials, or should they be listed explicitly? 6. RIB grammar ::=3D | | | CMP: Why these families?=20 CMP: Do you need to separate IPv4 in unicast versus multicast? Or are = you modeling a single table with attributes for the uni/multicast? ::=3D CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"? Thanks, -- Carlos. On Jul 24, 2013, at 11:55 PM, Alia Atlas wrote: > Please review draft-nitinb-i2rs-rib-info-model-01 and comment on = whether it should be adopted by I2RS. Detailed technical conversation = is also most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-nitinb-i2rs-rib-info-model-01 Is so, has this IPR been disclosed = in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 = for more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_A0C7C4C5-F61B-4CA7-A81C-2EA67AAEEC53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH1laEACgkQtfDPGTp3USzWiwCfWFWi/cIBWozbFknw/gFetAec iVgAoLJUSNdvLLyRAdw+rjo30552dA01 =efw4 -----END PGP SIGNATURE----- --Apple-Mail=_A0C7C4C5-F61B-4CA7-A81C-2EA67AAEEC53-- From cpignata@cisco.com Sun Jul 28 15:06:39 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AC521F9EAF for ; Sun, 28 Jul 2013 15:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mY43AVrsckJ3 for ; Sun, 28 Jul 2013 15:06:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB521F9C41 for ; Sun, 28 Jul 2013 15:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5889; q=dns/txt; s=iport; t=1375049194; x=1376258794; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BRGsYkoz0RMvxVhhJzLvJ6/bGg5OrHHCD2cr6dN8+ME=; b=LNhtJ3KGJUKwuaRl+cHOJWK8At4wheL6COY4JmFI0O1v/u4XiF27Yzmv 7LUR2RUL95fC10x1l7qddzKd8CVAWsm0TIwuKH8d30k9anloUf5Xw4+nN 4wgW7CkQ/lyqkJbg+78QxLkldZ+wxMoz6VgAIFfptI4mm2twOUXS4YRKu Y=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAF2V9VGtJXHB/2dsb2JhbABSCYMGNVC9UoEXFnSCJAEBAQMBAQEBGlELBQsCAQgOBBAkIQYLFw4CBA4FCAaHcAMJBgyuKA2IWgSNFYEwgQcxB4MWbwOQEoEthDeOD4UmgVuBOYIq X-IronPort-AV: E=Sophos;i="4.89,765,1367971200"; d="asc'?scan'208";a="237571862" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jul 2013 22:06:31 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6SM6VaB022758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 28 Jul 2013 22:06:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 28 Jul 2013 17:06:24 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: AQHOi96yaVNnHyWthEilH4X2k4OgbA== Date: Sun, 28 Jul 2013 22:06:23 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D5EDE4@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_777A16EC-788D-44F2-9211-EA9B9C1064AE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 22:06:39 -0000 --Apple-Mail=_777A16EC-788D-44F2-9211-EA9B9C1064AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I support I2RS adoption of this document. This is a very solid start with a very well written individual draft. I also take the chance to share some questions and provide some review = feedback (with "CMP"): An Architecture for the Interface to the Routing System draft-atlas-i2rs-architecture-01 1. Introduction The I2RS, and therefore this document, are specifically focused on an interface for routing and forwarding data. CMP: "and forwarding data"? Ultimately the interface will influence = forwarding, but is it focused on it? 1.2. Architectural Overview Routing: This block represents that portion of the Routing Element that implements part of the Internet routing system. It includes not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager layer. CMP: Things like LDP and RSVP-TE are counted as "routing". It is not = clear to me that we might want to lump it together here, and frankly = what the scope for these things is. I suspect it might be worth = clarifying the reach and scope of these. I2RS Client: ... It interacts with the I2RS clients to collect = information from the routing and forwarding system. =20 CMP: I also wonder whether these references to interaction with the = "Forwarding system" refer to MPLS dataplane encap or are further = reaching, and how. For example, creating a Tunnel would not be = "forwarding". 2. Terminology identity: A client is associated with exactly one specific identity. State can be attributed to a particular identity. It is possible for multiple communication channels to use the same identity; in that case, the assumption is that the associated client is coordinating such communication. CMP: It seems to me that the "client identity" is necessary, but = sometimes not sufficient. I recall seeing an "Application Identity" = somewhere in this document, and wonder if that concept should not be = elevated in the requirement priority. 3.4. Authorization and Authentication I2RS clients may be operating on behalf of other applications. While those applications' identities are not need for authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations. CMP: It seems to me that the identity of an application is also critical = for Accounting (and troubleshooting). 4. Network Applications and I2RS Client When an I2RS Client interacts with multiple network applications, that I2RS Client is behaving as a go-between and may indicate this to the I2RS Agents by, for example, specifying a secondary opaque identity to allow improved troubleshooting. CMP: Should this be stronger than a "may indicate"? 4.1. Example Network Application: Topology Manager One example of such an application is a Topology Manager. Such an application includes an I2RS client which uses the I2RS protocol to collect information about the state of the network. The Topology Manager would collect device and interface state from devices it interacts with directly.=20 CMP: Tunnels are some times key elements in a topology. Are tunnels = considered as "interfaces" or should those be called out explicitly? 5.4.1. Unicast and Multicast RIB and LFIB Network elements concerned with routing IP maintain IP unicast RIBs. Similarly, there are RIBs for IP Multicast, and a Label Information Base (LIB) for MPLS. and 5.4.3. MPLS The I2RS Agent will need to interact with the knobs that policy attributes that control LDP operation as well as RSVP-TE based LSPs. CMP: While I think that programmatically interfacing with MPLS = information is useful, the case is not clearly described in the problem = statement, nor it seems to be captured comprehensively here. Section = 5.4.3 includes only a big broad statement, but it's not clear which = elements of label distribution protocols (i.e., BGP also seems missing = here) are relevant to I2RS. 6.1. Protocol Structure protocol. That protocol may use several underlying transports (TCP, SCTP, DCCP), with suitable authentication and integrity protection CMP: Doesn't I2RS need a reliable underlying transport? Why DCCP? Thanks, -- Carlos. On Jul 24, 2013, at 11:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether = it should be adopted by I2RS. Detailed technical conversation is also = most welcome. >=20 > Authors: Are you aware of any IPR that applies to = draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in = compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for = more details). >=20 > This WG call for adoption will complete on August 12. >=20 > Thanks, > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_777A16EC-788D-44F2-9211-EA9B9C1064AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlH1ld8ACgkQtfDPGTp3USwOigCgzTdutwMIW75axRkH5RcFpWnC nNUAoJW6MEVeAEKlotD/pqpDguwo4y9R =wTyu -----END PGP SIGNATURE----- --Apple-Mail=_777A16EC-788D-44F2-9211-EA9B9C1064AE-- From russw@riw.us Sun Jul 28 17:15:53 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5C521F9B92 for ; Sun, 28 Jul 2013 17:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Z336Q0mW-o for ; Sun, 28 Jul 2013 17:15:47 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4E521F9B90 for ; Sun, 28 Jul 2013 17:15:47 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3b7q-0002tf-At; Sun, 28 Jul 2013 17:15:46 -0700 From: "Russ White" To: "'Alia Atlas'" , References: In-Reply-To: Date: Sun, 28 Jul 2013 20:15:48 -0400 Message-ID: <039801ce8bf0$c7caed60$5760c820$@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: AQF1BlaXK6aro1WfH4t7iBRO2sy/25ot1H3A Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 00:15:53 -0000 > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on > whether it should be adopted by I2RS. Detailed technical conversation is also > most welcome. I was under the impression that this was being merged with draft-white-i2rs-use-case... Did we decide to carry all these use cases forward separately? Or not to carry draft-white-i2rs-use-case forward? :-) Russ From russw@riw.us Sun Jul 28 18:11:02 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6320E21F9EDB for ; Sun, 28 Jul 2013 18:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CX5rNg2p-iR for ; Sun, 28 Jul 2013 18:10:56 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 148AD21F9E85 for ; Sun, 28 Jul 2013 18:10:56 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3bzA-0004Hq-LP; Sun, 28 Jul 2013 18:10:52 -0700 From: "Russ White" To: "'Nitin Bahadur'" , "'Acee Lindem'" , "'Joel M. Halpern'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> In-Reply-To: Date: Sun, 28 Jul 2013 21:10:54 -0400 Message-ID: <03a301ce8bf8$7a82dd30$6f889790$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGgkY4zvawlwF2YL9R0ro+rZ1yBB5nWzROg Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 01:11:02 -0000 > My original intent here was to provide "a name" to something that > aggregated all the routing-instances. > Obviously as many have pointed out, giving it the name of "rib" was a = bad > choice. >=20 > So we have 2 choices: > - Remove the top-level object in the grammar (rib) completely=A9and = instead > start off with routing-instance. > - Rename "rib" (in the grammar) to something better :) Let me ask this: Is there some point to the top level "rib" object? IE, would you ever use an object that encompasses every routing table entry across the box, no matter which specific VRF the route is in? To put it another way --is there any time when you might want to say, "hand me = every route you have to 10.1.1.0/24, no matter what the routing context?" I can't think of any reason you'd ever ask this type of question --the context of the route is something you must have to make sense of the = route itself. In response to that, I'd say it's best to simply remove the top level object itself. :-) Russ=20 From russw@riw.us Sun Jul 28 18:17:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2228B21F9B80 for ; Sun, 28 Jul 2013 18:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQOCXEbdWWKS for ; Sun, 28 Jul 2013 18:17:04 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6AC21F99A9 for ; Sun, 28 Jul 2013 18:17:04 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3c59-0004Rz-Qt; Sun, 28 Jul 2013 18:17:04 -0700 From: "Russ White" To: "'Luyuan Fang \(lufang\)'" , "'Alia Atlas'" , References: <0DB8F45437AB844CBB5102F807A0AD9310470F18@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD9310470F18@xmb-rcd-x03.cisco.com> Date: Sun, 28 Jul 2013 21:17:06 -0400 Message-ID: <03a601ce8bf9$57be7420$073b5c60$@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: AQL82O2RdkNgufp+5+a95+TPnarJzpceQMXQ Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 01:17:10 -0000 Support for WG Adoption. Russ > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of > Luyuan Fang (lufang) > Sent: Sunday, July 28, 2013 4:19 AM > To: Alia Atlas; i2rs@ietf.org > Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement- > 01 > > Support for WG adoption.. > Luyuan > > From: Alia Atlas > > Date: Wednesday, July 24, 2013 5:53 PM > To: "i2rs@ietf.org " > > Subject: [i2rs] Call for WG Adoption: > draft-atlas-i2rs-problem-statement-01 > > > Please review draft-atlas-i2rs-problem-statement-01 and comment on > whether it should be adopted by I2RS. Detailed technical conversation is also > most welcome. > > Authors: Are you aware of any IPR that applies to draft-atlas-i2rs-problem- > statement-01? Is so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > This WG call for adoption will complete on August 12. > > Thanks, > Alia From sriganeshkini@gmail.com Sun Jul 28 23:57:21 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A248B21F967F for ; Sun, 28 Jul 2013 23:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbZIGaAP5sVn for ; Sun, 28 Jul 2013 23:57:21 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1521F9473 for ; Sun, 28 Jul 2013 23:57:19 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so4282650pbb.34 for ; Sun, 28 Jul 2013 23:57:19 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=ijVDdloCsWXspBzkA+vRY5Q5cCjCq4vluimauZPl7CA=; b=VH3uHaeir89kesj8yBCzz2zhJO1PWUaRKh4YgK3USIj+bQuu6xhkAFYUhaV/zJqBsh XS8HMFSOPIPUSIAGq++0WZIm4sAjMfgqr3UREEIVQnlLmhImjF6ldozUFZ3ImM1Vp0B6 5XUWe0Alm5cqnnRC+k0JWn0NfSlFZvhBgP35JMj1/PpruSu8AaoOTOrm7T8Fsn/ewfTk 7EJtoFKlgA7krBfK2whDUVY+8jQh7W75AH+ES4gegJShaGyTmdPn0bJkLdfg9OR9a3RR zzjxpF14cMdCaGM32Xz60sOroyfJY4NzpZQHwW6AXJaYAyGp3N3ByX8gEfOjruvejbwq PYlQ== X-Received: by 10.66.232.73 with SMTP id tm9mr43976735pac.159.1375081039095; Sun, 28 Jul 2013 23:57:19 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Sun, 28 Jul 2013 23:56:49 -0700 (PDT) In-Reply-To: <03a301ce8bf8$7a82dd30$6f889790$@riw.us> References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> From: Sriganesh Kini Date: Sun, 28 Jul 2013 23:56:49 -0700 X-Google-Sender-Auth: aLzoJtesiIyD3GyRYhsWfEDzHAQ Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=047d7b111d0ddf6ef604e2a100c0 Cc: "i2rs@ietf.org" , Nitin Bahadur , "Joel M. Halpern" , Acee Lindem , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 06:57:21 -0000 --047d7b111d0ddf6ef604e2a100c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Carlos, good point. But we also need to ask the question of where we express relationships between routing-contexts. E.g. If VPN-1 is being transported over Backbone-1 and VPN-2 over Backbone-2. Would these be inside the routing context or in a top level object ? - Sri On Sun, Jul 28, 2013 at 6:10 PM, Russ White wrote: > > > My original intent here was to provide "a name" to something that > > aggregated all the routing-instances. > > Obviously as many have pointed out, giving it the name of "rib" was a b= ad > > choice. > > > > So we have 2 choices: > > - Remove the top-level object in the grammar (rib) completely=C5=A0and = instead > > start off with routing-instance. > > - Rename "rib" (in the grammar) to something better :) > > Let me ask this: Is there some point to the top level "rib" object? IE, > would you ever use an object that encompasses every routing table entry > across the box, no matter which specific VRF the route is in? To put it > another way --is there any time when you might want to say, "hand me ever= y > route you have to 10.1.1.0/24, no matter what the routing context?" > > I can't think of any reason you'd ever ask this type of question --the > context of the route is something you must have to make sense of the rout= e > itself. In response to that, I'd say it's best to simply remove the top > level object itself. > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b111d0ddf6ef604e2a100c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Carlos, good point. But we also need to ask the question o= f where we express relationships between routing-contexts. E.g. If VPN-1 is= being transported over Backbone-1 and VPN-2 over Backbone-2. Would these b= e inside the routing context or in a top level object ?=C2=A0

- Sri


On Sun, Jul 2= 8, 2013 at 6:10 PM, Russ White <russw@riw.us> wrote:

> My original intent here was to provide "a name" to something= that
> aggregated all the routing-instances.
> Obviously as many have pointed out, giving it the name of "rib&qu= ot; was a bad
> choice.
>
> So we have 2 choices:
> - Remove the top-level object in the grammar (rib) completely=C5=A0and= instead
> start off with routing-instance.
> - Rename "rib" (in the grammar) to something better :)

Let me ask this: Is there some point to the top level "rib"= object? IE,
would you ever use an object that encompasses every routing table entry
across the box, no matter which specific VRF the route is in? To put it
another way --is there any time when you might want to say, "hand me e= very
route you have to 10.1.1.0= /24, no matter what the routing context?"

I can't think of any reason you'd ever ask this type of question --= the
context of the route is something you must have to make sense of the route<= br> itself. In response to that, I'd say it's best to simply remove the= top
level object itself.

:-)

Russ


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

--047d7b111d0ddf6ef604e2a100c0-- From acee.lindem@ericsson.com Mon Jul 29 00:51:57 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EAC21F99B0 for ; Mon, 29 Jul 2013 00:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3vqV9ji2a9k for ; Mon, 29 Jul 2013 00:51:51 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA14321F9994 for ; Mon, 29 Jul 2013 00:51:45 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-7b-51f61f0c3bd9 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EB.B0.13034.C0F16F15; Mon, 29 Jul 2013 09:51:40 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 03:51:40 -0400 From: Acee Lindem To: Nitin Bahadur , "Joel M. Halpern" Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOiLpwmyVE6QJjHUysr/9svX4s1pl0qJmAgAAA1QCAAENnAIAABkcAgAAcX4CABZ7egIAAbs+A Date: Mon, 29 Jul 2013 07:51:40 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4702FD29A3@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <98DF6A0480CBD54395BE3F46A2E7E3F3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPuC6P/LdAgx1NRhafHl5itlg34wOL xcdTb5gsGnrb2RxYPHbOusvusWTJTyaPc1O+M3pcb7rKHsASxWWTkpqTWZZapG+XwJVxv3Mi e8EFzYopXaeZGhiPKnQxcnJICJhIzHt2ng3CFpO4cG89kM3FISRwlFFi8oeJ7BDOckaJ71t2 s4JUsQnoSDx/9I8ZxBYRCJS49PISO4jNLOAs0X+jG8wWFoiVONzUAVUTJ9E+cTY7hB0l8a39 N1icRUBV4vWKf2BxXgFfiZOLHoHFOQUMJGZ3bWMCsRmBLvp+ag0TxHxxiVtP5jNBXCogsWTP eWYIW1Ti5eN/YLeJCuhJtB07ww4RV5ZY8mQ/C0SvnsSzU7OgbGuJiXMmskHY2hLLFr5mhrhB UOLkzCcsExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVI0dpcWpZbrqRwSZGYPwdk2DT3cG456Xl IUZpDhYlcd5VemcChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDqvTdUu3eCV0V1n4QS00e/ c3y1Vz9y5HCsOnftuWt7vkx8w7U9uxdoR/6/EbmbSUS1UUTRYP4fSbe6ePf/c4KfsEwS6Vk9 9flU0ZVvfHZObvl8ru5BgU7Tme3qtmU7/KZHc/7a6S8VtPHC6taZVd2CKVq5v3WFOz63606N bf57VX2BZWbuKgklluKMREMt5qLiRACH+Kq1jQIAAA== Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:51:57 -0000 I vote for #1. =20 Acee On 7/28/13 11:15 AM, "Nitin Bahadur" wrote: > >My original intent here was to provide "a name" to something that >aggregated all the routing-instances. >Obviously as many have pointed out, giving it the name of "rib" was a bad >choice. > >So we have 2 choices: >- Remove the top-level object in the grammar (rib) completely=A9and instea= d >start off with routing-instance. >- Rename "rib" (in the grammar) to something better :) > > >Thanks >Nitin Bahadur > > > > > >On 7/25/13 4:25 AM, "Acee Lindem" wrote: > >>I agree with Joel. >> >>On 7/24/13 7:43 PM, "Joel M. Halpern" wrote: >> >>>This seems a different use of the term RIB than most of the work I am >>>familiar with. Even without dealing with things like protocol specific >>>RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally >>>discuss them as using separate RIBs. This is why the terminology seems >>>upside-down to me. >>> >>>Yours, >>>Joel >>> >>>On 7/24/13 10:21 PM, Nitin Bahadur wrote: >>>> Hi Joel, >>>> >>>> Maybe this can help clarify what we meant by the RIB. >>>> >>>> The RIB is the totality of all routing-information in a router. The >>>> routing information itself can be sub-divided into multiple objects >>>>called >>>> routing-instances. >>>> >>>> Routing-instances allow us to partition the physical router into >>>>domains >>>> that can operate independently from one another in terms of routing >>>>and >>>> forwarding. >>>> >>>> >>>> The rest of that section describes what objects are contained in a >>>>RIB, >>>> like routing tables, routes and nexthops. >>>> >>>> >>>> HTH as a starting point. >>>> Nitin Bahadur >>>> >>>> >>>> >>>> >>>> >>>> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >>>> >>>>> Asking for a text proposal is quite reasonable. >>>>> Unfortunately, since my oncern is taht I can not understand what is >>>>> meant by RIB in this definition, it is really ahrd to propose an >>>>> alternative set of definitions that do what the authors wanted. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>>>>> Joel, >>>>>> >>>>>> I understand your concern. Do you have text to suggest to Nitin and >>>>>> co-authors? >>>>>> I think part of this is figuring out how to pull out the RIB bits >>>>>> (routing tables) and what traffic they apply to - as well as the >>>>>>policy >>>>>> of how to create associated containers. Nitin's called that a >>>>>>routing >>>>>> instance... >>>>>> >>>>>> What set of objects would you create? >>>>>> >>>>>> I personally would like to see the info-model described in something >>>>>> other than rBNF - but I view that as a piece that can happen in a >>>>>>future >>>>>> version. >>>>>> >>>>>> Alia >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>>>>>>>>>> > wrote: >>>>>> >>>>>> Looking again at this document, I have to reluctantly say taht >>>>>>I >>>>>>do >>>>>> not support adoption of this document at this time. >>>>>> >>>>>> The base definition of RIB is still very unclear. A RIB is >>>>>>some >>>>>> collection of routing instances? First, this seems upside-down >>>>>>to >>>>>> me. A routing instance would seem to contain a RIB, not the >>>>>>other >>>>>> way around. Secondly, what defines, describes, or otherwise >>>>>>helps >>>>>> decide what set of routing instances go in the same RIB. >>>>>> >>>>>> If this issue were clarified, I believe the rest of the >>>>>>material >>>>>>is >>>>>> in sufficiently good shape for working group adoption. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> >>>>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>>>> >>>>>> Please review draft-nitinb-i2rs-rib-info-__model-01 and >>>>>>comment >>>>>> on whether >>>>>> it should be adopted by I2RS. Detailed technical >>>>>>conversation >>>>>> is also >>>>>> most welcome. >>>>>> >>>>>> Authors: Are you aware of any IPR that applies >>>>>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this >>>>>>IPR >>>>>> been >>>>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>>>> 4879, 3669 >>>>>> and 5378 for more details). >>>>>> >>>>>> This WG call for adoption will complete on August 12. >>>>>> >>>>>> Thanks, >>>>>> Alia >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> 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 lhotka@nic.cz Mon Jul 29 01:29:49 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2F21F9E46 for ; Mon, 29 Jul 2013 01:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhO9j1Eu89pa for ; Mon, 29 Jul 2013 01:29:44 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B64F521F9EE0 for ; Mon, 29 Jul 2013 01:27:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BCBDC5402B1; Mon, 29 Jul 2013 10:27:51 +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 W-nvMdW-j9Ef; Mon, 29 Jul 2013 10:27:48 +0200 (CEST) Received: from localhost (dhcp-15b4.meeting.ietf.org [130.129.21.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E122E5400C8; Mon, 29 Jul 2013 10:27:38 +0200 (CEST) From: Ladislav Lhotka To: "Joel M. Halpern" , Nitin Bahadur In-Reply-To: <51F090D6.8080002@joelhalpern.com> References: <51F090D6.8080002@joelhalpern.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Mon, 29 Jul 2013 10:27:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:29:49 -0000 "Joel M. Halpern" writes: > This seems a different use of the term RIB than most of the work I am > familiar with. Even without dealing with things like protocol specific > RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally > discuss them as using separate RIBs. This is why the terminology seems > upside-down to me. It was not without a reason that I proposed to start with agreeing on and writing down definition of these important terms and acronyms: http://www.ietf.org/mail-archive/web/i2rs/current/msg00554.html We have gone through similar discussions in the NETMOD WG regarding the document draft-ietf-netmod-routing-cfg. In short, IETF standards and various vendors (plus their customers) use these terms with different meanings. Lada > > Yours, > Joel > > On 7/24/13 10:21 PM, Nitin Bahadur wrote: >> Hi Joel, >> >> Maybe this can help clarify what we meant by the RIB. >> >> The RIB is the totality of all routing-information in a router. The >> routing information itself can be sub-divided into multiple objects called >> routing-instances. >> >> Routing-instances allow us to partition the physical router into domains >> that can operate independently from one another in terms of routing and >> forwarding. >> >> >> The rest of that section describes what objects are contained in a RIB, >> like routing tables, routes and nexthops. >> >> >> HTH as a starting point. >> Nitin Bahadur >> >> >> >> >> >> On 7/24/13 3:19 PM, "Joel M. Halpern" wrote: >> >>> Asking for a text proposal is quite reasonable. >>> Unfortunately, since my oncern is taht I can not understand what is >>> meant by RIB in this definition, it is really ahrd to propose an >>> alternative set of definitions that do what the authors wanted. >>> >>> Yours, >>> Joel >>> >>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>>> Joel, >>>> >>>> I understand your concern. Do you have text to suggest to Nitin and >>>> co-authors? >>>> I think part of this is figuring out how to pull out the RIB bits >>>> (routing tables) and what traffic they apply to - as well as the policy >>>> of how to create associated containers. Nitin's called that a routing >>>> instance... >>>> >>>> What set of objects would you create? >>>> >>>> I personally would like to see the info-model described in something >>>> other than rBNF - but I view that as a piece that can happen in a future >>>> version. >>>> >>>> Alia >>>> >>>> >>>> >>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>> > wrote: >>>> >>>> Looking again at this document, I have to reluctantly say taht I do >>>> not support adoption of this document at this time. >>>> >>>> The base definition of RIB is still very unclear. A RIB is some >>>> collection of routing instances? First, this seems upside-down to >>>> me. A routing instance would seem to contain a RIB, not the other >>>> way around. Secondly, what defines, describes, or otherwise helps >>>> decide what set of routing instances go in the same RIB. >>>> >>>> If this issue were clarified, I believe the rest of the material is >>>> in sufficiently good shape for working group adoption. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> >>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>> >>>> Please review draft-nitinb-i2rs-rib-info-__model-01 and comment >>>> on whether >>>> it should be adopted by I2RS. Detailed technical conversation >>>> is also >>>> most welcome. >>>> >>>> Authors: Are you aware of any IPR that applies >>>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this IPR >>>> been >>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>> 4879, 3669 >>>> and 5378 for more details). >>>> >>>> This WG call for adoption will complete on August 12. >>>> >>>> Thanks, >>>> Alia >>>> >>>> >>>> _________________________________________________ >>>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jrmitche@puck.nether.net Mon Jul 29 03:40:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2880721F9F5F for ; Mon, 29 Jul 2013 03:40:59 -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=[AWL=0.600, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPfaGZ5z5Eny for ; Mon, 29 Jul 2013 03:40:58 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4F21F994B for ; Mon, 29 Jul 2013 03:40:58 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6TAeu6m017257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2013 06:40:56 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6TAeuq6017255; Mon, 29 Jul 2013 06:40:56 -0400 Date: Mon, 29 Jul 2013 06:40:56 -0400 From: Jon Mitchell To: Russ White Message-ID: <20130729104056.GA7087@puck.nether.net> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039801ce8bf0$c7caed60$5760c820$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 29 Jul 2013 06:40:57 -0400 (EDT) Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 10:40:59 -0000 On 28/07/13 20:15 -0400, Russ White wrote: > > > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on > > whether it should be adopted by I2RS. Detailed technical conversation is > also > > most welcome. > > I was under the impression that this was being merged with > draft-white-i2rs-use-case... Did we decide to carry all these use cases > forward separately? Or not to carry draft-white-i2rs-use-case forward? WG Chairs - is the intent to only have one BGP use cases draft? The current keyupdate draft has a large number of use cases and scenarios, mostly focused on SP network requirements. Also, I note that most of it's use cases are centralized deployment and vendor neutral specification of configuration oriented in nature. If we are going to only progress one document to cover BGP use cases, I would prefer it cover at least some use cases oriented towards manipulation of routing information to meet service differentiated routing such as those specified in your draft. At this time without knowing the authors intent (although one of the authors is on both documents?) and lack of comment on Joel's similar feedback earlier to the group, I'm can't support adoption of this draft if there is only an intent to progress one. I'd be willing to support it if the authors are committed to integrating the white draft use cases (that don't already overlap such as VPN membership) into a merged document however. Jon From jrmitche@puck.nether.net Mon Jul 29 03:52:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE33721F9F01 for ; Mon, 29 Jul 2013 03:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcVArUsjZ-q8 for ; Mon, 29 Jul 2013 03:52:45 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9765D21F9CE8 for ; Mon, 29 Jul 2013 03:52:44 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6TAqhrc026449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2013 06:52:43 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6TAqhtm026448; Mon, 29 Jul 2013 06:52:43 -0400 Date: Mon, 29 Jul 2013 06:52:43 -0400 From: Jon Mitchell To: Alia Atlas Message-ID: <20130729105242.GB7087@puck.nether.net> 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) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 29 Jul 2013 06:52:43 -0400 (EDT) Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 10:52:46 -0000 On 24/07/13 17:53 -0400, Alia Atlas wrote: > Please review draft-atlas-i2rs-problem-statement-01 and comment on whether > it should be adopted by I2RS. Detailed technical conversation is also most > welcome. > Support adoption.. some small issues to authors direct. -Jon From edc@google.com Mon Jul 29 04:12:35 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDA821F99AE for ; Mon, 29 Jul 2013 04:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWVGGGsfqsV4 for ; Mon, 29 Jul 2013 04:12:34 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D667621F9590 for ; Mon, 29 Jul 2013 04:11:55 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id en1so2839565wid.0 for ; Mon, 29 Jul 2013 04:11:55 -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 :cc:content-type; bh=q1+Sl/K6OsZpZs/sWT5utknKif2a2Brm3OTtbARDjtk=; b=PCkb5EU7Pyh6JSqWlkSDT5tEy01ZQxmu/MpCl3veOLyKP236KAnSS5irXn2V7PEUS0 Ill0cFQJxkN1r9JqmhvSUnzaiGrJBA1aADmQ41LREzIIf3iS7FGDpiaFYRirBRWD+cEy VXDhkXgLL6zsYbWTcAWb+DBO6B7XkzqdJEXScpYzds4LLSPZD7m4THDv/+yar+rQykz/ 9c8RRezpeKLYtcqca64L3zGXD8R/P7ypVNoQ34yK/GTthPARCgUYk0ZQw9zyZKp1H9Js e87qmTudmviTq9/PeNXXS3fT+dyd9SZLrKJpcBHP4eLPe52s3JDy6DS1Zm3mc0v81E8i GMGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=q1+Sl/K6OsZpZs/sWT5utknKif2a2Brm3OTtbARDjtk=; b=HrycdaMdUdScmysv3K8UFHsPSF3VK8eElmMjPO9BAZ88O/93U8lsRWitNIC6vInnzt kVVYLIKWuEkYIXfIS+bjwP+AQx6hVXHkuHzqG6V90ylZqqlHbVbw22/y4c6TzSM8AFr9 4Qk+T1TCVieZMtjlDRStCmBvg/8EoqFrDJCInWP2ZK5Y+tXVhiKKIVg4t1He0FwNSZu1 Lpqd39sgvRqRvyz4ZJLUSuj8FXi7ZdJrjNYXgIHtBHSuTzXs9vQCTX3FtfanmmAo8TqM GdcPEQ0tEUfPt+WAZMtLuTtxLcxgMKkZMZ1M11qhbcqQPCEbo0g2375bGMQkFHnvbPDU 3w2Q== X-Received: by 10.194.95.100 with SMTP id dj4mr22088073wjb.55.1375096314920; Mon, 29 Jul 2013 04:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.81.198 with HTTP; Mon, 29 Jul 2013 04:11:14 -0700 (PDT) In-Reply-To: <20130729104056.GA7087@puck.nether.net> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> <20130729104056.GA7087@puck.nether.net> From: Edward Crabbe Date: Mon, 29 Jul 2013 13:11:14 +0200 Message-ID: To: Jon Mitchell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk0xpOchCnRIsta6LYHBM6SS74+L46h7x2ZCH2ObC9DmYjE+02OmPaes4auj04x+TktX3p1VzvMg6ZmJyKO8o7xgNvh/BAVJ5/POdkSX6UHU+L1DQXvkEiW7gaYh4UlccBIU2go0ajgPLB+zKVOM41zbYVrHtUUfTVBQ4aBWG43N+a5uD6geNLNPxchhzIrQp88RlyY Cc: Russ White , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:12:35 -0000 Jon et al; IMO we should have a single BGP use cases draft, at least initially. Obviously draft merger, if required, is up to the respective authors to negotiate. cheers, -ed cheers, -ed On Mon, Jul 29, 2013 at 12:40 PM, Jon Mitchell wrote: > On 28/07/13 20:15 -0400, Russ White wrote: >> >> > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on >> > whether it should be adopted by I2RS. Detailed technical conversation is >> also >> > most welcome. >> >> I was under the impression that this was being merged with >> draft-white-i2rs-use-case... Did we decide to carry all these use cases >> forward separately? Or not to carry draft-white-i2rs-use-case forward? > > WG Chairs - is the intent to only have one BGP use cases draft? > > The current keyupdate draft has a large number of use cases and > scenarios, mostly focused on SP network requirements. Also, I note > that most of it's use cases are centralized deployment and vendor > neutral specification of configuration oriented in nature. If we are > going to only progress one document to cover BGP use cases, I would > prefer it cover at least some use cases oriented towards manipulation > of routing information to meet service differentiated routing such as > those specified in your draft. > > At this time without knowing the authors intent (although one of the > authors is on both documents?) and lack of comment on Joel's similar > feedback earlier to the group, I'm can't support adoption of this > draft if there is only an intent to progress one. I'd be willing to > support it if the authors are committed to integrating the white draft > use cases (that don't already overlap such as VPN membership) into a > merged document however. > > Jon > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Mon Jul 29 04:28:44 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA0821F9360 for ; Mon, 29 Jul 2013 04:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiLkwLufYeTL for ; Mon, 29 Jul 2013 04:28:42 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1406321E80A6 for ; Mon, 29 Jul 2013 04:27:48 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so8977676obc.41 for ; Mon, 29 Jul 2013 04:27:48 -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=KAEEa6o5wZBS+ofWruxqOh+RMXpXfsdD/EvU3eToNcM=; b=v7yPeRVYa84q5CkE//AZbM4X7Em7z3w5/kvQsd97KwjOGybA+huiKhU7BCGEe83zjg fUyjAXnDE1cuwX5Z7ee094wEYmG/qB1YTS9RQAf6QpiTkoFz5WSnOp0oMZacbZa6mliE XM4dPekriux2wEpZw57JvyphabJCIPaLu5RBMK1a+16XzDm1dAXjfPijpzC/tIL3mcZO PfROBzYBE4ox6X2njL30/k8fcKyKh1a0m7aiNTrY2SW9SGmtMoUxo3aIN1jhBYyqbScP Pk+PiPHTmhZjM0oVrrOYWww239fR/yf32beea8TiVyeyHwjZZvJaFnzPRsa09XPjzg+c U4+w== MIME-Version: 1.0 X-Received: by 10.43.65.144 with SMTP id xm16mr21270466icb.112.1375097268019; Mon, 29 Jul 2013 04:27:48 -0700 (PDT) Received: by 10.64.8.19 with HTTP; Mon, 29 Jul 2013 04:27:47 -0700 (PDT) In-Reply-To: <20130729104056.GA7087@puck.nether.net> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> <20130729104056.GA7087@puck.nether.net> Date: Mon, 29 Jul 2013 07:27:47 -0400 Message-ID: From: Alia Atlas To: Jon Mitchell Content-Type: multipart/alternative; boundary=bcaec51b1b6f3128c904e2a4c832 Cc: Russ White , "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:28:44 -0000 --bcaec51b1b6f3128c904e2a4c832 Content-Type: text/plain; charset=ISO-8859-1 >From the comments so far, it is clear that there is work to be done on this draft before adoption. I am quite eager to see the set of reasonable use-cases get discussed and put in. A single draft of BGP use-cases would be good. Once one is adopted, the WG can direct the editors to add cases - if and when there is consensus to do so. I don't think that a single draft of all I2RS use-cases is at all practical. I would be happy to see more detailed discussion on what does and doesn't belong in the draft. My personal (WG-chair hat off) preference would be to focus on those cases that aren't "just another configuration mechanism" and that clearly articulate the feedback loop needed of monitored data and events as well as data to modify/write. Alia On Mon, Jul 29, 2013 at 6:40 AM, Jon Mitchell wrote: > On 28/07/13 20:15 -0400, Russ White wrote: > > > > > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on > > > whether it should be adopted by I2RS. Detailed technical conversation > is > > also > > > most welcome. > > > > I was under the impression that this was being merged with > > draft-white-i2rs-use-case... Did we decide to carry all these use cases > > forward separately? Or not to carry draft-white-i2rs-use-case forward? > > WG Chairs - is the intent to only have one BGP use cases draft? > > The current keyupdate draft has a large number of use cases and > scenarios, mostly focused on SP network requirements. Also, I note > that most of it's use cases are centralized deployment and vendor > neutral specification of configuration oriented in nature. If we are > going to only progress one document to cover BGP use cases, I would > prefer it cover at least some use cases oriented towards manipulation > of routing information to meet service differentiated routing such as > those specified in your draft. > > At this time without knowing the authors intent (although one of the > authors is on both documents?) and lack of comment on Joel's similar > feedback earlier to the group, I'm can't support adoption of this > draft if there is only an intent to progress one. I'd be willing to > support it if the authors are committed to integrating the white draft > use cases (that don't already overlap such as VPN membership) into a > merged document however. > > Jon > > --bcaec51b1b6f3128c904e2a4c832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From the comments so far, it is clear that there is work t= o be done on this draft before adoption. =A0I am quite eager to see the set= of reasonable use-cases get discussed and put in.=A0

A = single draft of BGP use-cases would be good. =A0Once one is adopted, the WG= can direct the editors to add cases - if and when there is consensus to do= so.

I don't think that a single draft of all I2RS use-c= ases is at all practical. =A0

I would be happy to = see more detailed discussion on what does and doesn't belong in the dra= ft. =A0My personal (WG-chair hat off) preference would be to focus on those= cases that aren't "just another configuration mechanism" and= that clearly articulate the feedback loop needed of monitored data and eve= nts as well as data to modify/write.

Alia


On Mon, Jul 29, 2013 at 6:40 AM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
On 2= 8/07/13 20:15 -0400, Russ White wrote:
>
> > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on<= br> > > whether it should be adopted by I2RS. =A0Detailed technical conve= rsation is
> also
> > most welcome.
>
> I was under the impression that this was being merged with
> draft-white-i2rs-use-case... Did we decide to carry all these use case= s
> forward separately? Or not to carry draft-white-i2rs-use-case forward?=

WG Chairs - is the intent to only have one BGP use cases draft?=

The current keyupdate draft has a large number of use cases and
scenarios, mostly focused on SP network requirements. =A0Also, I note
that most of it's use cases are centralized deployment and vendor
neutral specification of configuration oriented in nature. =A0If we are
going to only progress one document to cover BGP use cases, I would
prefer it cover at least some use cases oriented towards manipulation
of routing information to meet service differentiated routing such as
those specified in your draft.

At this time without knowing the authors intent (although one of the
authors is on both documents?) and lack of comment on Joel's similar feedback earlier to the group, I'm can't support adoption of this draft if there is only an intent to progress one. =A0I'd be willing to<= br> support it if the authors are committed to integrating the white draft
use cases (that don't already overlap such as VPN membership) into a merged document however.

Jon


--bcaec51b1b6f3128c904e2a4c832-- From tnadeau@lucidvision.com Mon Jul 29 04:40:25 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645121F9BD3 for ; Mon, 29 Jul 2013 04:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ0HAMwgc01h for ; Mon, 29 Jul 2013 04:40:20 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7F71121F8F2E for ; Mon, 29 Jul 2013 04:40:19 -0700 (PDT) Received: from [172.28.130.76] (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 5E2F32515F9B; Mon, 29 Jul 2013 07:40:17 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F7215EC-4FDC-4518-9E0B-64B62B6F352B" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Thomas Nadeau In-Reply-To: Date: Mon, 29 Jul 2013 13:40:16 +0200 Message-Id: <40409CD7-451E-41C1-9D77-BC39927CED88@lucidvision.com> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> <20130729104056.GA7087@puck.nether.net> To: Alia Atlas X-Mailer: Apple Mail (2.1508) Cc: Russ White , "i2rs@ietf.org" , Jon Mitchell Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:40:25 -0000 --Apple-Mail=_9F7215EC-4FDC-4518-9E0B-64B62B6F352B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 29, 2013:1:27 PM, at 1:27 PM, Alia Atlas = wrote: > =46rom the comments so far, it is clear that there is work to be done = on this draft before adoption. I am quite eager to see the set of = reasonable use-cases get discussed and put in.=20 >=20 > A single draft of BGP use-cases would be good. Once one is adopted, = the WG can direct the editors to add cases - if and when there is = consensus to do so. >=20 > I don't think that a single draft of all I2RS use-cases is at all = practical. =20 I agree. You also need to consider the fact that things will = evolve over time, and as a result that could hold up the progress of the = early use cases in the IETF process as other use cases are discovered = and added. As you also know, we could gut the entire document and = start from scratch just using the draft as a shell that targets that = charter item. The point is that the WG has such a charter item, and this = document at a minimum, is a good start to satisfy that. As you mention, = once its a WG draft, the WG is in control of its content and can alter = it as needed. --Tom > I would be happy to see more detailed discussion on what does and = doesn't belong in the draft. My personal (WG-chair hat off) preference = would be to focus on those cases that aren't "just another configuration = mechanism" and that clearly articulate the feedback loop needed of = monitored data and events as well as data to modify/write. >=20 > Alia >=20 >=20 > On Mon, Jul 29, 2013 at 6:40 AM, Jon Mitchell = wrote: > On 28/07/13 20:15 -0400, Russ White wrote: > > > > > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on > > > whether it should be adopted by I2RS. Detailed technical = conversation is > > also > > > most welcome. > > > > I was under the impression that this was being merged with > > draft-white-i2rs-use-case... Did we decide to carry all these use = cases > > forward separately? Or not to carry draft-white-i2rs-use-case = forward? >=20 > WG Chairs - is the intent to only have one BGP use cases draft? >=20 > The current keyupdate draft has a large number of use cases and > scenarios, mostly focused on SP network requirements. Also, I note > that most of it's use cases are centralized deployment and vendor > neutral specification of configuration oriented in nature. If we are > going to only progress one document to cover BGP use cases, I would > prefer it cover at least some use cases oriented towards manipulation > of routing information to meet service differentiated routing such as > those specified in your draft. >=20 > At this time without knowing the authors intent (although one of the > authors is on both documents?) and lack of comment on Joel's similar > feedback earlier to the group, I'm can't support adoption of this > draft if there is only an intent to progress one. I'd be willing to > support it if the authors are committed to integrating the white draft > use cases (that don't already overlap such as VPN membership) into a > merged document however. >=20 > Jon >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail=_9F7215EC-4FDC-4518-9E0B-64B62B6F352B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 akatlas@gmail.com> = wrote:
=46rom the comments so far, it is clear = that there is work to be done on this draft before adoption.  I am = quite eager to see the set of reasonable use-cases get discussed and put = in. 

A single draft of BGP use-cases would be = good.  Once one is adopted, the WG can direct the editors to add = cases - if and when there is consensus to do so.

I don't think that a single draft of all I2RS = use-cases is at all practical. =  

I agree. = You also need to consider the fact that things will evolve over time, = and as a result that could hold up the progress of the early use cases = in the IETF process as other use cases are discovered and added.   = As you also know, we could gut the entire document and start from = scratch just using the draft as a shell that targets that charter = item. The point is that the WG has such a charter item, and this = document at a minimum, is a good start to satisfy that. As you mention, = once its a WG draft, the WG is in control of its content and can alter = it as needed.

= --Tom


I would be happy to see more detailed discussion on = what does and doesn't belong in the draft.  My personal (WG-chair = hat off) preference would be to focus on those cases that aren't "just = another configuration mechanism" and that clearly articulate the = feedback loop needed of monitored data and events as well as data to = modify/write.

Alia


On Mon, Jul 29, = 2013 at 6:40 AM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
On 28/07/13 20:15 -0400, Russ White = wrote:
>
> > Please review draft-keyupdate-irs-bgp-usecases-02 and comment = on
> > whether it should be adopted by I2RS.  Detailed technical = conversation is
> also
> > most welcome.
>
> I was under the impression that this was being merged with
> draft-white-i2rs-use-case... Did we decide to carry all these use = cases
> forward separately? Or not to carry draft-white-i2rs-use-case = forward?

WG Chairs - is the intent to only have one BGP use cases = draft?

The current keyupdate draft has a large number of use cases and
scenarios, mostly focused on SP network requirements.  Also, I = note
that most of it's use cases are centralized deployment and vendor
neutral specification of configuration oriented in nature.  If we = are
going to only progress one document to cover BGP use cases, I would
prefer it cover at least some use cases oriented towards = manipulation
of routing information to meet service differentiated routing such = as
those specified in your draft.

At this time without knowing the authors intent (although one of the
authors is on both documents?) and lack of comment on Joel's similar
feedback earlier to the group, I'm can't support adoption of this
draft if there is only an intent to progress one.  I'd be willing = to
support it if the authors are committed to integrating the white = draft
use cases (that don't already overlap such as VPN membership) into a
merged document however.

Jon


_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/ma= ilman/listinfo/i2rs

= --Apple-Mail=_9F7215EC-4FDC-4518-9E0B-64B62B6F352B-- From kwangkooglee@gmail.com Mon Jul 29 04:54:30 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5321F869A for ; Mon, 29 Jul 2013 04:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPIkferE4X9X for ; Mon, 29 Jul 2013 04:54:29 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2446421F8C20 for ; Mon, 29 Jul 2013 04:54:01 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so1238647qeb.10 for ; Mon, 29 Jul 2013 04:54:00 -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=FCPuxO48ADneCWM1ecBcNQCYw7Y/oXqpmWc05Wy1Q+8=; b=L/fKgYuE8sHk5tOURFmb9aC27mIuiH/1/oRf2LjDXCNqwJN9j99emVwfufAu+hk4gd IKzFQa0hrZcXjGFkPWpJdP1gdifEEX5YC5TpI4+4/RbJKIm90tkxMeIZ5HdcAKIAe36x G4Qbvax1yNiXC3tGemfWnBW6Q3jL2UqfbQ849xJgia/d4keNZKye4prB/SDJxudXc1jm YgBS+5sS2y2FXXSgMJxcvwCQwywTPx/lYLdYau7cEuCe9refPHs2CPYvB+B3BB+HywwV SEYynh6DZTi1Mp2lXKTbjL0aTdxbTUS1LbVp1vKqGP+9CfZmohvtBnkUIH9Lj+JGNjmL g9pw== MIME-Version: 1.0 X-Received: by 10.224.53.196 with SMTP id n4mr11129513qag.104.1375098840366; Mon, 29 Jul 2013 04:54:00 -0700 (PDT) Received: by 10.49.2.198 with HTTP; Mon, 29 Jul 2013 04:54:00 -0700 (PDT) In-Reply-To: <20130729105242.GB7087@puck.nether.net> References: <20130729105242.GB7087@puck.nether.net> Date: Mon, 29 Jul 2013 20:54:00 +0900 Message-ID: From: KwangKoog Lee To: Jon Mitchell Content-Type: multipart/alternative; boundary=001a1133dde0e9433e04e2a5251b Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-atlas-i2rs-problem-statement-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:54:31 -0000 --001a1133dde0e9433e04e2a5251b Content-Type: text/plain; charset=ISO-8859-1 Hi. This is Kwang-koog from kt which is one of major network providers in South Korea. First, I appreciate a vast of contributions by i2rs members for enabling intelligent and simple routing operations. As Alia mentioned in her draft, many network providers including kt today have very huge and complex routing networks according to the growth of the IP-based services but they really need simple operation and new business model for covering a number of use cases on that. With the benefit of the distributed routing manner, modern routing systems easily plugged into a designated routing network and forward user packets to desired destinations. But, in the operator perspective, policy-based routing control and necessary optimizations for routing are always major issues for them because it is very hard to control multi-vendor ruters with their own proprietary functions. Our company has operated huge routing systems with the size of thousands of routing systems during tens of years and made a significant effort to optimize routing systems. So, current routing systems support preferable service level aggrement and traffic utilization is optimized by the our own planning rules. However, to this end, there have been even much trial-and-error and many times. So, I expect that the works of i2rs help network providers to easily control their network and also support many usecases from our customers. I also think Alia clearly stated such concerns of modern routing systems so that I also support the WG adoption. I2RS members pointed out many comments and feedbacks for enhancing that document which I also agree with. In addition, I give a small comment to her draft for "Sec. 5 desired aspect of a protocol for i2rs" That is "*interoperability between protocol versions*". For example, newly defined software define network protocols such as openflow rapidly changed and a bunch of functions are added. But, nobody does consider the interoperability of such protocols. I think providers are very wonderring that different version protocols can be inter-working or not. So, I want to comment that i2rs protocol has to have this aspect. Thanks. sincerly, Kwang-koog Lee (Ph.D) the advanced institue of technology of kt, South Korea On Mon, Jul 29, 2013 at 7:52 PM, Jon Mitchell wrote: > On 24/07/13 17:53 -0400, Alia Atlas wrote: > > Please review draft-atlas-i2rs-problem-statement-01 and comment on > whether > > it should be adopted by I2RS. Detailed technical conversation is also > most > > welcome. > > > > Support adoption.. some small issues to authors direct. > > -Jon > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1133dde0e9433e04e2a5251b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi. This is Kwang-koog from kt which is one of=A0majo= r network=A0providers=A0in South Korea.
Fir= st, I appreciate a vast of contributions by i2rs members for enabling intel= ligent and simple routing operations.
=A0
As Alia ment= ioned in her draft, many network providers including kt today=A0have very h= uge and complex=A0routing networks
according to the growth of the IP-ba= sed services but they really need simple operation and new business model f= or covering a number of use cases on that.
With the benefit of the distributed routin= g manner, modern routing systems easily plugged into=A0a designated routing= =A0network=A0and=A0
forward=A0user=A0packets to desired destinations. Bu= t,=A0in the operator perspective,=A0policy-based routing control=A0and nece= ssary optimizations for routing=A0are=A0always=A0major issues for them beca= use it is very hard to control multi-vendor ruters with their own proprieta= ry functions.
=A0
Our company = has operated=A0huge routing systems with the size of thousands of routing s= ystems=A0during tens of years
and made a si= gnificant effort to optimize routing systems.
So, current=A0routing systems=A0support preferab= le service level aggrement and traffic utilization is optimized by the=A0ou= r own planning rules.
However, to this end,= there have been even=A0much=A0trial-and-error=A0and many times.
So, I expect that the works of i2rs help network= providers to easily control their network and also support many usecases f= rom our customers.
=A0
I also think Alia clearly=A0stated such concerns of modern routing systems= =A0so that I also=A0support=A0the WG adoption.
I2RS members pointed out many=A0comments and feedbacks=A0for enhancing = that document which=A0I also agree with.=A0
=A0
In addition,= I=A0give=A0a=A0small comment to her draft for "Sec.=A05 desired aspec= t of a protocol for i2rs"
That is &quo= t;interoperability between protocol versions".
For example, newly defined software define netwo= rk protocols such as openflow=A0rapidly changed and a bunch of functions ar= e added.
But, nobody does consider the inte= roperability of such protocols.
I think providers are=A0very wonderring that dif= ferent version protocols can be inter-working or not.
So, I want to comment that i2rs protocol has to have this aspect= .
=A0
Thanks.
=A0
sincerly,
Kwang-koog Lee (Ph.D)
the advanced instit= ue of technology of kt,=A0South Korea


On Mon,= Jul 29, 2013 at 7:52 PM, Jon Mitchell <jrmitche@puck.nether.net> wrote:
On 24/07/13 17:53 -0400, A= lia Atlas wrote:
> Please review draft-atlas-i2rs-problem-statement-01 and comment on whe= ther
> it should be adopted by I2RS. =A0Detailed technical conversation is al= so most
> welcome.
>

Support adoption.. some small issues to authors direct.

-Jon

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

--001a1133dde0e9433e04e2a5251b-- From jrmitche@puck.nether.net Mon Jul 29 06:02:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3FE21F9E2B for ; Mon, 29 Jul 2013 06:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB3KxL64ZoZs for ; Mon, 29 Jul 2013 06:02:45 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2511A21F9E9C for ; Mon, 29 Jul 2013 06:02:31 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6TD2TB6022302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2013 09:02:29 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6TD2T27022301; Mon, 29 Jul 2013 09:02:29 -0400 Date: Mon, 29 Jul 2013 09:02:29 -0400 From: Jon Mitchell To: Thomas Nadeau Message-ID: <20130729130229.GA20218@puck.nether.net> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> <20130729104056.GA7087@puck.nether.net> <40409CD7-451E-41C1-9D77-BC39927CED88@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40409CD7-451E-41C1-9D77-BC39927CED88@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 29 Jul 2013 09:02:29 -0400 (EDT) Cc: Russ White , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:02:46 -0000 On 29/07/13 13:40 +0200, Thomas Nadeau wrote: > > On Jul 29, 2013:1:27 PM, at 1:27 PM, Alia Atlas wrote: > > > From the comments so far, it is clear that there is work to be done on this draft before adoption. I am quite eager to see the set of reasonable use-cases get discussed and put in. > > > > A single draft of BGP use-cases would be good. Once one is adopted, the WG can direct the editors to add cases - if and when there is consensus to do so. > > > > I don't think that a single draft of all I2RS use-cases is at all practical. > > I agree. You also need to consider the fact that things will evolve over time, and as a result that could hold up the progress of the early use cases in the IETF process as other use cases are discovered and added. As you also know, we could gut the entire document and start from scratch just using the draft as a shell that targets that charter item. The point is that the WG has such a charter item, and this document at a minimum, is a good start to satisfy that. As you mention, once its a WG draft, the WG is in control of its content and can alter it as needed. Ed/Alia/Tom - thanks for clarifying that we will have potentially multiple use case drafts but likely only one BGP use case draft in the WG. undertsood that the WG can direct the authors to include the white use cases once WG adopted but I personally would like to know their receptiveness to the use cases in the white draft, and it appears others have posed the same question previously. -Jon From ietfc@btconnect.com Mon Jul 29 07:01:12 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5B811E810E for ; Mon, 29 Jul 2013 07:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuvFLPisPkg8 for ; Mon, 29 Jul 2013 07:00:55 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id E944811E80ED for ; Mon, 29 Jul 2013 07:00:06 -0700 (PDT) Received: from mail1-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 13:59:58 +0000 Received: from mail1-tx2 (localhost [127.0.0.1]) by mail1-tx2-R.bigfish.com (Postfix) with ESMTP id 041A9400163; Mon, 29 Jul 2013 13:59:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail1-tx2 (localhost.localdomain [127.0.0.1]) by mail1-tx2 (MessageSwitch) id 1375106396492929_32526; Mon, 29 Jul 2013 13:59:56 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.235]) by mail1-tx2.bigfish.com (Postfix) with ESMTP id 6953616004B; Mon, 29 Jul 2013 13:59:56 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 13:59:55 +0000 Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.79.164) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 29 Jul 2013 13:59:35 +0000 Message-ID: <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net> From: t.petch To: Russ White , 'Nitin Bahadur' , 'Acee Lindem' , "'Joel M. Halpern'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> Date: Mon, 29 Jul 2013 14:58:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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.53] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%JUNIPER.NET$RO%1$TLS%0$FQDN%$TlsDn% Cc: i2rs@ietf.org, 'Alia Atlas' Subject: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:01:12 -0000 ----- Original Message ----- From: "Russ White" To: "'Nitin Bahadur'" ; "'Acee Lindem'" ; "'Joel M. Halpern'" Cc: ; "'Alia Atlas'" Sent: Monday, July 29, 2013 2:10 AM > My original intent here was to provide "a name" to something that > aggregated all the routing-instances. > Obviously as many have pointed out, giving it the name of "rib" was a bad > choice. > > So we have 2 choices: > - Remove the top-level object in the grammar (rib) completely=A9and instead > start off with routing-instance. > - Rename "rib" (in the grammar) to something better :) Let me ask this: Is there some point to the top level "rib" object? IE, would you ever use an object that encompasses every routing table entry across the box, no matter which specific VRF the route is in? To put it another way --is there any time when you might want to say, "hand me every route you have to 10.1.1.0/24, no matter what the routing context?" Russ After decades of working with router models in the IETF, my ideas are probably rather fossilised, but I think I see some agreement that at one end of the router, there are data structures that are passed to the silicon to use in deciding where to forward packets; while at the other end, there are instances of routing protocols sending and receiving data, maintaining protocol specific data structures as a BGP RIB or OSPF link state database, and processing it in order to derive one or more best routes within the purview of that protocol instance:-) Then there is Something In The Middle, on which I do not see agreement, that takes some or all of the output of the other and passes it to the one. You could regard SITM as being a process with no data; or it might be useful to conceive of it as a data structure, listing all possible routes, or at least all those seen as acceptable to the individual protocol instance. If you are going to apply rules of selection, operational parameters, policy and so on, then regarding SITM as data is one way to do it. I rather expected this to be the approach of i2rs. So I am happy to see an all embracing SITM data structure, as long as its definition makes clear its relationship to the other and the one (as described above). I avoid the use of the usual terminology here for reasons that are probably obvious. Tom Petch I can't think of any reason you'd ever ask this type of question --the context of the route is something you must have to make sense of the route itself. In response to that, I'd say it's best to simply remove the top level object itself. :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From russw@riw.us Mon Jul 29 13:26:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B918A21E809F for ; Mon, 29 Jul 2013 13:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-EP4uWCKB-4 for ; Mon, 29 Jul 2013 13:26:40 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51B21E80AB for ; Mon, 29 Jul 2013 13:26:38 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3u1c-0005nF-8x; Mon, 29 Jul 2013 13:26:36 -0700 From: "Russ White" To: "'t.petch'" , "'Nitin Bahadur'" , "'Acee Lindem'" , "'Joel M. Halpern'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net> In-Reply-To: <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net> Date: Mon, 29 Jul 2013 16:26:38 -0400 Message-ID: <008e01ce8c99$eeb6b7c0$cc242740$@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: AQJqHIjW+VmLbypRNTjXMAWmP6KFlQGgkY4zAbf2o7wB0j7d5pgboiEQ Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:26:46 -0000 > After decades of working with router models in the IETF, my ideas are > probably rather fossilised, but I think I see some agreement that at one end > of the router, there are data structures that are passed to the silicon to use in > deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining > protocol specific data structures as a BGP RIB or OSPF link state database, and > processing it in order to derive one or more best routes within the purview > of that protocol instance:-) The problem is there is no longer "one" database that's passed to the silicon to make an actual forwarding decision --with virtualization, specifically, there's (potentially) a different set per interface, and hence there's a different "RIB" per topology behind these different forwarding table entries (though I hate to use the term "RIB" here). So when you look up a specific destination, you must not only specify the destination, but also the context within which that destination lives. The question becomes --do you want to have something like this: (Context1,10.1.1.0/24) (Context2,10.1.1.0/24) And call that the "RIB," which lives at the top level of the hierarchy? If so, then what do you call the table that lives exclusively in context 1 (or 2), and has a route to 10.1.1.0/24, but is not even aware of other routes to that same destination address because it has no access to the tables in other contexts? This second table is what's traditionally called "the RIB," in my experience. While different people have different experiences, I don't know of anyone who would call the combination of all forwarding table entry contexts into one large table the "RIB." A second way to look at this, I think, is in asking what question you want to be able to ask. Do you want to say: "Find me the route in context 1 that leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select context 1. Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find every route to every possible 10.1.1.0/24 no matter what the context is?" The third question makes no sense to me, as I don't see anything useful you can do with that information. I'm open to suggestions, I just can't think of anything off the top of my head I'd ever want to use that information for, because (Context1,10.1.1.0/24) is actually a completely different destination than (Context2,10.1.1.0/24) --they're only related by their destination address, not by the physical or logical topology in any way. :-) Russ From russw@riw.us Mon Jul 29 13:30:24 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C1421F8FA1 for ; Mon, 29 Jul 2013 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzRmyfFqPAO3 for ; Mon, 29 Jul 2013 13:30:18 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id C466721F94DC for ; Mon, 29 Jul 2013 13:30:17 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3u5A-000617-2f; Mon, 29 Jul 2013 13:30:16 -0700 From: "Russ White" To: "'Sriganesh Kini'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> In-Reply-To: Date: Mon, 29 Jul 2013 16:30:18 -0400 Message-ID: <008f01ce8c9a$71b9d760$552d8620$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJqHIjW+VmLbypRNTjXMAWmP6KFlQGgkY4zAbf2o7wCVjzDapgXhLqA Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Nitin Bahadur' , "'Joel M. Halpern'" , 'Acee Lindem' , 'Alia Atlas' Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:30:24 -0000 > Carlos, good point. But we also need to ask the question of where we > express relationships between routing-contexts. E.g. If VPN-1 is being > transported over Backbone-1 and VPN-2 over Backbone-2. Would these be > inside the routing context or in a top level object ? So you're saying, "what if 10.1.1.0/24 in context 1 is reachable via = 10.1.1.1 in context 2?" The primary way we describe this today is = through tunneling, not through multiple VRF contexts... And I would = never expect to have, "(10.1.1.0/24,context1) is reachable via = (10.1.1.1,context2), and (192.168.1.0/24,context2) is reachable via = (10.1.1.1,context1)." In fact, I think all such situations are probably = really dangerous in the real world, and operators would avoid them like = the plague. But, again, I'm not saying this is a completely nonuseful construct, I'm = just trying to figure out a specific use case for doing such a thing. :-) Russ From jakob.heitz@ericsson.com Mon Jul 29 16:09:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0390121F9C12 for ; Mon, 29 Jul 2013 16:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M33XekPaus-i for ; Mon, 29 Jul 2013 16:09:44 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 618D921F9C0E for ; Mon, 29 Jul 2013 16:09:44 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-44-51f6f6371a5d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 43.3C.31362.736F6F15; Tue, 30 Jul 2013 01:09:43 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 29 Jul 2013 19:09:30 -0400 From: Jakob Heitz To: Russ White , 't.petch' , "'Nitin Bahadur'" , Acee Lindem , "'Joel M. Halpern'" Thread-Topic: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOjJn7XoUgEOq86k6dTaouuiCI1Zl8RAjzgAAEIEU= Date: Mon, 29 Jul 2013 23:09:29 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net>, <008e01ce8c99$eeb6b7c0$cc242740$@riw.us> In-Reply-To: <008e01ce8c99$eeb6b7c0$cc242740$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476eusaamb109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyuXSPn675t2+BBgd3aVh8eniJ2WLdjA8s Ftce3Wex+HjqDZNFQ287m8W6uQfYHdg8dh39we6xc9Zddo8lS34yeZyb8p3R43rTVXaP0w8n swewRXHZpKTmZJalFunbJXBlbLu1iKngmGfFiXO7mBoYb9l0MXJySAiYSMxbfp4FwhaTuHBv PVsXIxeHkMBRRolD/7axQjjLGSXOd/SygVSxCehIfLvexQxiiwjsZZSYvLEMxGYWcJX4efwx K4gtLFAoceVwFyNETZFEx5977BC2lcTKzU/A5rAIqEp8OPAWLM4r4Cvxc/8PqM0/GSXmTz8K 1swpYCrRs/of2DJGoPO+n1rDBLFMXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuEbSrxa8MHRghb WeL7nEcsEL35Epvnb2SGWCwocXLmE5YJjGKzkIydhaRsFpIyiLiexI2pU9ggbG2JZQtfM0PY uhIz/h2CqrGW+LlhIQuymgWMHKsYOUqLU8ty040MNzECI/uYBJvjDsYFnywPMUpzsCiJ827Q OxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTEwmV+7wzEje1dDsr77ww2ecTPCX3iklKrM /8jxoEVRb8ruCvmXs1l+/9NQNig71Go1U3267oS05GU7pI8FZR2RXCUm6qJ3LlcqT/ren+cT jNhLUyYYNm08Xtm5+pdN673PM2QU5uVe/OEq/+Tmq1DfF+/1WvhY5QP8517YV+/r1+51Od5F RImlOCPRUIu5qDgRAHdnDxm6AgAA Cc: "i2rs@ietf.org" , 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:09:50 -0000 --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476eusaamb109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't know about the global RIB, but one thing that should be modeled is the box within which all the RIBs exist. All the RIBs share various resources/objects within the box. Examples are: 1. power supply: if it dies, all the RIBs die. 2. Physical ports. Any RIB can bind to any of them or any VLANs on them. 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) ove= r a single BGP session. 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all o= f them. The RIBs in a box, but not RIBs in a different box have access to all the r= esources in the box. -- Jakob Heitz. ________________________________ From: i2rs-bounces@ietf.org [i2rs-bounces@ietf.org] on behalf of Russ White= [russw@riw.us] Sent: Monday, 29 July 2013 1:26 PM To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern' Cc: i2rs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-= i2rs-rib-info-model-01 (ends Aug 12) > After decades of working with router models in the IETF, my ideas are > probably rather fossilised, but I think I see some agreement that at one end > of the router, there are data structures that are passed to the silicon t= o use in > deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining > protocol specific data structures as a BGP RIB or OSPF link state database, and > processing it in order to derive one or more best routes within the purview > of that protocol instance:-) The problem is there is no longer "one" database that's passed to the silicon to make an actual forwarding decision --with virtualization, specifically, there's (potentially) a different set per interface, and henc= e there's a different "RIB" per topology behind these different forwarding table entries (though I hate to use the term "RIB" here). So when you look up a specific destination, you must not only specify the destination, but also the context within which that destination lives. The question becomes --do you want to have something like this: (Context1,10.1.1.0/24) (Context2,10.1.1.0/24) And call that the "RIB," which lives at the top level of the hierarchy? If so, then what do you call the table that lives exclusively in context 1 (or 2), and has a route to 10.1.1.0/24, but is not even aware of other routes t= o that same destination address because it has no access to the tables in other contexts? This second table is what's traditionally called "the RIB," in my experience. While different people have different experiences, I don'= t know of anyone who would call the combination of all forwarding table entry contexts into one large table the "RIB." A second way to look at this, I think, is in asking what question you want to be able to ask. Do you want to say: "Find me the route in context 1 that leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select context 1. Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find every route to every possible 10.1.1.0/24 no matter what the context is?" The third question makes no sense to me, as I don't see anything useful you can do with that information. I'm open to suggestions, I just can't think o= f anything off the top of my head I'd ever want to use that information for, because (Context1,10.1.1.0/24) is actually a completely different destination than (Context2,10.1.1.0/24) --they're only related by their destination address, not by the physical or logical topology in any way. :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476eusaamb109erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

I don't know about the global RIB, but one thing that

should be modeled is the box within which all the RIBs exist.

All the RIBs share various resources/objects within the box.

Examples are:

1. power supply: if it dies, all the RIBs die.

2. Physical ports. Any RIB can bind to any of them or any VLANs on them.=

3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) = over a single BGP session.

4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to al= l of them.

 

The RIBs in a box, but not RIBs in a different box have access to all th= e resources in the box.

 

--

Jakob Heitz.

From: i2rs-bounces@ietf.org [i2rs-bounces@ietf.org] on behalf of= Russ White [russw@riw.us]
Sent: Monday, 29 July 2013 1:26 PM
To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern'
Cc: i2rs@ietf.org; 'Alia Atlas'
Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-= nitinb-i2rs-rib-info-model-01 (ends Aug 12)


> After decades of working with router models in the IETF, my ideas are<= br> > probably rather fossilised, but I think I see some agreement that at o= ne
end
> of the router, there are data structures that are passed to the silico= n to
use in
> deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining=
> protocol specific data structures as a BGP RIB or OSPF link state
database, and
> processing it in order to derive one or more best routes within the purview
> of that protocol instance:-)

The problem is there is no longer "one" database that's passed to= the
silicon to make an actual forwarding decision --with virtualization,
specifically, there's (potentially) a different set per interface, and henc= e
there's a different "RIB" per topology behind these different for= warding
table entries (though I hate to use the term "RIB" here). So when= you look
up a specific destination, you must not only specify the destination, but also the context within which that destination lives.

The question becomes --do you want to have something like this:

(Context1,10.1.1.0/24)
(Context2,10.1.1.0/24)

And call that the "RIB," which lives at the top level of the hier= archy? If
so, then what do you call the table that lives exclusively in context 1 (or=
2), and has a route to 10.1.1.0/24, but is not even aware of other routes t= o
that same destination address because it has no access to the tables in
other contexts? This second table is what's traditionally called "the = RIB,"
in my experience. While different people have different experiences, I don'= t
know of anyone who would call the combination of all forwarding table entry=
contexts into one large table the "RIB."

A second way to look at this, I think, is in asking what question you want<= br> to be able to ask. Do you want to say: "Find me the route in context 1= that
leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select con= text 1.
Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find e= very route
to every possible 10.1.1.0/24 no matter what the context is?"

The third question makes no sense to me, as I don't see anything useful you=
can do with that information. I'm open to suggestions, I just can't think o= f
anything off the top of my head I'd ever want to use that information for,<= br> because  (Context1,10.1.1.0/24) is actually a completely different
destination than (Context2,10.1.1.0/24) --they're only related by their
destination address, not by the physical or logical topology in any way.
:-)

Russ

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs
--_000_2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476eusaamb109erics_-- From russw@riw.us Mon Jul 29 16:21:00 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2020411E8124 for ; Mon, 29 Jul 2013 16:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkMGL+Sj0Trl for ; Mon, 29 Jul 2013 16:20:54 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4969511E813A for ; Mon, 29 Jul 2013 16:20:54 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V3wkF-0005QQ-N4; Mon, 29 Jul 2013 16:20:51 -0700 From: "Russ White" To: "'Jakob Heitz'" , "'t.petch'" , "'Nitin Bahadur'" , "'Acee Lindem'" , "'Joel M. Halpern'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net>, <008e01ce8c99$eeb6b7c0$cc242740$@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> Date: Mon, 29 Jul 2013 19:20:53 -0400 Message-ID: <014601ce8cb2$469fd3f0$d3df7bd0$@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: AQJqHIjW+VmLbypRNTjXMAWmP6KFlQGgkY4zAbf2o7wB0j7d5gJOPay4AboL9xSX+5JfUA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:21:00 -0000 > I don't know about the global RIB, but one thing that > should be modeled is the box within which all the RIBs exist. I would prefer not to get into modeling the physical box, or anything else that reaches outside the routing system. IMHO, we're already trying to boil the ocean... We should leave management of the box to the management folks, as much as possible (IMHO), and attack the points where there are truly unique, interactive, "things," we can do that the management folks haven't already done. :-) Russ From nitinb@juniper.net Mon Jul 29 16:24:58 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6105021F9BAB for ; Mon, 29 Jul 2013 16:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.084 X-Spam-Level: X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSrkebZhF7QP for ; Mon, 29 Jul 2013 16:24:51 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 373E521F9AFE for ; Mon, 29 Jul 2013 16:24:48 -0700 (PDT) Received: from mail32-db9-R.bigfish.com (10.174.16.251) by DB9EHSOBE012.bigfish.com (10.174.14.75) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 23:24:47 +0000 Received: from mail32-db9 (localhost [127.0.0.1]) by mail32-db9-R.bigfish.com (Postfix) with ESMTP id 4C1C6260210 for ; Mon, 29 Jul 2013 23:24:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85ehzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h18c673h8275bh1de097hz2fh2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail32-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=nitinb@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail32-db9 (localhost.localdomain [127.0.0.1]) by mail32-db9 (MessageSwitch) id 1375140285244812_3497; Mon, 29 Jul 2013 23:24:45 +0000 (UTC) Received: from DB9EHSMHS026.bigfish.com (unknown [10.174.16.234]) by mail32-db9.bigfish.com (Postfix) with ESMTP id 3686E460046 for ; Mon, 29 Jul 2013 23:24:45 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.50) by DB9EHSMHS026.bigfish.com (10.174.14.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 23:24:44 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 16:24:43 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Mon, 29 Jul 2013 16:24:43 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 16:28:51 -0700 Received: from mail155-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 23:24:40 +0000 Received: from mail155-co1 (localhost [127.0.0.1]) by mail155-co1-R.bigfish.com (Postfix) with ESMTP id 9D66F780169 for ; Mon, 29 Jul 2013 23:24:40 +0000 (UTC) Received: from mail155-co1 (localhost.localdomain [127.0.0.1]) by mail155-co1 (MessageSwitch) id 1375140278303424_1281; Mon, 29 Jul 2013 23:24:38 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.242]) by mail155-co1.bigfish.com (Postfix) with ESMTP id 4520460004C; Mon, 29 Jul 2013 23:24:38 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 23:24:38 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0341.000; Mon, 29 Jul 2013 23:24:37 +0000 From: Nitin Bahadur To: Jakob Heitz , Russ White , 't.petch' , Acee Lindem , "'Joel M. Halpern'" Thread-Topic: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOjLLKWeauhD8fpE+0zkAjCuQICQ== Date: Mon, 29 Jul 2013 23:24:36 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: multipart/alternative; boundary="_000_CE1CC54A2BCACnitinbjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RIW.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%JOELHALPERN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" , 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:24:58 -0000 --_000_CE1CC54A2BCACnitinbjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > 1. power supply: if it dies, all the RIBs die. > 2. Physical ports. Any RIB can bind to any of them or any VLANs on them. +1 to Russ's comments in prior email. > 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) o= ver a single BGP session. BGP L3VPN is a specific use-case. The RIB modeling avoid protocol specific = modeling. Also we are not trying to replicate BGP here. So what is modeled = here is the ability to inject routes into a bunch of tables (and the tables= can be contained in routing-instances=85aka VRFs). > 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all= of them. These should be modeled as part of topology. Tunnels are nothing but virtua= l links in a topology. Thanks Nitin --_000_CE1CC54A2BCACnitinbjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

> 1. power supply: if it= dies, all the RIBs die.

> 2. Physical ports. Any RIB can bind to any of them or any VLANs on = them.
+1 to Russ's comments in prior email.

> 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (R= IBs) over a single BGP session.
BGP L3VPN is a specific use-case. The RIB modeling avoid protocol specific = modeling. Also we are not trying to replicate BGP here. So what is modeled = here is the ability to inject routes into a bunch of tables (and the tables= can be contained in routing-instances=85aka VRFs).

> 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access = to all of them.
These should be modeled as part of topology. Tunnels are nothing but virtua= l links in a topology.


Thanks
Nitin
--_000_CE1CC54A2BCACnitinbjunipernet_-- From jrmitche@puck.nether.net Mon Jul 29 17:21:14 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453D721E8090 for ; Mon, 29 Jul 2013 17:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyMq5NTeT9IN for ; Mon, 29 Jul 2013 17:21:13 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8B41921E8054 for ; Mon, 29 Jul 2013 17:21:13 -0700 (PDT) Received: from [IPv6:2001:df8::64:404a:7407:7df0:ae38] ([IPv6:2001:df8:0:64:404a:7407:7df0:ae38]) (authenticated bits=0) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6U0Kw4s008957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jul 2013 20:21:00 -0400 References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net> <008e01ce8c99$eeb6b7c0$cc242740$@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> <014601ce8cb2$469fd3f0$d3df7bd0$@riw.us> Mime-Version: 1.0 (1.0) In-Reply-To: <014601ce8cb2$469fd3f0$d3df7bd0$@riw.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Jon Mitchell Date: Tue, 30 Jul 2013 02:20:57 +0200 To: Russ White X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.1 (puck.nether.net [IPv6:2001:418:3f4::5]); Mon, 29 Jul 2013 20:21:01 -0400 (EDT) Cc: "i2rs@ietf.org" , Jakob Heitz , Nitin Bahadur , "t.petch" , Acee Lindem , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:21:14 -0000 On Jul 30, 2013, at 1:20 AM, "Russ White" wrote: >=20 > I would prefer not to get into modeling the physical box, or anything else= > that reaches outside the routing system. IMHO, we're already trying to boi= l > the ocean... We should leave management of the box to the management folks= , > as much as possible (IMHO), and attack the points where there are truly > unique, interactive, "things,"=20 +1, the only reason the top level context might exist is as a root for i2rs c= lients to interact with (some basic info such as hostname could be provided t= o ensure you are talking to the right device...) -Jon From sriganeshkini@gmail.com Mon Jul 29 23:37:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37921E8051 for ; Mon, 29 Jul 2013 23:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmj98e1k9+rw for ; Mon, 29 Jul 2013 23:37:58 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A78911E8174 for ; Mon, 29 Jul 2013 23:37:58 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so5595907pbc.16 for ; Mon, 29 Jul 2013 23:37:49 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=0tW1FdmaKTRm+upRyyHXtar81r2LUQb1+N+DI1VVA+U=; b=v0hDQSaqDc/3z287Aw309Cro0/e1/vgBfzxD9Cpofu+TxNg9EkQP3D6Zy1Vsti/xD5 rWGndb0/MgN+awExrVIq/mVP/17KIyuhokeR++WQ1hK10HTqsI6aDvqhQESU2KfxQZ5/ FunM2ULmxp0hLoDFqxOsqsIKkUNQ49GN9VCvGWl+QomdsWoj4VpoFrVHHX3D2/onlLPx ct6sg4tb/T459WEG4u48d46zNC8pKLYTE9Ui5aHSKv26ism4gPpSAKQC+vGBi7TSbVlo RtMcpk58VhIOtVOqJZt3EarEJ76Y+nbZfUGur72v+W7cDLgsvRQR8Ou/QNUVBkY5FGER oMQw== X-Received: by 10.68.220.1 with SMTP id ps1mr66547444pbc.30.1375166269736; Mon, 29 Jul 2013 23:37:49 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Mon, 29 Jul 2013 23:37:19 -0700 (PDT) In-Reply-To: References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <009b01ce8c63$d5bff0a0$4001a8c0@gateway.2wire.net> <008e01ce8c99$eeb6b7c0$cc242740$@riw.us> <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> <014601ce8cb2$469fd3f0$d3df7bd0$@riw.us> From: Sriganesh Kini Date: Mon, 29 Jul 2013 23:37:19 -0700 X-Google-Sender-Auth: m9otkYo93GJavQe4rMLLA1ehS2s Message-ID: To: Jon Mitchell Content-Type: multipart/alternative; boundary=e89a8ff1ca7803cf1004e2b4d979 Cc: "i2rs@ietf.org" , Jakob Heitz , Acee Lindem , "t.petch" , Russ White , Nitin Bahadur , "Joel M. Halpern" , Alia Atlas Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:37:59 -0000 --e89a8ff1ca7803cf1004e2b4d979 Content-Type: text/plain; charset=UTF-8 +1 to Russ' comments. Management context, top-level context, local-context, backbone-context, ... etc should not influence whether this information should be at the top-level of the modeling hierarchy. - Sri On Mon, Jul 29, 2013 at 5:20 PM, Jon Mitchell wrote: > > On Jul 30, 2013, at 1:20 AM, "Russ White" wrote: > > > > > I would prefer not to get into modeling the physical box, or anything > else > > that reaches outside the routing system. IMHO, we're already trying to > boil > > the ocean... We should leave management of the box to the management > folks, > > as much as possible (IMHO), and attack the points where there are truly > > unique, interactive, "things," > > +1, the only reason the top level context might exist is as a root for > i2rs clients to interact with (some basic info such as hostname could be > provided to ensure you are talking to the right device...) > > -Jon > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --e89a8ff1ca7803cf1004e2b4d979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Russ' comments.

Management context, top-level context, local-context, backbone-cont= ext, ... etc should not influence whether this information should be at the= top-level of the modeling hierarchy.

- Sri
On Mon, Jul 29, 2013 at 5:20 PM, Jon Mitchell = <jrmitche@puck.nether.net> wrote:

On Jul 30, 2013, at 1:20 AM, "Russ White" <russw@riw.us> wrote:

>
> I would prefer not to get into modeling the physical box, or anything = else
> that reaches outside the routing system. IMHO, we're already tryin= g to boil
> the ocean... We should leave management of the box to the management f= olks,
> as much as possible (IMHO), and attack the points where there are trul= y
> unique, interactive, "things,"

+1, the only reason the top level context might exist is as a root fo= r i2rs clients to interact with (some basic info such as hostname could be = provided to ensure you are talking to the right device...)

-Jon

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

--e89a8ff1ca7803cf1004e2b4d979-- From sriganeshkini@gmail.com Mon Jul 29 23:53:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6416221E80C0 for ; Mon, 29 Jul 2013 23:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ4K7YH8+5qv for ; Mon, 29 Jul 2013 23:53:33 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B446121F9BC3 for ; Mon, 29 Jul 2013 23:53:25 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wy7so5601551pbc.31 for ; Mon, 29 Jul 2013 23:53:25 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=L9lgmLogKo7uYyPo0j3f/mVmsz/EZ7MGDwSexGF5F5U=; b=VBKGGoSBFm4P8zl+LBH9b3pxhNu6vHVxU0DejPXxfSRr4ShUZa4HhBdJVp+ehUa6EN onBErU5Aw2OMLVrqwRKNK1xoz7NWb/qvpsHq/zmofG44no4Py6ey1kk6kKutWeVOqFWs vbR8I95CuSx76yZTLCfvGbJViYO/vnRp+3whuLgJNPcrcU664hxSxEVwmtRyLqN6Mgmx SSbtMyLbQ0Pa99HZpLPqJR3YE9D3x9mtlAGv7Y21rGRTyCdxI3+oP2ou3rpzEMjy47Dl /PNe6j+ErZ1pZrz8pF/1x8rKVIQBuSzBB/ZBR9OSGSigTPXyFzrWZEDkqGNJK1YBkSKE brKQ== X-Received: by 10.68.2.69 with SMTP id 5mr72446408pbs.124.1375167204957; Mon, 29 Jul 2013 23:53:24 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Mon, 29 Jul 2013 23:52:54 -0700 (PDT) In-Reply-To: <008f01ce8c9a$71b9d760$552d8620$@riw.us> References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <008f01ce8c9a$71b9d760$552d8620$@riw.us> From: Sriganesh Kini Date: Mon, 29 Jul 2013 23:52:54 -0700 X-Google-Sender-Auth: Y58k0n-wtOm3z7_QXfMQn-LtrXo Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=bcaec52156bdc223b804e2b51073 Cc: "i2rs@ietf.org" , Nitin Bahadur , "Joel M. Halpern" , Acee Lindem , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:53:50 -0000 --bcaec52156bdc223b804e2b51073 Content-Type: text/plain; charset=UTF-8 Russ, I am not not talking about the resolution of nexthops in another context. BTW we have not modeled a "context", so there is every possibility we are talking different things. I am considering the case where there is more than one backbone to provide BGP/MPLS IP VPNs. The use-case could be purely for administrative purposes. If we put the restriction that there is a single backbone, then it is clear as to how the VRF routing-instance traffic is tunneled over. So RIB could be below the routing-instance in the hierarchy. If there can be multiple backbones, then the relationship has to be expressed as to which backbone the VRF is tunneled over. This information could be in a structure that is not below the routing-instance in the hierarchy. - Sri On Mon, Jul 29, 2013 at 1:30 PM, Russ White wrote: > > > Carlos, good point. But we also need to ask the question of where we > > express relationships between routing-contexts. E.g. If VPN-1 is being > > transported over Backbone-1 and VPN-2 over Backbone-2. Would these be > > inside the routing context or in a top level object ? > > So you're saying, "what if 10.1.1.0/24 in context 1 is reachable via > 10.1.1.1 in context 2?" The primary way we describe this today is through > tunneling, not through multiple VRF contexts... And I would never expect to > have, "(10.1.1.0/24,context1) is reachable via (10.1.1.1,context2), and ( > 192.168.1.0/24,context2) is reachable via (10.1.1.1,context1)." In fact, > I think all such situations are probably really dangerous in the real > world, and operators would avoid them like the plague. > > But, again, I'm not saying this is a completely nonuseful construct, I'm > just trying to figure out a specific use case for doing such a thing. > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --bcaec52156bdc223b804e2b51073 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Russ,

I am not not talking a= bout the resolution of nexthops in another context. BTW we have not modeled= a "context", so there is every possibility we are talking differ= ent things.

I am considering the case where there is more than one = backbone to provide BGP/MPLS IP VPNs. The use-case could be purely for admi= nistrative purposes.

If we put the restriction tha= t there is a single backbone, then it is clear as to how the VRF routing-in= stance traffic is tunneled over. So RIB could be below the routing-instance= in the hierarchy. If there can be multiple backbones, then the relationshi= p has to be expressed as to which backbone the VRF is tunneled over. This i= nformation could be in a structure that is not below the routing-instance i= n the hierarchy.

- Sri


On Mon, Jul 29, 2013 at 1:30 PM, Russ Wh= ite <russw@riw.us> wrote:

> Carlos, good point. But we also need to ask the question of where we > express relationships between routing-contexts. E.g. If VPN-1 is being=
> transported over Backbone-1 and VPN-2 over Backbone-2. Would these be<= br> > inside the routing context or in a top level object ?

So you're saying, "what if 10.1.1.0/24 in context 1 is reachable via 10.1.1.1 in c= ontext 2?" The primary way we describe this today is through tunneling= , not through multiple VRF contexts... And I would never expect to have, &q= uot;(10.1.1.0/24,= context1) is reachable via (10.1.1.1,context2), and (192.168.1.0/24,context2) is = reachable via (10.1.1.1,context1)." In fact, I think all such situatio= ns are probably really dangerous in the real world, and operators would avo= id them like the plague.

But, again, I'm not saying this is a completely nonuseful construct, I&= #39;m just trying to figure out a specific use case for doing such a thing.=

:-)

Russ


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

--bcaec52156bdc223b804e2b51073-- From jrmitche@puck.nether.net Tue Jul 30 04:49:45 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0AF21F93F3 for ; Tue, 30 Jul 2013 04:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB1tbNzae6n7 for ; Tue, 30 Jul 2013 04:49:44 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 621CD21F8EFE for ; Tue, 30 Jul 2013 04:49:44 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6UBng4F029552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jul 2013 07:49:42 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6UBngla029551; Tue, 30 Jul 2013 07:49:42 -0400 Date: Tue, 30 Jul 2013 07:49:42 -0400 From: Jon Mitchell To: Thomas Nadeau Message-ID: <20130730114942.GA29393@puck.nether.net> References: <039801ce8bf0$c7caed60$5760c820$@riw.us> <20130729104056.GA7087@puck.nether.net> <40409CD7-451E-41C1-9D77-BC39927CED88@lucidvision.com> <20130729130229.GA20218@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130729130229.GA20218@puck.nether.net> X-IMAPbase: 1365870647 0000000001 X-UID: 1 User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Tue, 30 Jul 2013 07:49:43 -0400 (EDT) Cc: Russ White , "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:49:45 -0000 On 29/07/13 09:02 -0400, Jon Mitchell wrote: > multiple use case drafts but likely only one BGP use case draft in the > WG. undertsood that the WG can direct the authors to include the > white use cases once WG adopted but I personally would like to know > their receptiveness to the use cases in the white draft, and it > appears others have posed the same question previously. Based on my discussion with Keyur in person - I'm satisfied he will work with the the other authors to integrate WG relevant use cases from draft-white-i2rs-use-case-00 draft into the document if adopted, so I now support it's adoption. Here is my view on the differences between the drafts: I'd like to see Sections 3,5,6 from the white draft integrated. Section 3 overlaps some with content in keyupdate but does not specify using FlowSpec routes for DDoS diversion; presumably you could divert traffic directly through i2rs messaging (if such a thing will exist). Sections 2/7 are basically covered by the keyupdate doc, although certainly useful text could be merged. Use case in section 4 is not on my list, maybe others feel strongly for it. Thanks, -Jon From russw@riw.us Tue Jul 30 05:26:41 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232B511E81E1 for ; Tue, 30 Jul 2013 05:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lpYA+4K7Aje for ; Tue, 30 Jul 2013 05:26:24 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7321E80A7 for ; Tue, 30 Jul 2013 05:26:12 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V490A-0006eX-2G; Tue, 30 Jul 2013 05:26:06 -0700 From: "Russ White" To: "'Sriganesh Kini'" References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <008f01ce8c9a$71b9d760$552d8620$@riw.us> In-Reply-To: Date: Tue, 30 Jul 2013 08:26:09 -0400 Message-ID: <021e01ce8d1f$f9660b40$ec3221c0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJqHIjW+VmLbypRNTjXMAWmP6KFlQGgkY4zAbf2o7wCVjzDagIpDqe/Aiv95SuX9eeFUA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Nitin Bahadur' , "'Joel M. Halpern'" , 'Acee Lindem' , 'Alia Atlas' Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:26:44 -0000 > I am considering the case where there is more than one backbone to = provide > BGP/MPLS IP VPNs. The use-case could be purely for administrative > purposes. If there are multiple backbones (I think you mean multiple VRFs across a = single set of physical links here), then there wouldn't be one "RIB" at = the "top of the hierarchy." There would be multiple "RIBs," with each = one (possibly) bearing the same set of destinations IP address wise, = while actually reaching different topological destinations in the = network. The only way to make these multiple "RIBs" into a single "RIB," = would be to include some form of context identifier, such as a VRF = number or RD, to distinguish between the different destinations.=20 Your argument actually argues against a single "RIB" at the top of the = hierarchy, rather than for it.=20 :-) Russ From nitinb@juniper.net Tue Jul 30 05:40:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A201D11E814F for ; Tue, 30 Jul 2013 05:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.507 X-Spam-Level: X-Spam-Status: No, score=-0.507 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQlg0fcLccxC for ; Tue, 30 Jul 2013 05:40:34 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9550D21F9EF8 for ; Tue, 30 Jul 2013 05:40:33 -0700 (PDT) Received: from mail14-va3-R.bigfish.com (10.7.14.228) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 30 Jul 2013 12:40:32 +0000 Received: from mail14-va3 (localhost [127.0.0.1]) by mail14-va3-R.bigfish.com (Postfix) with ESMTP id 71E9B1000E9 for ; Tue, 30 Jul 2013 12:40:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail14-va3: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=nitinb@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail14-va3 (localhost.localdomain [127.0.0.1]) by mail14-va3 (MessageSwitch) id 1375188029434341_22294; Tue, 30 Jul 2013 12:40:29 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.235]) by mail14-va3.bigfish.com (Postfix) with ESMTP id 6555160047 for ; Tue, 30 Jul 2013 12:40:29 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:40:28 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 05:40:27 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 05:40:27 -0700 Received: from DB8EHSOBE001.bigfish.com (213.199.154.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 05:44:36 -0700 Received: from mail73-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE001.bigfish.com (10.174.4.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 12:40:25 +0000 Received: from mail73-db8 (localhost [127.0.0.1]) by mail73-db8-R.bigfish.com (Postfix) with ESMTP id 1D22B5000F4 for ; Tue, 30 Jul 2013 12:40:25 +0000 (UTC) Received: from mail73-db8 (localhost.localdomain [127.0.0.1]) by mail73-db8 (MessageSwitch) id 1375188022276054_14739; Tue, 30 Jul 2013 12:40:22 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.231]) by mail73-db8.bigfish.com (Postfix) with ESMTP id 34F58900048; Tue, 30 Jul 2013 12:40:22 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:40:20 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 12:40:13 +0000 From: Nitin Bahadur To: "Carlos Pignataro (cpignata)" , Alia Atlas Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOjSHvmSB9wAiFVU6fHOffnoJWMw== Date: Tue, 30 Jul 2013 12:40:12 +0000 Message-ID: In-Reply-To: <95067C434CE250468B77282634C96ED322D5EDCF@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:40:46 -0000 Hi Carlos, Thanks for the detailed review. Please see inline below. On 7/29/13 12:05 AM, "Carlos Pignataro (cpignata)" wrote: >Hi, > >I have concerns with adopting this document. > >As others have mentioned on the list, the concepts of RIB and routing >instance seem to be inverted. Yes, I have removed "RIB" as a top-level container to avoid the confusion/inversion-issue. >But in addition to that, there seem to be two other issues with the >document in its current shape: >1. It's not clear the scope of what's within the Routing Information Base >information model. Specifically, elements defined seem to belong in the >FIB and not the RIB. Besides the routing table, which other elements did you have in mind. Regarding "routing tables" as an element of the FIB, then I think it's a terminology mis-understanding. A routing-table (as per this draft) is something that is local to the control plane and has nothing to do with the forwarding plane. A routing-table (as per this draft) is a database containing route information. Now if this terminology conflicts/confuses with how hardware vendors use the same term, I would be happy to change the name to something else (maybe call it a RIB). I hope you now understand why I did not think of it as a FIB construct. >2. The document structure seems to have gaps and overlaps, and lacks a >compiled set of definitions of RIB elements. Compiled set of definitions of the elements is on my TODO list. I'll likely add an Appendix at the end. > >Please find below some additional questions and observations on the >document, marked with "CMP". > >I hope these are clear and useful. > > Routing Information Base Info Model > draft-nitinb-i2rs-rib-info-model-01 > >1. Introduction > > The rest of this document is organized as follows. Section 2.1 goes > into the details of what constitutes and can be programmed in a RIB. > Section 5 provides a high-level view of the events and notifications > going from a network device to an external entity, to update the > external entity on asynchronous events. The RIB grammar is specified > in Section 6. Examples of using the RIB grammar are shown in > Section 7. > >CMP: What about other Sections? From 2.1 it jumps to Section 5 Will be cleaned up in next rev. > > and not proactive push (from the router) mechanisms. Screen scraping > is error prone (since output can change) and vendor dependent. > >CMP: A nit -- the output will change. I think "since the output format >can change" is what's meant. Will fix. >2.1. RIB definition > > A RIB is a logical construct controlled by an external entity. A RIB > contains one or more routing instances. On a network device, a RIB > is uniquely identified by its name. A routing instance can be in > only 1 RIB. A routing instance, in the context of the RIB > information model, is a collection of routing tables, interfaces, and > routing parameters. A routing instance creates a logical slice of > the router and allows different logical slices; across a set of > routers; to communicate with other each. > >CMP: I think these set of definitions could use a visual to describe >what's a RIB, routing instance, routing tables and their high-level >elements, in addition to itemized definitions. I have a UML diagram representing this, but there is no way to imbed images in IETF drafts (maybe time to change IETF draft format?). I'll add a text form of a diagram for readability. > Layer 3 Virtual Private > Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service > (VPLS) can be modeled as routing instances. > >CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as >routing instances. Which L3 elements are there in an L2VPN? There are no L3 elements in a L2VPN. However, one can (if one really wants) setup a static PW through the RIB model and then map MAC routes to that PW. You can argue that MAC routes shouldn't be a part of this draft and I'll be happy to remove it if there is consensus. > Note that modeling a > Layer 2 VPN using a routing instance only models the Layer-3 (RIB) > aspect and does not model any layer-2 information (like ARP) that > might be associated with the L2VPN. > >CMP: DOes this mean that ARP should be out of the RIB model? ARP should be out of the RIB model. ARP is a network-device local function. >2.2. Routing tables > > A routing table is an entity that contains routes. A routing table > is identified by its name. The name MUST be unique within a RIB. > All routes in a given routing table MUST be of the same type (e.g. > IPv4). Each routing table MUST belong to some routing instance. > >CMP: Should you also differentiate, in addition to the AF, by unicast >versus multicast? It would be good if someone kept unicast & mcast in different tables, but the model does not enforce that. > Each route table can be optionally associated with a > ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding > (RPF) checks on all IP routes in that table. Reverse path forwarding > >CMP: Is RPF an attribute of the routing table? In reality, RPF is an attribute of the route. But it's simpler if it is associated with the entire table..so you do an RPF check for all routes in that table. It is possible to move this as an attribute of the route and if folks prefer that, it's an easy change. >2.3. Route > > 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. This document specifies the > following match types: > >CMP: What is an "MPLS Route" in the context of a routing table? MPLS route is nothing but a mpls label match. > > o IPv4: Match on destination IP in IPv4 header > o IPv6: Match on destination IP in IPv6 header > o MPLS: Match on a MPLS tag > o MAC: Match on ethernet destination addresses > >CMP: Is the MAC address a match element within routing? MAC address is really not a routing concept. But given that we have mac addresses being passed around in E-VPN and that VPLS deals with MAC addresses, there was sufficient motive to add MAC address match. >Or what types of address families and identifiers are input to defining >the elements included? I'm not sure if I understand the above question. AF_IP, AF_IPV6, AF_MPLS? >2.4.1. Nexthop types > > o Special nexthops - for performing specific well-defined functions > >CMP: Are things like the drop/null route fitting here? Are there many >different kinds of specials, or should they be listed explicitly? They should be called out explicitly someplace but not here. This is more of an overview of the info model and putting in all the details in this section would disturb the overall flow. >6. RIB grammar > > ::=3D | | > | > >CMP: Why these families? It doesn't make sense to put IPv4 routes and IPv6 routes together. Currently, routing vendors have well-defined table names that implicitly identify the address family of routes in a given table. Intent here is to remove that implicit assumption. >=20 >CMP: Do you need to separate IPv4 in unicast versus multicast? Or are you >modeling a single table with attributes for the uni/multicast? As I said before, it's up to the I2RS server (controller) to create multiple tables (one for unicast and one for mcast). If the WG feel strongly, we can enforce that in the model. =20 > ::=3D > >CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"? I don't know. Last I remember, in rBNF, all terminal stuff should be all CAPS. Thanks Nitin From nitinb@juniper.net Tue Jul 30 05:58:10 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0343B21E80DB for ; Tue, 30 Jul 2013 05:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLiPrwz5gvy5 for ; Tue, 30 Jul 2013 05:58:03 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id DA26A11E81F3 for ; Tue, 30 Jul 2013 05:58:02 -0700 (PDT) Received: from mail176-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE004.bigfish.com (10.174.4.67) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 12:58:00 +0000 Received: from mail176-db8 (localhost [127.0.0.1]) by mail176-db8-R.bigfish.com (Postfix) with ESMTP id 942B7D800DF for ; Tue, 30 Jul 2013 12:58:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h683h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail176-db8: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=nitinb@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail176-db8 (localhost.localdomain [127.0.0.1]) by mail176-db8 (MessageSwitch) id 137518907866370_20828; Tue, 30 Jul 2013 12:57:58 +0000 (UTC) Received: from DB8EHSMHS027.bigfish.com (unknown [10.174.8.238]) by mail176-db8.bigfish.com (Postfix) with ESMTP id F3A2B160048 for ; Tue, 30 Jul 2013 12:57:57 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.50) by DB8EHSMHS027.bigfish.com (10.174.4.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:57:58 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 05:57:55 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Tue, 30 Jul 2013 05:57:55 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 30 Jul 2013 06:10:53 -0700 Received: from mail75-co1-R.bigfish.com (10.243.78.250) by CO1EHSOBE017.bigfish.com (10.243.66.80) with Microsoft SMTP Server id 14.1.225.22; Tue, 30 Jul 2013 12:57:55 +0000 Received: from mail75-co1 (localhost [127.0.0.1]) by mail75-co1-R.bigfish.com (Postfix) with ESMTP id 03E463C0259 for ; Tue, 30 Jul 2013 12:57:55 +0000 (UTC) Received: from mail75-co1 (localhost.localdomain [127.0.0.1]) by mail75-co1 (MessageSwitch) id 1375189073882600_29764; Tue, 30 Jul 2013 12:57:53 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.227]) by mail75-co1.bigfish.com (Postfix) with ESMTP id D32CE30004E; Tue, 30 Jul 2013 12:57:53 +0000 (UTC) Received: from SN2PRD0510HT005.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 30 Jul 2013 12:57:53 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.143]) by SN2PRD0510HT005.namprd05.prod.outlook.com ([10.255.116.40]) with mapi id 14.16.0341.000; Tue, 30 Jul 2013 12:57:48 +0000 From: Nitin Bahadur To: t.petch Thread-Topic: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOiLwErF8aRPkwVkGXnQxOro1qa5l0NGsAgAB7nwCAAmuKtYAGPT4A Date: Tue, 30 Jul 2013 12:57:48 +0000 Message-ID: In-Reply-To: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:58:10 -0000 Hi Tom, Thanks for your comments. Please see inline below. On 7/26/13 5:39 PM, "t.petch" wrote: >I oppose adoption of this I-D. The use of terminology seems >incompatible with the use of the same terminology elsewhere and, >arguably, contradicts the charter. > >For example, this I-D says > >" A RIB > contains one or more routing instances. > A routing instance, in the context of the RIB > information model, is a collection of routing tables, interfaces, and > routing parameters. > The routing tables specify how incoming > traffic is to be forwarded." > >whereas the charter clearly differentiates the RIB, which is the subject >of this WG, from the FIB, which is not. The reference here to routing >tables sounds rather like a FIB. Regarding "routing tables" as an element of the FIB, then I think it's a terminology mis-understanding. A routing-table (as per this draft) is something that is local to the control plane and has nothing to do with the forwarding plane. A routing-table (as per this draft) is a database containing route information. Now if this terminology conflicts/confuses with how some hardware vendors use the same term, I would be happy to change the name to something else (maybe call it a RIB). I hope you now understand why I did not think of it as a FIB construct. >And the I-D places heavy emphasis on interfaces which again seems to >have >nothing to do with the charter. It's unclear to me how you program a route without an associated interface where the data gets sent out. For example in OSPF, if one learns a route via OSPF, you know from which neighbor you learnt it from and you know the interface associated with it as well. That's how the router is able to send the packets out to the destination. In the case of DDOS mitigation, you might want to add a route that drops packets from most offending prefixes. But for some of the offending prefixes, you might want to forward the packets to a monitoring station (a station that is directly connected to the router and does not speak IGP). So the only way is to add a route pointing to an interface. This is very similar to how static routes are configured on routers today. AFAIK, a lot of operators use static routes and if we get rid of the "interface" object, then a whole class of static routes cannot be programmed using the RIB IM model. Similarly, you won't be able perform things like RPF check=8Awithout which multicast will be crippled. >This topic has surfaced several times on several WG lists, none of which >has produced an agreed document, but the best one would appear to me to >agree that there are processes, not just data, and that these processes >are tied to routing protocols, and that the data thereof needs to be >split into three > - a RIB (in the sense that I most often see it used) containing the >data used by a protocol process instance This is what is contained in the contents of the "routing table". >- a central database of consolidated routes, sometime referred to as >RIB2 This is not necessarily exposed to the external controller. At least it's not easily possible in the current information model. The RIB IM draft basically calls for programming routes in tables (say RIBs) and if a route gets selected as the best route (Eg. For a given IP prefix), then the external controller is informed that the route it programmed is now installed and will be used by silicon for forwarding). >- what gets used in forwarding, usually by the silicon. This should not be exposed to the controller=8Asince it contains forwarding details as well. Thanks Nitin From sriganeshkini@gmail.com Tue Jul 30 07:42:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E121E80FC for ; Tue, 30 Jul 2013 07:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9v2w4Yyducl for ; Tue, 30 Jul 2013 07:42:47 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9297011E8218 for ; Tue, 30 Jul 2013 07:42:46 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so2876566pbb.13 for ; Tue, 30 Jul 2013 07:42:41 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bc67f2UZr5t9ZVKJyFcXRqmimyhBxcuZC/JnRUpTVyg=; b=tgweJOHp8ulWKR67yIOEJ1tjcTGHn4RS3VNo+TTsppHQKjm4XarvQRRn9GbaWXGYHJ OE49oqJDHWmNYkz2NGBf3VlJA3JNdMK+NkJVP7ZoE07ivqbdJzVpKqa7yTCA1hd6EMty yNvUv1NGxHloWWOiBY4DV10oTdk/VvzOvSHhyDP/4dORFagJx1IHNKdnjS90cmp1WxJR 94d2Cl4B80g8S0TefOniRtKRAjBoeqlINsXSID4ECzwtPMYSmL3a9CZc0+E30bAiZrEp mRuhjd7UQNyHqLttY2X5qlI6YaFiVMuZYFP6W5FWxpxYiEOH97KSQANIFFmcW7ZFXf1B TE5A== X-Received: by 10.66.193.98 with SMTP id hn2mr35921157pac.173.1375195360934; Tue, 30 Jul 2013 07:42:40 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Tue, 30 Jul 2013 07:42:10 -0700 (PDT) In-Reply-To: <021e01ce8d1f$f9660b40$ec3221c0$@riw.us> References: <94A203EA12AECE4BA92D42DBFFE0AE4702FB875C@eusaamb106.ericsson.se> <03a301ce8bf8$7a82dd30$6f889790$@riw.us> <008f01ce8c9a$71b9d760$552d8620$@riw.us> <021e01ce8d1f$f9660b40$ec3221c0$@riw.us> From: Sriganesh Kini Date: Tue, 30 Jul 2013 07:42:10 -0700 X-Google-Sender-Auth: LiDZhXnMnCbEsYMw_xhfFs-oRa0 Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=047d7bdc9d60fc42a404e2bb9e53 Cc: "i2rs@ietf.org" , Nitin Bahadur , "Joel M. Halpern" , Acee Lindem , Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:42:47 -0000 --047d7bdc9d60fc42a404e2bb9e53 Content-Type: text/plain; charset=UTF-8 As Nitin already pointed out in another email we have removed RIB from the top-level of the hierarchy. I wasn't arguing to make a single RIB at the top of hierarchy, but rather seeing if by moving the RIB tables to under routing-instance there would still be any information that would still make sense at the top-level. It doesn't seem there is such information. Having some context identifier is a given in any case. On Tue, Jul 30, 2013 at 5:26 AM, Russ White wrote: > > > I am considering the case where there is more than one backbone to > provide > > BGP/MPLS IP VPNs. The use-case could be purely for administrative > > purposes. > > If there are multiple backbones (I think you mean multiple VRFs across a > single set of physical links here), then there wouldn't be one "RIB" at the > "top of the hierarchy." There would be multiple "RIBs," with each one > (possibly) bearing the same set of destinations IP address wise, while > actually reaching different topological destinations in the network. The > only way to make these multiple "RIBs" into a single "RIB," would be to > include some form of context identifier, such as a VRF number or RD, to > distinguish between the different destinations. > > Your argument actually argues against a single "RIB" at the top of the > hierarchy, rather than for it. > > :-) > > Russ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7bdc9d60fc42a404e2bb9e53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As Nitin already pointed out in another email we have remo= ved RIB from the top-level of the hierarchy. I wasn't arguing to make a= single RIB at the top of hierarchy, but rather seeing if by moving the RIB= tables to under routing-instance there would still be any information that= would still make sense at the top-level. It doesn't seem there is such= information. Having some context identifier is a given in any case.


On Tue, Jul 3= 0, 2013 at 5:26 AM, Russ White <russw@riw.us> wrote:

> I am considering the case where there is more than one backbone to pro= vide
> BGP/MPLS IP VPNs. The use-case could be purely for administrative
> purposes.

If there are multiple backbones (I think you mean multiple VRFs acros= s a single set of physical links here), then there wouldn't be one &quo= t;RIB" at the "top of the hierarchy." There would be multipl= e "RIBs," with each one (possibly) bearing the same set of destin= ations IP address wise, while actually reaching different topological desti= nations in the network. The only way to make these multiple "RIBs"= ; into a single "RIB," would be to include some form of context i= dentifier, such as a VRF number or RD, to distinguish between the different= destinations.

Your argument actually argues against a single "RIB" at the top o= f the hierarchy, rather than for it.

:-)

Russ

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

--047d7bdc9d60fc42a404e2bb9e53-- From russw@riw.us Tue Jul 30 07:53:50 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1251711E8210 for ; Tue, 30 Jul 2013 07:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frVOA3-FCDPm for ; Tue, 30 Jul 2013 07:53:43 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id AD69D21F9CC2 for ; Tue, 30 Jul 2013 07:53:43 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V4BJ1-0007yJ-8K; Tue, 30 Jul 2013 07:53:43 -0700 From: "Russ White" To: "'Nitin Bahadur'" , "'t.petch'" References: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> In-Reply-To: Date: Tue, 30 Jul 2013 10:53:47 -0400 Message-ID: <009501ce8d34$98aeee60$ca0ccb20$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFt3Opqukwf0F4wQJPxbWNeef6ZFJo+rXfA Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:53:50 -0000 > >And the I-D places heavy emphasis on interfaces which again seems to > >have nothing to do with the charter. >=20 > It's unclear to me how you program a route without an associated = interface > where the data gets sent out. For example in OSPF, if one learns a = route via > OSPF, you know from which neighbor you learnt it from and you know the > interface associated with it as well. That's how the router is able to send the > packets out to the destination. Actually, it isn't... Routing protocols install routes to a next hop, = which is then recursed to find the best interface (or set of interfaces) by = which the local forwarding plane can reach that next hop. I would avoid = telling the RIB which specific interface to use, as this could have very = negative effects on load sharing and fast failover solutions --unless the = specific intent is to provide for load sharing on a per interface level in I2RS. = I would argue that's more of a job for OpenFlow than I2RS, though. > In the case of DDOS mitigation, you might want to add a route that = drops > packets from most offending prefixes. But for some of the offending > prefixes, you might want to forward the packets to a monitoring = station (a > station that is directly connected to the router and does not speak = IGP). You can do this with the full tuple in the IP header --you don't need = the interface for this specific use case (unless you're programming a = switch, which isn't where I2RS should be, IMHO). > So the only way is to add a route pointing to an interface. This is = very similar > to how static routes are configured on routers today. AFAIK, a lot of > operators use static routes and if we get rid of the "interface" > object, then a whole class of static routes cannot be programmed using = the > RIB IM model. Similarly, you won't be able perform things like RPF > check=A9without which multicast will be crippled. I assume you're talking about a static to an interface. For this = specific case, I would argue that we should wait and see if that's really a requirement --statics to interface aren't (normally) in operational best practices, so I don't know the value of supporting them. For point-to-points, just use the other end of the link, and for broadcast, = a static to an interface is generally not a really good idea (ARP cache).=20 For uRPF and OILs, I'm not certain you need the interface... uRPF, for instance, doesn't rely on direct programming of the expected inbound interface, but rather the "previous hop" being examined recursively in = the routing table to figure out what the correct inbound interface is. You = don't want uRPF to break because the route to you from some specific source changes...=20 > >- a central database of consolidated routes, sometime referred to as > >RIB2 >=20 > This is not necessarily exposed to the external controller. At least = it's not > easily possible in the current information model. The RIB IM draft basically > calls for programming routes in tables (say RIBs) and if a route gets selected > as the best route (Eg. For a given IP prefix), then the external controller is > informed that the route it programmed is now installed and will be = used by > silicon for forwarding). Which is all only useful within the virtual context. It's been a long = long time since routers only had one "RIB." :-) Russ From jrmitche@puck.nether.net Tue Jul 30 08:07:17 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD21921E80D8 for ; Tue, 30 Jul 2013 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEzTiQfqR6be for ; Tue, 30 Jul 2013 08:07:06 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id EA55211E81C6 for ; Tue, 30 Jul 2013 08:06:57 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6UF6jAe016434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jul 2013 11:06:45 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6UF6j12016433; Tue, 30 Jul 2013 11:06:45 -0400 Date: Tue, 30 Jul 2013 11:06:45 -0400 From: Jon Mitchell To: Russ White Message-ID: <20130730150644.GA15347@puck.nether.net> References: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> <009501ce8d34$98aeee60$ca0ccb20$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <009501ce8d34$98aeee60$ca0ccb20$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Tue, 30 Jul 2013 11:06:46 -0400 (EDT) Cc: i2rs@ietf.org, 'Nitin Bahadur' , "'t.petch'" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:07:18 -0000 On 30/07/13 10:53 -0400, Russ White wrote: > > > So the only way is to add a route pointing to an interface. This is very > similar > > to how static routes are configured on routers today. AFAIK, a lot of > > operators use static routes and if we get rid of the "interface" > > object, then a whole class of static routes cannot be programmed using the > > RIB IM model. Similarly, you won't be able perform things like RPF > > checkŠwithout which multicast will be crippled. > > I assume you're talking about a static to an interface. For this specific > case, I would argue that we should wait and see if that's really a > requirement --statics to interface aren't (normally) in operational best > practices, so I don't know the value of supporting them. For > point-to-points, just use the other end of the link, and for broadcast, a > static to an interface is generally not a really good idea (ARP cache). I'm not sure I agree with this... specifying interface + IPv4/v6 NH on some platforms can be useful specifically to stop recursion when the interface goes down by for a nexthop that otherwise may recurse (often to an aggregate or default). Whether it's required to program static routes in i2rs I don't know, but if we plan to support it, a way to stop undesired recursion would be useful. Jon From sriganeshkini@gmail.com Tue Jul 30 08:55:46 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41521F9A0C for ; Tue, 30 Jul 2013 08:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NduuXghfNemv for ; Tue, 30 Jul 2013 08:55:45 -0700 (PDT) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id AAA6E11E822E for ; Tue, 30 Jul 2013 08:55:25 -0700 (PDT) Received: by mail-da0-f51.google.com with SMTP id z8so15097daj.24 for ; Tue, 30 Jul 2013 08:55:25 -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 :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iIkDWo+kdECb7rSAsnXFwseO+H6CFF7bYOSUa4FpqeA=; b=zoLShtaewGDlKK5CdVxH9wRPtvthkRn4YXbcHb7TB5RjT2D5wfbIviWmwImw3vCivy 4g9rbZoa8dxgrA6+GsUVzIqJ+HBphlpDMbFWJQJLrfrggqANRvZEfmqjitCyLdXW5QwS 5Dydl1vlVYFJ1/+pglSS4wOfWnlXyBphbOVEOi613gIi2z1qAHzZUedY8rXbHX7gaLM8 T50ttFYO2BS+zPX/9aDF1s3VrNXZBsxmGoCdZqrdQylVsc36yDpXUoOVNTiXSOeqUGjQ K8AmXyE9YZrstF2EJ6GtUzSAcfAusL02EEPAU5EqsZO5tb2AsS+RkaZflgTjycLs2T3T 2hiw== X-Received: by 10.68.220.1 with SMTP id ps1mr69087282pbc.30.1375199725338; Tue, 30 Jul 2013 08:55:25 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.52.162 with HTTP; Tue, 30 Jul 2013 08:54:55 -0700 (PDT) In-Reply-To: <009501ce8d34$98aeee60$ca0ccb20$@riw.us> References: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> <009501ce8d34$98aeee60$ca0ccb20$@riw.us> From: Sriganesh Kini Date: Tue, 30 Jul 2013 08:54:55 -0700 X-Google-Sender-Auth: eznD-0Sfr2JcSTObNzSjPwekg3Y Message-ID: To: Russ White Content-Type: multipart/alternative; boundary=e89a8ff1ca781fc88904e2bca326 Cc: "i2rs@ietf.org" , Nitin Bahadur , "t.petch" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:55:46 -0000 --e89a8ff1ca781fc88904e2bca326 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 30, 2013 at 7:53 AM, Russ White wrote: > > > >And the I-D places heavy emphasis on interfaces which again seems to > > >have nothing to do with the charter. > > > > It's unclear to me how you program a route without an associated > interface > > where the data gets sent out. For example in OSPF, if one learns a route > via > > OSPF, you know from which neighbor you learnt it from and you know the > > interface associated with it as well. That's how the router is able to > send the > > packets out to the destination. > > Actually, it isn't... Routing protocols install routes to a next hop, which > is then recursed to find the best interface (or set of interfaces) by which > the local forwarding plane can reach that next hop. I would avoid telling > the RIB which specific interface to use, as this could have very negative > effects on load sharing and fast failover solutions --unless the specific > intent is to provide for load sharing on a per interface level in I2RS. I > Even today routes can be added with nexthop as an interface. Consider a static route with nexthop as a point-to-point unnumbered interface. > would argue that's more of a job for OpenFlow than I2RS, though. > Great. Now we have another use-case for I2RS ;-) - Sri --e89a8ff1ca781fc88904e2bca326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 30, 2013 at 7:53 AM, Russ White <<= a href=3D"mailto:russw@riw.us" target=3D"_blank">russw@riw.us> wrote:

> >And the I-D places heavy emphasis on interfaces which again seems = to
> >have nothing to do with the charter.
>
> It's unclear to me how you program a route without an associated i= nterface
> where the data gets sent out. For example in OSPF, if one learns a rou= te
via
> OSPF, you know from which neighbor you learnt it from and you know the=
> interface associated with it as well. That's how the router is abl= e to
send the
> packets out to the destination.

Actually, it isn't... Routing protocols install routes to a next = hop, which
is then recursed to find the best interface (or set of interfaces) by which=
the local forwarding plane can reach that next hop. I would avoid telling the RIB which specific interface to use, as this could have very negative effects on load sharing and fast failover solutions --unless the specific intent is to provide for load sharing on a per interface level in I2RS. I

Even today routes can be added with next= hop as an interface. Consider a static route with nexthop as a point-to-poi= nt unnumbered interface.
=C2=A0
would argue that's more of a job for OpenFlow than I2RS, though.

Great. Now we have another use-case for I2RS = ;-)
=C2=A0

- Sri
--e89a8ff1ca781fc88904e2bca326-- From edc@google.com Wed Jul 31 00:46:59 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E9921E8129 for ; Wed, 31 Jul 2013 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IIL4MGPFJ3T for ; Wed, 31 Jul 2013 00:46:59 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6D521E8128 for ; Wed, 31 Jul 2013 00:46:58 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so299518wes.12 for ; Wed, 31 Jul 2013 00:46:57 -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=CjGjTv5hHMyryOPxQXzWYqV55++Im7U7UDJb+Sj7Gxk=; b=VRhM9kmB/Iz1UZzIjoXIAq0V6q7FJnIy+t5kp6cVt8HmtUMlN/4w0Kvl65JG3IomzS cbZfal4HFRyvSzWaBrNkHO9v56FOKopMcdsSoird/z3BAtPizndBFgXM10SB63EsErUC 0n9418DPRuN8NfrBewzwKlAhKnAEtZuiVgT2opxKav6VuX8jxCZn7/PL1M52v9jA4luq ZMBFgocZWrMbcdYZzQ5kmv7V5bkTysfLC13sOKRj+zxCJ0BLasn9n+BDYH86nCvuiZfN NzJ+uTuHwuehRGk2OIwN+iBLlUExlJHZiUJOvuh2cMJllXT6HyfsnW86k7cuDkCFqkWS gTMw== X-Google-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 :x-gm-message-state; bh=CjGjTv5hHMyryOPxQXzWYqV55++Im7U7UDJb+Sj7Gxk=; b=Qk7gOwpACjngv+p7DvM47Q/rDoz6jP3ChmSdw7Uq/65Pw+AKtIM2L++R69FJHuTDUC j3CGGV3sQ97GLniKzc4t9kHqooWe/VgIC6zzYKdaCPRVhVaMpnozc6GWIt26Qpwk5vjc wSGrjQ9k/V+NIFcRUSruo8uqLN5QVb+WlBXqi96hB7r3d9Qaa63oBnO1a++rw0nFGNzv ZnbjLgV88e+mnMfWVSB27NS0S6JPlcBQ/6BH+cYqRQCXrNMsX94H3VDF5lvWSeE3+Pfi /zwG3S1pBqjzw4Nbo+E+xCKrXj7WeDDx4SvoCGMe6bwdXQ4vfF9k7zDbjrc9BoNxBP9p 9XQg== X-Received: by 10.180.187.136 with SMTP id fs8mr3351592wic.18.1375256817538; Wed, 31 Jul 2013 00:46:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.81.198 with HTTP; Wed, 31 Jul 2013 00:46:17 -0700 (PDT) From: Edward Crabbe Date: Wed, 31 Jul 2013 09:46:17 +0200 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnswpO1X/ISKsLQ2n/P4RnlkGzHDwYi3Puc7iiYCE8thkBa0TcYx854xEiAkkbjxQN690+lvYTua35JdoFu+y7Cr7OQift9II9dPG83PehEnNdyboDzMGb6/hJqqr6CGHCp7Nlp3cXhBN7VvlqBjq31IL4YdGgho/C5npJ9fgonSboYopa2sHbhMdKvp/z5hF6j56im Subject: [i2rs] presentations for the wg meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:47:00 -0000 For those of you who are presenting: If you haven't gotten me your presentation for tomorrow, please do so by this evening. cheers, -ed From jclarke@cisco.com Wed Jul 31 03:57:52 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851EE21F997B for ; Wed, 31 Jul 2013 03:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm0Rqr20jQJP for ; Wed, 31 Jul 2013 03:57:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE0521F9CE3 for ; Wed, 31 Jul 2013 03:57:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6VAvYhN003674; Wed, 31 Jul 2013 12:57:34 +0200 (CEST) Received: from dhcp-10-61-98-57.cisco.com (dhcp-10-61-98-57.cisco.com [10.61.98.57]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6VAvC61022989; Wed, 31 Jul 2013 12:57:22 +0200 (CEST) Message-ID: <51F8ED88.5050208@cisco.com> Date: Wed, 31 Jul 2013 06:57:12 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:57:52 -0000 On 7/24/13 5:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > This WG call for adoption will complete on August 12. I support adoption, but I do have some comments below (see JMC) Section 1: The I2RS, and therefore this document, are specifically focused on an interface for routing and forwarding data. JMC: Does an interface to the forwarding set the bar too broadly? Should this instead be an interface to the layer 3 forwarding data? Do we want to exclude this altogether in light of ForCES? Section 1.2: As can also be seen in Figure 1, an I2RS Agent may communicate with multiple clients. Each client may send the agent a variety of write operations. The handling of this situation has been a source of discussion in the working group. In order to keep the protocol simple, the current view is that two clients should not be attempting to write (modify) the same piece of information. Such collisions may happen, but are considered error cases that should be resolved by the network applications and management systems. JMC: I think more verbiage is needed around how to detect collisions. This is key to security considerations. Saying "clients should not" is not strong enough to keep our potential attackers. If each operation is tagged with an identifier that is unique to a client, then it will be possible to determine if the current client is trying to overwrite data from a previous client. This could fold into authz as well where there is a permission to allow global override of other application's state. Section 2: read scope: ... write scope: ... JMC: Should there be an event or notification scope in addition to read and write? Section 3.4: I2RS clients may be operating on behalf of other applications. While those applications' identities are not need for authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations. JMC: The opaque ID might make it hard to accurately attribute changes. I2RS should mandate a way to ensure traceability back to a client that made the change or was granted access. Section 4.1: JMC: I found the text here a bit confusing and potentially overreaching for the I2RS scope. I attempted to rewrite it. OLD: One example of such an application is a Topology Manager. Such an application includes an I2RS client which uses the I2RS protocol to collect information about the state of the network. The Topology Manager would collect device and interface state from devices it interacts with directly. It also collects routing configuration and operation data from those devices. Most importantly, it collects information about the routing system, including the contents of the IGP (e.g. IS-IS or OSPF) and BGP data sets. This information is provided to the I2RS client using the I2RS data models and protocols. The Topology Manager may be an integral part of an application. It would build internal data structures, and use the collected data to drive applications like path computations or anomalous routing detection. Alternatively, the Topology manager could combine the I2RS collected data with other information, abstract the result, and provide a coherent picture of the network state over another interface. That interface might use the same I2RS protocols, and could use extensions of the I2RS data models. Developing such mechanisms is outside the initial scope of the I2RS work. NEW: One example of such an application is a Topology Manager. A Topology Manager includes an I2RS client that uses the I2RS data models and protocol to collect information about the state of the network by communicating directly with one or more I2RS agents. From these I2RS agents, the Topology Manager collects routing configuration and operational data. Most importantly, it collects information about the routing system, including the contents of the IGP (e.g., IS-IS or OSPF) and BGP data sets. The Topology Manager may be embedded as a component of a larger application. It would construct internal data structures and use the collected data to drive functions such as path computations or anomalous routing detection. Alternatively, the Topology Manager could combine the I2RS-collected data with other information, abstract a composite set, and provide a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could use extensions to the I2RS data models. Developing such mechanisms is outside the initial scope of the I2RS work. Section 5.2.1: An I2RS client applies changes via the I2RS interface based on policy and other application inputs... JMC: I2RS interface is redundant, perhaps I2RS protocol Section 5.2.2: An I2RS Agent may decide that some state should no longer be applied. An I2RS Client may instruct an Agent to remove state it has applied. 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. I2RS Agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. JMC: Previously I had commented that one event that should be supported and perhaps documented here is that if the agent decides to revert the application can be notified that its state has been reverted. This might also be useful if another client overrides some portion of another client's state (this is covered in Section 6.8, but might be useful to mention here as well). Perhaps add at the end of Section 5.2.2: "A client may choose to be notified whenever its state is reverted either by another client or by the I2RS agent." Section 5.4.2: (Bulleted list of examples) JMC: Consider adding an example for an event such as a new route being learned or an OSPF neighbor removal. Section 5.4.4: Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS data models and in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. JMC: I think this either needs an editor's note for more discussion or perhaps QoS in general should be out of scope. Section 6.1: As a result, this architecture views the I2RS interface as an interface supporting a single control and data exchange protocol. JMC: Another instance of I2RS interface. Section 6.1: That protocol may use several underlying transports (TCP, SCTP, DCCP), with suitable authentication and integrity protection mechanisms. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP is ideal for I2RS since we likely do want reliable order of delivery. Section 6.4: Each I2RS Client will have an identity; it can also have secondary identities to be used for troubleshooting. JMC: Each application will have a _unique_ identity. Section 6.5: JMC: Perhaps some normative language here to indicate a client may not maintain a persistent connection, but they may choose to do so as well. OLD: A client does not need to maintain an active communication channel with an agent. NEW: A client may not maintain... Section 6.7: One of the other important aspects of the I2RS is that it is intended to simplify collecting information about the state of network elements. JMC: I think this needs to be more specific to routing information versus any information from the network element (e.g., it does not cover CPU statistics). Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From cpignata@cisco.com Wed Jul 31 04:14:40 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9955221E810B for ; Wed, 31 Jul 2013 04:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.686 X-Spam-Level: X-Spam-Status: No, score=-110.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fhGrLehEVLr for ; Wed, 31 Jul 2013 04:14:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCD11E810D for ; Wed, 31 Jul 2013 04:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7481; q=dns/txt; s=iport; t=1375269264; x=1376478864; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pu/O2Q2xVBeQuBnV3EIs2MLsVH0x1VxbSnoo959bZ5o=; b=Ewc9kGxMWvFaq1aMmA55Uxl4vwj3eT9XbOXQnDiU66yGreVJuaYo7pAE HaCEjXM40OFYz7JNnBaUd/rzqq0ZJXmds9S5bqRDFqVIOOna4FwAvxx7E vEYmwM67QOJ+4k3oDv8Xjy/O+rlKIAEpiov6rTN+t/kt87S3DBqWxcn1o M=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsFAFbw+FGtJV2d/2dsb2JhbABbgwZ5DIJJu1OBGBZ0giQBAQEDAR1cBQsCAQgSECQyFw4CBA4FCAaHfAa4do9WMQeDGHMDkBKBLZdtgVuBOYIq X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="asc'?scan'208,217";a="238711027" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 31 Jul 2013 11:14:24 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VBENUn024275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 11:14:23 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 06:14:22 -0500 From: "Carlos Pignataro (cpignata)" To: "Joe Clarke (jclarke)" Thread-Topic: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) Thread-Index: AQHOjdzgEyNMnYDMz0S4VnNEXCvSfZl+9k2A Date: Wed, 31 Jul 2013 11:14:22 +0000 Message-ID: <95067C434CE250468B77282634C96ED322D69783@xmb-aln-x02.cisco.com> References: <51F8ED88.5050208@cisco.com> In-Reply-To: <51F8ED88.5050208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.106.13] Content-Type: multipart/signed; boundary="Apple-Mail=_FBFCE3AD-F31D-4FED-9DF2-7C6CDF6C2AC4"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:14:41 -0000 --Apple-Mail=_FBFCE3AD-F31D-4FED-9DF2-7C6CDF6C2AC4 Content-Type: multipart/alternative; boundary="Apple-Mail=_C3B60726-AA40-4229-BB8A-53BE7344584A" --Apple-Mail=_C3B60726-AA40-4229-BB8A-53BE7344584A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 31, 2013, at 12:57 PM, Joe Marcus Clarke = wrote: > Section 2: >=20 > read scope: ... >=20 > write scope: ... >=20 > JMC: Should there be an event or notification scope in addition to = read > and write? +1 to this point. I think that it should also include some words about = pub/sub.=20 Section 6.6 covers some of this though, so perhaps a forward reference. Thanks, -- Carlos. --Apple-Mail=_C3B60726-AA40-4229-BB8A-53BE7344584A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii jclarke@cisco.com> = wrote:


read scope: ...
write scope: ...
JMC: Should there be an event or = notification scope in addition to read
and write?
X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0D511E817D for ; Wed, 31 Jul 2013 05:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=-1.091, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYOZAJOKoSx3 for ; Wed, 31 Jul 2013 05:38:54 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50811E8147 for ; Wed, 31 Jul 2013 05:36:31 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1V4VdZ-0005MM-Bf; Wed, 31 Jul 2013 05:36:17 -0700 From: "Russ White" To: "'Jon Mitchell'" References: <027701ce8a16$699af680$4001a8c0@gateway.2wire.net> <009501ce8d34$98aeee60$ca0ccb20$@riw.us> <20130730150644.GA15347@puck.nether.net> In-Reply-To: <20130730150644.GA15347@puck.nether.net> Date: Wed, 31 Jul 2013 08:36:15 -0400 Message-ID: <00a401ce8dea$8d0790b0$a716b210$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQCkeywzUMzk34ezMgoxDn4dcLElBAFt3OpqAQs2NXMBxvLkIZuw3lMQ Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: i2rs@ietf.org, 'Nitin Bahadur' , "'t.petch'" Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:39:00 -0000 =20 > I'm not sure I agree with this... specifying interface + IPv4/v6 NH on = some > platforms can be useful specifically to stop recursion when the = interface goes > down by for a nexthop that otherwise may recurse (often to an = aggregate or > default). Whether it's required to program static routes in i2rs I = don't know, > but if we plan to support it, a way to stop undesired recursion would = be > useful. Aha! Good point... This is a useful case, so I'm happy with leaving it = in.=20 :-) Russ From kgray@juniper.net Wed Jul 31 07:31:32 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DDA21F9B90 for ; Wed, 31 Jul 2013 07:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhcCQxDKeBvm for ; Wed, 31 Jul 2013 07:31:23 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id DA6F721F962D for ; Wed, 31 Jul 2013 07:31:18 -0700 (PDT) Received: from mail26-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 14:31:17 +0000 Received: from mail26-am1 (localhost [127.0.0.1]) by mail26-am1-R.bigfish.com (Postfix) with ESMTP id CC2AF30033C for ; Wed, 31 Jul 2013 14:31:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85ehzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail26-am1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=kgray@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail26-am1 (localhost.localdomain [127.0.0.1]) by mail26-am1 (MessageSwitch) id 1375281075262928_878; Wed, 31 Jul 2013 14:31:15 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.247]) by mail26-am1.bigfish.com (Postfix) with ESMTP id 3A0D120048 for ; Wed, 31 Jul 2013 14:31:15 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.53) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 14:31:09 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF01-SAC.jnpr.net (172.24.192.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 07:31:05 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 07:31:05 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 07:35:12 -0700 Received: from mail203-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 14:31:04 +0000 Received: from mail203-co1 (localhost [127.0.0.1]) by mail203-co1-R.bigfish.com (Postfix) with ESMTP id BAD493000FF for ; Wed, 31 Jul 2013 14:31:04 +0000 (UTC) Received: from mail203-co1 (localhost.localdomain [127.0.0.1]) by mail203-co1 (MessageSwitch) id 1375281062281864_7365; Wed, 31 Jul 2013 14:31:02 +0000 (UTC) Received: from CO1EHSMHS006.bigfish.com (unknown [10.243.78.236]) by mail203-co1.bigfish.com (Postfix) with ESMTP id 40B23540049; Wed, 31 Jul 2013 14:31:02 +0000 (UTC) Received: from BLUPRD0511HT003.namprd05.prod.outlook.com (157.56.232.213) by CO1EHSMHS006.bigfish.com (10.243.66.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 14:31:02 +0000 Received: from BLUPRD0511MB402.namprd05.prod.outlook.com ([169.254.7.245]) by BLUPRD0511HT003.namprd05.prod.outlook.com ([10.255.135.166]) with mapi id 14.16.0329.000; Wed, 31 Jul 2013 14:31:01 +0000 From: Ken Gray To: Jakob Heitz , Russ White , 't.petch' , Nitin Bahadur , Acee Lindem , "'Joel M. Halpern'" Thread-Topic: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) Thread-Index: AQHOjfqT8V7YufBxAkmQEURdWLIGHQ== Date: Wed, 31 Jul 2013 14:31:00 +0000 Message-ID: In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E02DE2476@eusaamb109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.135.132] Content-Type: multipart/alternative; boundary="_000_CE1EE9AC166A5Dkgrayjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%RIW.US$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%BTCONNECT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%JOELHALPERN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" , 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:31:32 -0000 --_000_CE1EE9AC166A5Dkgrayjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The idea here/now is the model for programmability via I2RS, namely the RIB= object(s) =85the intent isn't to modify envmon or inventory from a program= mability perspective (or anything else). >From a "topology" extraction PoV, which we are not covering quite yet, inte= rfaces/inventory are an adjunct bit of information that we'll probably have= to deal with in that model (as "inactive topology")=85 Again as a topology= model and not as a monitoring mechanism per-se. >From a monitoring perspective - as someone else said, let's leave the moni= toring of these envmon/inventory objects to existing mechanisms. If we st= art venturing into a generic programmatic interface for monitoring as a rep= lacement for the existing mechanisms (because now we've got REST potentiall= y abetted by Yang/NETCONF/?) we will bit off way more than we can chew =85 = even if maybe one day we may get to that point. From: Jakob Heitz > Date: Mon, 29 Jul 2013 23:09:29 +0000 To: Russ White >, "'t.petch'" >, 'Nitin Bahadur' >, Acee Lindem >, "'Joel M. Halpern'" > Cc: "i2rs@ietf.org" >, 'Alia Atlas' > Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-= i2rs-rib-info-model-01 (ends Aug 12) I don't know about the global RIB, but one thing that should be modeled is the box within which all the RIBs exist. All the RIBs share various resources/objects within the box. Examples are: 1. power supply: if it dies, all the RIBs die. 2. Physical ports. Any RIB can bind to any of them or any VLANs on them. 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) ove= r a single BGP session. 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all o= f them. The RIBs in a box, but not RIBs in a different box have access to all the r= esources in the box. -- Jakob Heitz. ________________________________ From: i2rs-bounces@ietf.org [i2rs-bounces@iet= f.org] on behalf of Russ White [russw@riw.us<= mailto:russw@riw.us>] Sent: Monday, 29 July 2013 1:26 PM To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern' Cc: i2rs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-= i2rs-rib-info-model-01 (ends Aug 12) > After decades of working with router models in the IETF, my ideas are > probably rather fossilised, but I think I see some agreement that at one end > of the router, there are data structures that are passed to the silicon t= o use in > deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining > protocol specific data structures as a BGP RIB or OSPF link state database, and > processing it in order to derive one or more best routes within the purview > of that protocol instance:-) The problem is there is no longer "one" database that's passed to the silicon to make an actual forwarding decision --with virtualization, specifically, there's (potentially) a different set per interface, and henc= e there's a different "RIB" per topology behind these different forwarding table entries (though I hate to use the term "RIB" here). So when you look up a specific destination, you must not only specify the destination, but also the context within which that destination lives. The question becomes --do you want to have something like this: (Context1,10.1.1.0/24) (Context2,10.1.1.0/24) And call that the "RIB," which lives at the top level of the hierarchy? If so, then what do you call the table that lives exclusively in context 1 (or 2), and has a route to 10.1.1.0/24, but is not even aware of other routes t= o that same destination address because it has no access to the tables in other contexts? This second table is what's traditionally called "the RIB," in my experience. While different people have different experiences, I don'= t know of anyone who would call the combination of all forwarding table entry contexts into one large table the "RIB." A second way to look at this, I think, is in asking what question you want to be able to ask. Do you want to say: "Find me the route in context 1 that leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select context 1. Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find every route to every possible 10.1.1.0/24 no matter what the context is?" The third question makes no sense to me, as I don't see anything useful you can do with that information. I'm open to suggestions, I just can't think o= f anything off the top of my head I'd ever want to use that information for, because (Context1,10.1.1.0/24) is actually a completely different destination than (Context2,10.1.1.0/24) --they're only related by their destination address, not by the physical or logical topology in any way. :-) Russ _______________________________________________ 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_CE1EE9AC166A5Dkgrayjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6C122E48CAE8E54C90D4F8574D075B63@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
The idea here/now is the model for programmability via I2RS, namely th= e RIB object(s) =85the intent isn't to modify envmon or inventory from a pr= ogrammability perspective (or anything else).   

From a "topology" extraction PoV, which we are not covering = quite yet, interfaces/inventory are an adjunct bit of information that we'l= l probably have to deal with in that model (as "inactive topology"= ;)=85 Again as a topology model and not as a monitoring mechanism per-se.

From a monitoring perspective -  as someone else said, let's leav= e the monitoring of these envmon/inventory objects to existing mechanisms.&= nbsp;  If we start venturing into a generic programmatic interface for= monitoring as a replacement for the existing mechanisms (because now we've got REST potentially abetted by Yang/NETCONF/?) we will= bit off way more than we can chew =85 even if maybe one day we may get to = that point.

From: Jakob Heitz <jakob.heitz@ericsson.com>
Date: Mon, 29 Jul 2013 23:09:29 = 3;0000
To: Russ White <russw@riw.us>, "'t.petch'" <ietfc@btconnect.com>, 'Nitin Bahadur' &l= t;nitinb@juniper.net>, Acee Lindem <acee.lindem@er= icsson.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>
Cc: "i2rs@ietf.org" <i2rs@i= etf.org>, 'Alia Atlas' <akat= las@gmail.com>
Subject: Re: [i2rs] rough consensus= ? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12= )

I don't know about the global RIB, but one thing that

should be modeled is the box within which all the RIBs exist.

All the RIBs share various resources/objects within the box.

Examples are:

1. power supply: if it dies, all the RIBs die.

2. Physical ports. Any RIB can bind to any of them or any VLANs on them.=

3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) = over a single BGP session.

4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to al= l of them.

 

The RIBs in a box, but not RIBs in a different box have access to all th= e resources in the box.

 

--

Jakob Heitz.

From: i2rs-bounces@ietf.org [i2rs-bounces@ietf.org] on behalf of R= uss White [russw@riw.us]
Sent: Monday, 29 July 2013 1:26 PM
To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern'
Cc: i2rs@ietf.org; 'Alia Atlas'=
Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-= nitinb-i2rs-rib-info-model-01 (ends Aug 12)


> After decades of working with router models in the IETF, my ideas are<= br> > probably rather fossilised, but I think I see some agreement that at o= ne
end
> of the router, there are data structures that are passed to the silico= n to
use in
> deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining=
> protocol specific data structures as a BGP RIB or OSPF link state
database, and
> processing it in order to derive one or more best routes within the purview
> of that protocol instance:-)

The problem is there is no longer "one" database that's passed to= the
silicon to make an actual forwarding decision --with virtualization,
specifically, there's (potentially) a different set per interface, and henc= e
there's a different "RIB" per topology behind these different for= warding
table entries (though I hate to use the term "RIB" here). So when= you look
up a specific destination, you must not only specify the destination, but also the context within which that destination lives.

The question becomes --do you want to have something like this:

(Context1,10.1.1.0/24)
(Context2,10.1.1.0/24)

And call that the "RIB," which lives at the top level of the hier= archy? If
so, then what do you call the table that lives exclusively in context 1 (or=
2), and has a route to 10.1.1.0/24, but is not even aware of other routes t= o
that same destination address because it has no access to the tables in
other contexts? This second table is what's traditionally called "the = RIB,"
in my experience. While different people have different experiences, I don'= t
know of anyone who would call the combination of all forwarding table entry=
contexts into one large table the "RIB."

A second way to look at this, I think, is in asking what question you want<= br> to be able to ask. Do you want to say: "Find me the route in context 1= that
leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select con= text 1.
Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find e= very route
to every possible 10.1.1.0/24 no matter what the context is?"

The third question makes no sense to me, as I don't see anything useful you=
can do with that information. I'm open to suggestions, I just can't think o= f
anything off the top of my head I'd ever want to use that information for,<= br> because  (Context1,10.1.1.0/24) is actually a completely different
destination than (Context2,10.1.1.0/24) --they're only related by their
destination address, not by the physical or logical topology in any way.
:-)

Russ

_______________________________________________
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 --_000_CE1EE9AC166A5Dkgrayjunipernet_-- From edc@google.com Wed Jul 31 14:50:47 2013 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A5711E80E6 for ; Wed, 31 Jul 2013 14:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pbs6yIc8hCT for ; Wed, 31 Jul 2013 14:50:46 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A6C8811E811D for ; Wed, 31 Jul 2013 14:50:44 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so4517981wib.2 for ; Wed, 31 Jul 2013 14:50:43 -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=Y2jUppb4wdqfinS8dmYZioNFAGWSkHlKkzeerRCKQz0=; b=gcwJ4CGxBPRd6s5TALAeejMBl0wWOc/zM8kXyfjkwWk/s/OYFBNEJtXB1cdi48gnkx leKejgLdqyhsB85yr9/w5CFfCQU4Z8yvXHxgxSfDmFSuBtjwSPT9KP9OIx7071QYaQYK POLhpXLJ+pALZXCkLENSxinVlu3cQ1QU0Gkl0f/ZnKIcX9wt+k4Cq+Evc057LP1OPUDW 98csY9711eX4r4N68BRyherW8xd0YsSeVYx9453zn5S0rBrpXGroWvgFVInWunTPfmmb GFjOU4z5eCc+NKbrNsNoy0armtQ6OcAi5pgjUn46M6V3saHD427l3K/T96AvbOTe9HlI +Jfg== X-Google-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:x-gm-message-state; bh=Y2jUppb4wdqfinS8dmYZioNFAGWSkHlKkzeerRCKQz0=; b=WB5JUENEtAiyXN5E6lafgeccutakPSeQYPjAY6Wo1lZMRQEJIdZe7wF9iDUIhBkH77 JeQTRIwEH5coy7Wp687+dfANz7loPQcdcaerOQcX2QssA9qQOrjGKsMBBWgSoIrVqiUt G+3ZZQYN3DT5dbTibWLA0bNiHaa1UuHkadeA3bHnxHxU6ztD9zvA4F+zZ0Tb+UuFcUng ScBAdSDA9EpuOYWLgDFxUmIyEd8o7O5foE33YiCeUjnwC+8Af53i6CAROco9DowwBtH7 YQXu7mpepIsU1IZJm4eK0LYra/2ffLKac3kyiV+/J5t7ZYXUK2iKdNBF3iWklz/SKT5o AB0w== X-Received: by 10.180.188.49 with SMTP id fx17mr4056095wic.49.1375307443121; Wed, 31 Jul 2013 14:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.81.198 with HTTP; Wed, 31 Jul 2013 14:50:03 -0700 (PDT) In-Reply-To: References: From: Edward Crabbe Date: Wed, 31 Jul 2013 23:50:03 +0200 Message-ID: To: "i2rs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnOwXFOL62jjUhLtMfPJjX3v6jif/vSh12mSF3f/ncjVQJD9PNWL5ds9tRnz139Pcy9GW3L64PyNl62gH4umIiKKh7Q46h+mukX7Rpa5cdFY/5SYPsbkTph8xUHqkqJjkW0urIFmqapf5HX4tjFjHVJ4yBdRc4+KH6fS1yhAH6KDmgFd1eUV0Kktpfcf7SCjtRtJxL+ Subject: Re: [i2rs] presentations for the wg meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:50:47 -0000 I still haven't received slides from a number of folks (you know who you are. ;) Please get them to me ASAP. cheers, -ed On Wed, Jul 31, 2013 at 9:46 AM, Edward Crabbe wrote: > For those of you who are presenting: > > If you haven't gotten me your presentation for tomorrow, please do so > by this evening. > > cheers, > -ed