From akatlas@gmail.com Thu Oct 3 11:40:56 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 5DC9B21F937E for ; Thu, 3 Oct 2013 11:40:56 -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 2JeiUY2nNYYZ for ; Thu, 3 Oct 2013 11:40:49 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B095821E8088 for ; Thu, 3 Oct 2013 11:31:37 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so6478113ieb.14 for ; Thu, 03 Oct 2013 11:31:37 -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=2eFI9TJ8QuKmQsC3HRFxn+Lk+xUQhoPH7z8DIQfV/+s=; b=oFM2+mVKSKsvudfuxc6KhkWIKP7xOwjlRrfX35QMpjhbysbjlUmDK+J8Xw25kgbFV0 lBAwJT1nvA9/mvX+rTukn9a1szEVMEO8IXJgfpzON7QEHsjjSIQhOKVPO+vtz3LApZ3P UKPp3IMQA35TJif9il/Qauu7zWElG/3KB1p5I2sosmqKaGS5HNO5XTQAyYiIkA8X/74w /FnmannQHvSeuGHjbXeBlm3CIktJC2nJkdeX0b93oTTmte3a3O79I4sZgpttIc+Juq+v 7t5Xg3yUJrN0/lhvtITXf+vCue6b/HLqftixhDgbQqSRaSDOH9T6ZVd52q0fAKczKVUJ bYfg== MIME-Version: 1.0 X-Received: by 10.42.54.132 with SMTP id r4mr5987686icg.19.1380825096662; Thu, 03 Oct 2013 11:31:36 -0700 (PDT) Received: by 10.64.13.145 with HTTP; Thu, 3 Oct 2013 11:31:36 -0700 (PDT) In-Reply-To: <52476F71.5080608@cisco.com> References: <20130929000501.9951.55365.idtracker@ietfa.amsl.com> <52476F71.5080608@cisco.com> Date: Thu, 3 Oct 2013 14:31:36 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=90e6ba539e9462374a04e7da65bf Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Fwd: New Version Notification for draft-clarke-i2rs-traceability-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: Thu, 03 Oct 2013 18:40:56 -0000 --90e6ba539e9462374a04e7da65bf Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Thanks for writing this up. I think that helps give a sense of the complexity required by a basic troubleshooting information model. I have a couple minor comments (including transport session details beyond just the client's IP address, ability to request logs (possibly outside of I2RS - such as via scp)), but I think this gives a good sense of what would be needed. Has anyone else read the draft? What do you think? Regards, Alia On Sat, Sep 28, 2013 at 8:08 PM, Joe Marcus Clarke wrote: > This is an answer to the suggestion by Alia for a document describing > aspects of I2RS traceability. Some of the ideas in this document are > suggestions on how the overall I2RS protocol might be designed while at the > same time knowing that changes will need to be made as the protocol evolves. > > Joe > > -------- Original Message -------- > Subject: New Version Notification for draft-clarke-i2rs-** > traceability-00.txt > Date: Sat, 28 Sep 2013 17:05:01 -0700 > From: > To: Joe Clarke , Gonzalo Salgueiro , > Carlos Pignataro > > > A new version of I-D, draft-clarke-i2rs-**traceability-00.txt > has been successfully submitted by Joe Clarke and posted to the > IETF repository. > > Filename: draft-clarke-i2rs-traceability > Revision: 00 > Title: Interface to the Routing System (I2RS) Traceability: > Framework and Information Model > Creation date: 2013-09-28 > Group: Individual Submission > Number of pages: 12 > URL: http://www.ietf.org/internet-**drafts/draft-clarke-i2rs-** > traceability-00.txt > Status: http://datatracker.ietf.org/**doc/draft-clarke-i2rs-**traceability > Htmlized: http://tools.ietf.org/html/**draft-clarke-i2rs-**traceability-00 > > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: jclarke@cisco.com > > ------------------------------**------------------------------** > ---------------- > > > ______________________________**_________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/**listinfo/i2rs > --90e6ba539e9462374a04e7da65bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thanks for writing this up. =A0= I think that helps give a sense of the complexity required by a basic troub= leshooting information model. =A0I have a couple minor comments (including = transport session details beyond just the client's IP address, ability = to request logs (possibly outside of I2RS - such as via scp)), but I think = this gives a good sense of what would be needed.

Has anyone else read the draft? =A0What do you think? = =A0

Regards,
Alia


On Sat, Sep 28, 2013 at= 8:08 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote:
This is an answer to the suggestion by Alia = for a document describing aspects of I2RS traceability. =A0Some of the idea= s in this document are suggestions on how the overall I2RS protocol might b= e designed while at the same time knowing that changes will need to be made= as the protocol evolves.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-clarke-i2rs-traceability= -00.txt
Date: Sat, 28 Sep 2013 17:05:01 -0700
From: <int= ernet-drafts@ietf.org>
To: Joe Clarke <j= clarke@cisco.com>, Gonzalo Salgueiro <gsalguei@cisco.com>, Carlos Pignataro &= lt;cpignata@cisco.c= om>


A new version of I-D, draft-clarke-i2rs-traceability-00.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-clarke-i2rs-traceability
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Interface to the Routing System (I2RS) Traceabil= ity: Framework and Information Model
Creation date: =A0 2013-09-28
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: http://www.ietf.org/internet-draft= s/draft-clarke-i2rs-traceability-00.txt
Status: http://datatracker.ietf.org/doc/draft-clar= ke-i2rs-traceability
Htmlized: http://tools.ietf.org/html/draft-clarke-i2= rs-traceability-00


Abstract:
=A0 =A0This document describes a framework for traceability in the Interfac= e
=A0 =A0to the Routing System (I2RS) and information model for that
=A0 =A0framework. =A0It specifies the motivation, requirements, use cases, = and
=A0 =A0defines an information model for recording interactions between
=A0 =A0elements implementing the I2RS protocol. =A0This framework provides = a
=A0 =A0consistent tracing interface for components implementing the I2RS =A0 =A0architecture to record what was done, by which component, and when.<= br> =A0 =A0It aims to improve the management of I2RS implementations, and can b= e
=A0 =A0used for troubleshooting, auditing, forensics, and accounting
=A0 =A0purposes.





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

The IETF Secretariat


--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t= e m s
Email: jclarke@cisco= .com

-------------------------------------------------------------= ---------------


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

--90e6ba539e9462374a04e7da65bf-- From jclarke@cisco.com Thu Oct 3 11:58: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 6C71D21F8B9C for ; Thu, 3 Oct 2013 11:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwGXBQAhBKKT for ; Thu, 3 Oct 2013 11:57:46 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDB421E80AD for ; Thu, 3 Oct 2013 11:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4672; q=dns/txt; s=iport; t=1380826072; x=1382035672; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iFZojUjrbWH85/wOjs+HNDz49I60I42eAk6+diuuOjs=; b=QtWS2+lu4w2x3p7w1D4AIcr2jk5+PUkcRfhjKgP0J3FmAiudWy22pPjT DYiD8gteTDLbqvFwC6DKECu8GMkr9X5/AXX04wXEsVEl1pJgVIdO+tgr1 UwZA3GzfJ69cT3SK6gJ9mEh5e0yvsiHjOvrFaR1N9HerPsTqn3loWbavN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAMK6TVKtJV2Y/2dsb2JhbABWA4MHOMIOCYEiFnSCJQEBAQMBAQEBawkBAQwCAgsOAwECAQIBCRYIBwkDAgECAQkMHwMGCAYNAQUCAQEFh3cGDLxhBI4EgTkQBwYLhBIDmAGBL5BQgWaBWiCBNQ X-IronPort-AV: E=Sophos;i="4.90,1027,1371081600"; d="scan'208";a="267777329" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 03 Oct 2013 18:47:50 +0000 Received: from dhcp-10-150-54-133.cisco.com (dhcp-10-150-54-133.cisco.com [10.150.54.133]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r93Iloqt028786; Thu, 3 Oct 2013 18:47:50 GMT Message-ID: <524DBBD6.6050807@cisco.com> Date: Thu, 03 Oct 2013 14:47:50 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alia Atlas References: <20130929000501.9951.55365.idtracker@ietfa.amsl.com> <52476F71.5080608@cisco.com> 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] Fwd: New Version Notification for draft-clarke-i2rs-traceability-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: Thu, 03 Oct 2013 18:58:09 -0000 On 10/3/13 2:31 PM, Alia Atlas wrote: > Hi Joe, > > Thanks for writing this up. I think that helps give a sense of the > complexity required by a basic troubleshooting information model. I > have a couple minor comments (including transport session details beyond > just the client's IP address, ability to request logs (possibly outside > of I2RS - such as via scp)), but I think this gives a good sense of what > would be needed. > > Has anyone else read the draft? What do you think? I received some comments individually. As such we are working on incorporating them. We certainly expect this document to change as the protocol becomes more fleshed out. Joe > > Regards, > Alia > > > On Sat, Sep 28, 2013 at 8:08 PM, Joe Marcus Clarke > wrote: > > This is an answer to the suggestion by Alia for a document > describing aspects of I2RS traceability. Some of the ideas in this > document are suggestions on how the overall I2RS protocol might be > designed while at the same time knowing that changes will need to be > made as the protocol evolves. > > Joe > > -------- Original Message -------- > Subject: New Version Notification for > draft-clarke-i2rs-__traceability-00.txt > Date: Sat, 28 Sep 2013 17:05:01 -0700 > From: > > To: Joe Clarke >, > Gonzalo Salgueiro >, > Carlos Pignataro > > > > A new version of I-D, draft-clarke-i2rs-__traceability-00.txt > has been successfully submitted by Joe Clarke and posted to the > IETF repository. > > Filename: draft-clarke-i2rs-traceability > Revision: 00 > Title: Interface to the Routing System (I2RS) > Traceability: Framework and Information Model > Creation date: 2013-09-28 > Group: Individual Submission > Number of pages: 12 > URL: > http://www.ietf.org/internet-__drafts/draft-clarke-i2rs-__traceability-00.txt > > Status: > http://datatracker.ietf.org/__doc/draft-clarke-i2rs-__traceability > > Htmlized: > http://tools.ietf.org/html/__draft-clarke-i2rs-__traceability-00 > > > > Abstract: > This document describes a framework for traceability in the Interface > to the Routing System (I2RS) and information model for that > framework. It specifies the motivation, requirements, use cases, and > defines an information model for recording interactions between > elements implementing the I2RS protocol. This framework provides a > consistent tracing interface for components implementing the I2RS > architecture to record what was done, by which component, and when. > It aims to improve the management of I2RS implementations, and can be > used for troubleshooting, auditing, forensics, and accounting > purposes. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c > i s c o S y s t e m s > Email: jclarke@cisco.com > > ------------------------------__------------------------------__---------------- > > > _________________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/__listinfo/i2rs > > > -- 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 aretana@cisco.com Thu Oct 3 12:07: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 0850721F9CAC for ; Thu, 3 Oct 2013 12:07:40 -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 kfHX-EDi41Gb for ; Thu, 3 Oct 2013 12:07:21 -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 3184721E809C for ; Thu, 3 Oct 2013 11:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2573; q=dns/txt; s=iport; t=1380826609; x=1382036209; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=yXTBhmopV9NcfxA1gRRDMvdX7fsfWFTmlPZKEb5kLUQ=; b=KKKHni2kC6B+f2pTJcmN4140Z11RVmhIhLi1Sk4FlGLHshMihP8yadXz joaLNIHeNNekDL58OosjWe8OQ0GVI/Hs7pkn+HqqFI0gNeDIsuzr4arwC 2KDgn9L0wuzWtCaqcJBZQBEIwqfW1cKV9YmijnINh2yUdw0zb5+CabOLV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAKC8TVKtJV2b/2dsb2JhbABZgkNEgQrBRYEiFnSCJwEEdwISAQgEChQdKBEUEQIEAQ0FCIdsAw+yaw2Ja4xmgjoxB4MfgQQDlhiOMoU2gWaBPoIq X-IronPort-AV: E=Sophos;i="4.90,1027,1371081600"; d="scan'208,217";a="267762649" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 03 Oct 2013 18:56:40 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r93Iue4u014216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 18:56:40 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.229]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 3 Oct 2013 13:56:40 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas , "Joe Clarke (jclarke)" Thread-Topic: [i2rs] Fwd: New Version Notification for draft-clarke-i2rs-traceability-00.txt Thread-Index: AQHOwGpKUN2u2I+FWkWKFvpmOD/Rqw== Date: Thu, 3 Oct 2013 18:56:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.7] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94E39551950xmbalnx15ciscoc_" MIME-Version: 1.0 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Fwd: New Version Notification for draft-clarke-i2rs-traceability-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: Thu, 03 Oct 2013 19:07:40 -0000 --_000_BBD66FD99311804F80324E8139B3C94E39551950xmbalnx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 10/3/13 2:31 PM, "Alia Atlas" > wrote: Alia: Hi! Has anyone else read the draft? What do you think? I read it and sent some comments to Joe off line. I think that it is a great start. There is a need to clearly document the = actions and result codes, but that is not to be done in this document. As = you said, it points at some of the things that need to be ironed out. Alvaro. --_000_BBD66FD99311804F80324E8139B3C94E39551950xmbalnx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 10/3/13 2:31 PM, "Alia Atlas" <akatlas@gmail.com> wrote:

Alia:

Hi!

Has anyone else read the draft?  What do you think?  

I read it and sent some comments to Joe off line.

I think that it is a great start.  There is a need to clearly doc= ument the actions and result codes, but that is not to be done in this docu= ment.  As you said, it points at some of the things that need to be ir= oned out.

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94E39551950xmbalnx15ciscoc_-- From kwangkooglee@gmail.com Fri Oct 4 02:18: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 6857B21F8FDC for ; Fri, 4 Oct 2013 02:18:32 -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 wDuwPdeH+m9o for ; Fri, 4 Oct 2013 02:18:25 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD4221F918F for ; Fri, 4 Oct 2013 02:14:21 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id gh4so2636691qeb.2 for ; Fri, 04 Oct 2013 02:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q4NrlRJVb5mp7BAf7+wrUNCrNJC+WAphmO47kzcpUCo=; b=kTlZiT9xoOf3KF0O6kae83iOPxtyVvenm6V9tNu0QxzUETVELFnsam2jUdAmCobxDj ZLBHHWGfnHmCt8vZBQRUsoPcpxdeYl67mRCo5jE9JwYeHcMIdBreVp+ZKdu74byKZkO3 wmDskt7evudgLTWVql9No+20WExvmBv5N7TJPeGRN91wAE4fRxBSeGV3QhHOGuwVhSr5 cH2frh2C2wTZ62vsfcwutTBfEja4L52266uzE58EozXUqHUWIvcSSleZ3V3GSV7TtiaT j/4Gqg/67/uKDHIoyTtelnrNM7obnheS/ZhUtOscVjdkDEQz/8YjcxiCSsyrCz2KtPtz MD0Q== MIME-Version: 1.0 X-Received: by 10.224.20.72 with SMTP id e8mr16251551qab.49.1380878060778; Fri, 04 Oct 2013 02:14:20 -0700 (PDT) Received: by 10.49.37.69 with HTTP; Fri, 4 Oct 2013 02:14:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Oct 2013 18:14:20 +0900 Message-ID: From: KwangKoog Lee To: Alia Atlas Content-Type: multipart/alternative; boundary=001a11c1bfea4a788d04e7e6ba49 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] Architecture Discussion 5: Client Redundancy 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, 04 Oct 2013 09:18:32 -0000 --001a11c1bfea4a788d04e7e6ba49 Content-Type: text/plain; charset=ISO-8859-1 Hi Alia. This is Kwang-koog from KT. I checked many opinions from i2rs experts about the client redundancy. Thanks for very meaningful discussion to more advance i2rs. >From service provider perspective, active/standby operation of network elements through dualization is mandatory for reliable operation from any failure. So, I am welcoming for the addition of the client redundancy part. Thank you. Regarding to this, I ask you something for clarifying the understanding of the i2rs architecture :-) As seen in Figure 1 of the architure document, a network application has to have a client? Or multiple network applications can attach to a single client. Referring to Sec. 4, an I2RS client can interact with multiple network applications. The next question is that network applications and client can be physically separated? Additionally, in Sec. 6.5 Connectivity, you state that "There are three different assumptions that can apply to handling dead clients. The first is that the network applicaions or management systems will detect a dead network application and iether restart that network application ....". Network applications can check the status of other network applications each other? What is the management system? The first sentence is saying the handling of dead clients, but the second sentence says the dead network application. I want to cleary understand those matters. Those might be simple questions for you. If so, appologize my lack of comprehension :p Thank you in advance and I also appreciate your efforts for i2rs. Bye. best regards, Kwang-koog Lee On Thu, Sep 12, 2013 at 11:59 PM, Alia Atlas wrote: > In draft-ietf-i2rs-architecture-00 Sec 6.4.1: > > "I2RS must support client redundancy. At the simplest, this can be > > handled by having a primary and a backup network application that > both use the same client identity and can successfully authenticate > as such. Since I2RS does not require a continuous transport > connection and supports multiple transport sessions, this can provide > some basic redundancy. However, it does not address concerns for > > troubleshooting and accountability about knowing which network > application is actually active. At a minimum, basic transport > information about each connection and time can be logged with the > identity. Further discussion is necessary to determine whether > additional client identification information is necessary.[[Editor's > note: This requires more discussion in the working group.]]" > > > I would like to start this discussion. During and after the Berlin IETF, there > > was significant discussion on the list. I tried to capture the ideas that were > > expressed then. Is what is in the draft now sufficient? How should it be improved > > upon? > > > Thanks, > > Alia (WG-Chair hat off) > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c1bfea4a788d04e7e6ba49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alia. This is Kwang-koog from KT.
=A0
I=A0checked many opinions=A0from i2rs=A0experts=A0about the client = redundancy.
Thanks for very meaningful discussion=A0to more=A0adv= ance=A0i2rs.=A0
=A0
From service provider perspective,=A0active/standby oper= ation of network elements through dualization=A0is=A0mandatory=A0for reliab= le operation from=A0any failure. So,=A0I am welcoming=A0for the=A0addition = of the client redundancy part. Thank you.
=A0
Regarding to this, I=A0ask you something for clarifying = the understanding of the i2rs architecture=A0:-)
=A0
As= seen in Figure 1 of the architure document, a network application=A0has to= have a client?=A0Or multiple=A0network applications can attach=A0to a sing= le client. Referring to Sec. 4, an I2RS client can interact with multiple n= etwork applications.=A0The next question is that=A0network applications and= client can be physically separated?
=A0
Additionally, in Sec. 6.5 Connectivity, you state that= =A0"There are three different assumptions that can apply to handling d= ead clients. The first is that the network applicaions or management system= s will detect a dead network application and iether restart that network ap= plication ....".
Network applications=A0can check the status of other network applicati= ons each other? What is the management system? The first sentence is saying= the handling of dead clients, but the second sentence says the dead networ= k application. I want to cleary understand those matters.
=A0
Those might be simple questions for you. If so, appologi= ze my lack of comprehension :p
Thank you in advance and I=A0also = appreciate=A0your efforts for i2rs.
Bye.
=A0
best regards,
Kwang-koog Lee

=A0
On Thu, Sep 12, 2013 at 11:59 PM, Alia Atlas <akatla= s@gmail.com> wrote:
In draft-ietf-i2rs-architecture-00 Sec 6.4.1:

"I2RS must support client red= undancy. At the simplest, this can be
   handled by having a primary and a backup network applic=
ation that
   both use the same client identity and can successfully authenticate
   as such.  Since I2RS does not require a continuous transport
   connection and supports multiple transport sessions, this can provide
   some basic redundancy.  However, it does not address concerns for

   troubleshooting and accountability ab=
out knowing which network
   application is actually active.  At a minimum, basic transport
   information about each connection and time can be logged with the
   identity.  Further discussion is necessary to determine whether
   additional client identification information is necessary.[[Editor's
   note: This requires more discussion in the working group.]]"=


I would like to start this disc=
ussion.  During and after the Berlin IETF, there
was significant discussion on the list.  I tried to capture the ideas th=
at were
expressed then.  Is what is in the draft now sufficient?  =
How should it be improved
upon?

Thanks,
Alia (WG-Chair hat off)

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


--001a11c1bfea4a788d04e7e6ba49-- From akatlas@gmail.com Sun Oct 6 22:05: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 C2E2721E814E for ; Sun, 6 Oct 2013 22:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 MBlL24n4ndIY for ; Sun, 6 Oct 2013 22:05:46 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 733C821E8150 for ; Sun, 6 Oct 2013 22:05:12 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id c11so5236066lbj.27 for ; Sun, 06 Oct 2013 22:05:11 -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=8xwGMNWD4RlStD4953tFaHCFQWNFKYaT76ajETg6SOY=; b=TDM90pOGUpCDAZQqk7LhUacTNdNrPDjWievd7R9Ep6FFh/Av91sjkdC0+fymrf8Zz0 esiNrSTe7klWka3EuPd1wHsPJQ4mJ26pPQBT8l8esoR4tIv2JohYlO07CN66E9Cvsg2I OzoTh/5+W40KlAcZq9HxoQr3ZOS2TNTGNvXk//bJ5+rU1zem8R+cQTgMQBXC0Xfuvxg9 RDN5nLh5H9KH+6afD/Y7O6Cy+giq+pfDvoYbBh+LLrIjRTkl0SEOP/v1w/ysDjE3Hv8D TBVj54eLFCXbnRY63sDCDcBh7ddjayBLhibDpRAarPuiGKDI8IGLGw/jwZBGeocIbhTA bukg== MIME-Version: 1.0 X-Received: by 10.152.120.73 with SMTP id la9mr24638189lab.3.1381122311317; Sun, 06 Oct 2013 22:05:11 -0700 (PDT) Received: by 10.112.139.202 with HTTP; Sun, 6 Oct 2013 22:05:11 -0700 (PDT) Date: Mon, 7 Oct 2013 01:05:11 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e011766e5c1ef9904e81f98bd Subject: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Mon, 07 Oct 2013 05:05:48 -0000 --089e011766e5c1ef9904e81f98bd Content-Type: text/plain; charset=ISO-8859-1 I really really like how the discussion and explanation has shaped up in this draft. I'd love to see a bit more detail fleshing out the events/notification section and some thought given to what different mechanisms make sense for the information collection stream. For instance, what types of filtering or thresholding can be done by a client who wants to learn the RIB information. For the reading or notifications - is it possible to learn which protocol has installed a particular route? What types of filters beyond routing instance, RIB, and match can be used for reading routes? It would be useful to capture on the Installed flag whether that means a fully confirmed route installed into all the relevant FIBs or whether it means that the RIB manager has passed it down to the FIB manager for installation? I can see this being an event rather than being returned on the write - but am happy to hear other ideas. I understand completely the concerns about access for the I2RS client as far as reading or writing RIBs. I don't think that the solution is likely to be access-lists configured on each network device - but rather something tied into the authentication and authorization and associated scope of the role that is verified by (I hope) an existing protocol. One thing we do have to decide as a WG is what level of detail the scope will have. In the context of this draft, pulling out essential the information model of the permissions that would make sense would help clarify this and provide the data needed for the read/write scope resolution. Nit: The multicast match is missing from the in the BNF and from Figure 2. (Some of the later figures aren't labeled either). For those who have read this far, I'd really like to get strong focus and comments on this draft. We have tight milestones and I still cling to some hope of coming close to them. Has anyone done compare/contrasts on what features are needed in a data-modeling language for this info model? Could we have a useful conversation about how well different data-modeling languages work for this? Regards, Alia --089e011766e5c1ef9904e81f98bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I really really like how the discussion and explanation ha= s shaped up in this draft.

I'd love to see a bit more deta= il fleshing out the events/notification section and some thought given to w= hat different mechanisms make sense for the information collection stream. = =A0For instance, what types of filtering or thresholding can be done by a c= lient who wants to learn the RIB information.

For the reading or notifications - is it possible= to learn which protocol has installed a particular route? =A0What types of= filters beyond routing instance, RIB, and match can be used for reading ro= utes?

It would be useful to capture on the Installed flag whe= ther that means a fully confirmed route installed into all the relevant FIB= s or whether it means that the RIB manager has passed it down to the FIB ma= nager for installation? =A0 I can see this being an event rather than being= returned on the write - but am happy to hear other ideas.

I understand completely the concerns about access for t= he I2RS client as far as reading or writing RIBs. =A0I don't think that= the solution is likely to be access-lists configured on each network devic= e - but rather something tied into the authentication and authorization and= associated scope of the role that is verified by (I hope) an existing prot= ocol. =A0One thing we do have to decide as a WG is what level of detail the= scope will have. =A0In the context of this draft, pulling out essential th= e information model of the permissions that would make sense would help cla= rify this and provide the data needed for the read/write scope resolution.<= /div>

Nit: =A0The multicast match is missing from the <mat= ch> in the BNF and from Figure 2. =A0(Some of the later figures aren'= ;t labeled either).

For those who have read this f= ar, I'd really like to get strong focus and comments on this draft. =A0= We have tight milestones and I still cling to some hope of coming close to = them.

Has anyone done compare/contrasts on what features are = needed in a data-modeling language for this info model? =A0Could we have a = useful conversation about how well different data-modeling languages work f= or this?

Regards,
Alia
--089e011766e5c1ef9904e81f98bd-- From nitinb@juniper.net Wed Oct 9 17:10:04 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 2BCF511E810F for ; Wed, 9 Oct 2013 17:10:04 -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 LcCitDcHBDFm for ; Wed, 9 Oct 2013 17:09:57 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id BC68911E80FE for ; Wed, 9 Oct 2013 17:09:57 -0700 (PDT) Received: from mail126-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 00:09:57 +0000 Received: from mail126-tx2 (localhost [127.0.0.1]) by mail126-tx2-R.bigfish.com (Postfix) with ESMTP id 011A020067; Thu, 10 Oct 2013 00:09:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail126-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(59766001)(77982001)(79102001)(50986001)(47976001)(49866001)(46102001)(47736001)(76482001)(56776001)(54316002)(36756003)(51856001)(74366001)(74876001)(74706001)(83072001)(63696002)(4396001)(65816001)(47446002)(66066001)(80022001)(74502001)(83506001)(74662001)(31966008)(76176001)(85306002)(81686001)(81542001)(81342001)(77096001)(53806001)(69226001)(56816003)(76796001)(83322001)(76786001)(81816001)(54356001)(80976001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB049; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail126-tx2 (localhost.localdomain [127.0.0.1]) by mail126-tx2 (MessageSwitch) id 1381363794831695_9171; Thu, 10 Oct 2013 00:09:54 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.250]) by mail126-tx2.bigfish.com (Postfix) with ESMTP id C6902160046; Thu, 10 Oct 2013 00:09:54 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 00:09:54 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 00:09:53 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 00:09:52 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.67]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.76]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 00:09:52 +0000 From: Nitin Bahadur To: "Joel M. Halpern" , "i2rs@ietf.org" Thread-Topic: [i2rs] RIB Model draft Thread-Index: AQHOsHuL5uA39Jk3+U6M9WjBc0bkKJnsw8GA Date: Thu, 10 Oct 2013 00:09:52 +0000 Message-ID: In-Reply-To: <523302BF.4040701@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0995196AA2 Content-Type: text/plain; charset="Windows-1252" Content-ID: <3DC29840AF2EDE43ABE1BC482F9DC834@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [i2rs] RIB Model draft 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, 10 Oct 2013 00:10:04 -0000 Hi Joel, >Given that metrics are not comparable between routing protocols, or even >between distinct instances of routing protocols, why are the metrics in >the general RIB model instead of the protocol specific models? >From the draft: "Route metric is used for comparing routes learned by the same protocol. If a controller wishes to program 2 or more routes to the same destination, then it can use the metric field to disambiguate the 2 routes." So forget "protocol". If a controller programs 2 routes to same dest, it needs a metric value to distinguish between the 2 routes. >Similarly, why is AS Path in this model, rather than in the BGP model? >Whether the decision is implemented in BGP or a common RIB model would >seem implementation specific, but from a model perspective it seems to >be a BGP-specific property rather than a generic RIB property. I agree that AS-path is a BGP thing. However there is no other construct to represent inter-domain paths today. From the draft=8A "A route can have an as-path associated with it to indicate which set of autonomous systems has to be traversed to reach the final destination. The as-path attribute can be used by the RIB manager in multiple ways. The RIB manager can choose paths with lower as-path length. Or the RIB manager can choose to not install paths going via a particular AS. How exactly the RIB manager uses the as-path is outside the scope of this document." Note that the above text has no reference to BGP. >The load balancing attributes seem to reflect a particular >implementation strategy. While a not unreasonable strategy, the >modeling seems pretty implementation specific. This applies to both the >specifics of load balance weight and the interaction of that weight with >protection preference. I would be happy to hear alternatives for modeling this. >Having no-decrementTTL has a general nexthop attribute seems a mistake. >In fact, having a next hop with no decrement seems very dangerous, since >one could have a looping tunnel chain with no decrementing. Is this >really something we want in the model? (I can't stop someone from doing >it in an implementation.) No-decrement-ttl is the only way to simulate a Pipe model. Someone has to be very careful in using this, otherwise as you said - they'll cause routing loops. But the same argument is true with any programming from the controller. I can always program the RIB of 2 edge routers in a way that packets are ping-ponging between them (until TTL expires). >While the model should permit handling the TTL propagation into and out >of tunnels, it should not mandate support for specific modes. How do we >indicate that support for things like the NO_PROPAGATE_TTL flag is >optional, or conversely always set? ::=3D [] [] ::=3D [] [] Above indicates that nexthop-flags is an optional attribute. And it also indicates that the NO_PROPAGATE_TTL flag is an optional flag attribute. Support being optional is a matter of Data-model negotiation (outside scope of this document). Indicating always set - I don't have a good answer. >Minor: I presume that the cardinality of 0 is allowed in the >relationship between route and nexthop-list to reflect incomplete route >entries?=20 > If so, shouldn't the text say so? It's a typo. It should be 1. Every route needs to have a nexthop=8Athe nexthop can be unresolved. >Nit: figure 2 should include multicast. Yup. Thanks Nitin From jmh@joelhalpern.com Wed Oct 9 17:21: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 D1FE321F9E1D for ; Wed, 9 Oct 2013 17:21:16 -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 ZvEBNwEUP8Rk for ; Wed, 9 Oct 2013 17:21:10 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A558221F9D1B for ; Wed, 9 Oct 2013 17:21:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 2DFF0482B71; Wed, 9 Oct 2013 17:21:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0782A482B70; Wed, 9 Oct 2013 17:21:08 -0700 (PDT) Message-ID: <5255F2F3.9000902@joelhalpern.com> Date: Wed, 09 Oct 2013 20:21:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nitin Bahadur References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB Model draft 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, 10 Oct 2013 00:21:17 -0000 Thank you for your responses. Further in-line. (Deleted text where there is agreement.) On 10/9/13 8:09 PM, Nitin Bahadur wrote: > Hi Joel, > >> Given that metrics are not comparable between routing protocols, or even >> between distinct instances of routing protocols, why are the metrics in >> the general RIB model instead of the protocol specific models? > >>From the draft: > "Route metric is used for comparing routes learned by the same protocol. > If a controller wishes to program 2 or more routes to the same > destination, then it can use > the metric field to disambiguate the 2 routes." > > So forget "protocol". If a controller programs 2 routes to same dest, it > needs a metric > value to distinguish between the 2 routes. Why would a single I2RS Client program two routes for the same prefix with different next-hops? Is there a use case that drives us to want to allow this? > > >> Similarly, why is AS Path in this model, rather than in the BGP model? >> Whether the decision is implemented in BGP or a common RIB model would >> seem implementation specific, but from a model perspective it seems to >> be a BGP-specific property rather than a generic RIB property. > > I agree that AS-path is a BGP thing. However there is no other construct to > represent inter-domain paths today. From the draftŠ > > "A route can have an as-path associated with it to indicate which set of > autonomous systems has to be traversed to reach the final destination. The > as-path attribute can be used by the RIB manager in multiple ways. The RIB > manager can choose paths with lower as-path length. Or the RIB manager can > choose to not install paths going via a particular AS. How exactly the RIB > manager uses the as-path is outside the scope of this document." > > Note that the above text has no reference to BGP. AS Paths are a BGP construct. If you are not running BGP then the question above (about two paths from the I2RS agent) would seem to apply. If you do have a BGP running, then the BGP is usually where that sort of policy lives. My concern is that this mechanism assumes a RIB agent that handles BGP specific operations. I would prefer to leave BGP mediation to the BGP model. > > >> The load balancing attributes seem to reflect a particular >> implementation strategy. While a not unreasonable strategy, the >> modeling seems pretty implementation specific. This applies to both the >> specifics of load balance weight and the interaction of that weight with >> protection preference. > > I would be happy to hear alternatives for modeling this. Maybe we should defer modeling the details of load balancing? > > >> Having no-decrementTTL has a general nexthop attribute seems a mistake. >> In fact, having a next hop with no decrement seems very dangerous, since >> one could have a looping tunnel chain with no decrementing. Is this >> really something we want in the model? (I can't stop someone from doing >> it in an implementation.) > > No-decrement-ttl is the only way to simulate a Pipe model. Someone has to > be > very careful in using this, otherwise as you said - they'll cause routing > loops. But the same argument is true with any programming from the > controller. > I can always program the RIB of 2 edge routers in a way that packets are > ping-ponging > between them (until TTL expires). Well, my concern is exactly your parenthetical (until the TTL expires.) I do understand that people want to support pipe mode. Is there some way this could be attached to the tunnel entry behavior, rather than being a general next-hop property. It is rather specific, and making it general seems weak modeling. > > >> While the model should permit handling the TTL propagation into and out >> of tunnels, it should not mandate support for specific modes. How do we >> indicate that support for things like the NO_PROPAGATE_TTL flag is >> optional, or conversely always set? > > ::= [] [] > ::= [] [] > > > Above indicates that nexthop-flags is an optional attribute. And it also > indicates that the > NO_PROPAGATE_TTL flag is an optional flag attribute. Support being > optional is a matter of > Data-model negotiation (outside scope of this document). Indicating always > set - I don't have a > good answer. I am not concerned with how we represent that something is optional in a message. That's easy. And I understand that negotiation is outside the scope of this model. But it is the model's job to indicate which capabilities are required to be supported on the underlying device, and which are optional. This presumably would then be reflected in the negotiation or capabilities exchange mechanism. As currently written, a reader is led to conclude that a compliant device / I2RS Agent must support all of the capabilities in the model. I hope that is not the intent. ... > > Thanks > Nitin > > > From russw@riw.us Thu Oct 10 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 D1E2021E8100 for ; Thu, 10 Oct 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=[BAYES_00=-2.599, J_CHICKENPOX_14=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 fJbhOe1sFRpJ for ; Thu, 10 Oct 2013 03:40:54 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9889811E813D for ; Thu, 10 Oct 2013 03:40:52 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:64973 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VUDfi-0003A3-2b; Thu, 10 Oct 2013 10:40:47 +0000 From: "Russ White" To: "'Joel M. Halpern'" , "'Nitin Bahadur'" References: <5255F2F3.9000902@joelhalpern.com> In-Reply-To: <5255F2F3.9000902@joelhalpern.com> Date: Thu, 10 Oct 2013 06:40:46 -0400 Message-ID: <00c701cec5a5$2e99f340$8bcdd9c0$@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: AQGobaHfmYzGSB8dTGfy5TV0iNZDTgKU3KspmiXDx1A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: i2rs@ietf.org Subject: Re: [i2rs] RIB Model draft 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, 10 Oct 2013 10:40:59 -0000 > Why would a single I2RS Client program two routes for the same prefix with > different next-hops? Is there a use case that drives us to want to allow this? There are two cases --a backup route, and load balancing. The way to handle both cases is to have a marker of some type indicating what's going on. Assuming based on metrics is a bad thing. The process on the forwarding device should not be in the position of evaluating between two different routes installed by the same client process for the same destination through the route metric. Route metrics of all types --AS Path, etc.-- are local to the routing process, and should be treated as meaningless outside it (with special exceptions, such as importing/exporting routes for L3VPNs and the like). So if the idea that we will be installing multiple routes from a client into the RIB, and asking the RIB to decide between these routes based on metrics passed with the route itself --that's not a good construct. The decision should be made by the client process before it sends two such routes; that work shouldn't be pushed onto the RIB or some other process outside the client. > AS Paths are a BGP construct. If you are not running BGP then the > question above (about two paths from the I2RS agent) would seem to > apply. If you do have a BGP running, then the BGP is usually where that > sort of policy lives. My concern is that this mechanism assumes a RIB > agent that handles BGP specific operations. I would prefer to leave BGP > mediation to the BGP model. Completely agree... We don't need BGP constructs at the RIB level at all. Same reasoning as above. > Maybe we should defer modeling the details of load balancing? I'm not so certain it's difficult (?)... There seem to be two options: 1. The client sends multiple routes, each marked with some sort of tag saying, "this is a load share." 2. The client puts multiple routes into a single transaction, something like NLRIs in a BGP packet. Beyond this, the local process handles anything that has to be done to manage things... Part of the problem with dealing with a data model before a protocol is we're immediately diving into how to represent something in a globally meaningful way, rather than simply how to just get the information across the wire. > Well, my concern is exactly your parenthetical (until the TTL expires.) > I do understand that people want to support pipe mode. Is there some > way this could be attached to the tunnel entry behavior, rather than > being a general next-hop property. It is rather specific, and making it > general seems weak modeling. Again, agreed... This could be a rewrite attribute, rather than a next hop attribute --in fact, it should be. I can imagine cases where the next hop can be reached either through a tunnel, or not through a tunnel, and tunnel entry depends on some policy. If you mark all traffic to a particular destination "don't decrement the ttl," then you're risking a loop in traffic that's not entering the tunnel for policy reasons. Not a good thing. :-) Russ From nitinb@juniper.net Thu Oct 10 11:15: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 6441A11E81B3 for ; Thu, 10 Oct 2013 11:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 sTuqZ1yfi3m2 for ; Thu, 10 Oct 2013 11:15:23 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3511E8160 for ; Thu, 10 Oct 2013 11:13:09 -0700 (PDT) Received: from mail119-db9-R.bigfish.com (10.174.16.252) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 18:13:08 +0000 Received: from mail119-db9 (localhost [127.0.0.1]) by mail119-db9-R.bigfish.com (Postfix) with ESMTP id 97E094018D; Thu, 10 Oct 2013 18:13:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail119-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(51704005)(189002)(74366001)(46102001)(74706001)(79102001)(74876001)(63696002)(76482001)(66066001)(65816001)(53806001)(80022001)(56776001)(54356001)(54316002)(59766001)(77982001)(83506001)(85306002)(81342001)(69226001)(51856001)(31966008)(74662001)(74502001)(4396001)(76786001)(80976001)(76796001)(81816001)(76176001)(36756003)(47446002)(81542001)(56816003)(77096001)(83072001)(83322001)(81686001)(47736001)(50986001)(47976001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB050; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail119-db9 (localhost.localdomain [127.0.0.1]) by mail119-db9 (MessageSwitch) id 1381428786882052_17317; Thu, 10 Oct 2013 18:13:06 +0000 (UTC) Received: from DB9EHSMHS001.bigfish.com (unknown [10.174.16.243]) by mail119-db9.bigfish.com (Postfix) with ESMTP id C7DBB3A00F0; Thu, 10 Oct 2013 18:13:06 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS001.bigfish.com (10.174.14.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 18:13:05 +0000 Received: from BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 18:13:04 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 18:13:03 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.67]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.76]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 18:13:03 +0000 From: Nitin Bahadur To: "Joel M. Halpern" , Russ White Thread-Topic: [i2rs] RIB Model draft Thread-Index: AQHOsHuL5uA39Jk3+U6M9WjBc0bkKJnsw8GAgAB4gYCAALYgAA== Date: Thu, 10 Oct 2013 18:13:02 +0000 Message-ID: In-Reply-To: <5255F2F3.9000902@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0995196AA2 Content-Type: text/plain; charset="iso-8859-2" Content-ID: <0DF579359053E5459C1E425DD1270DCA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB Model draft 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, 10 Oct 2013 18:15:30 -0000 Hi Joel/Russ, >>>From the draft: >> "Route metric is used for comparing routes learned by the same protocol. >> If a controller wishes to program 2 or more routes to the same >> destination, then it can use >> the metric field to disambiguate the 2 routes." >> >> So forget "protocol". If a controller programs 2 routes to same dest, it >> needs a metric >> value to distinguish between the 2 routes. > >Why would a single I2RS Client program two routes for the same prefix >with different next-hops? Is there a use case that drives us to want to >allow this? I'll remove "route_metric" unless someone comes up with a useful use-case. >> >> >>> Similarly, why is AS Path in this model, rather than in the BGP model? >>> Whether the decision is implemented in BGP or a common RIB model would >>> seem implementation specific, but from a model perspective it seems to >>> be a BGP-specific property rather than a generic RIB property. >> >> I agree that AS-path is a BGP thing. However there is no other >>construct to >> represent inter-domain paths today. From the draft=A9 >> >> "A route can have an as-path associated with it to indicate which set of >> autonomous systems has to be traversed to reach the final destination. >>The >> as-path attribute can be used by the RIB manager in multiple ways. The >>RIB >> manager can choose paths with lower as-path length. Or the RIB manager >>can >> choose to not install paths going via a particular AS. How exactly the >>RIB >> manager uses the as-path is outside the scope of this document." >> >> Note that the above text has no reference to BGP. > >AS Paths are a BGP construct. If you are not running BGP then the >question above (about two paths from the I2RS agent) would seem to >apply. If you do have a BGP running, then the BGP is usually where that >sort of policy lives. My concern is that this mechanism assumes a RIB >agent that handles BGP specific operations. I would prefer to leave BGP >mediation to the BGP model. There were folks who had expressed interest in inter-domain paths. That's why this was added. I agree with you that the handling logic will be BGP'ish and there is an implicit assumption that the RIB agent can handle this. However, it's obvious (at least to me), that most of the use-cases for I2RS will be intra-domain and a device that does not support inter-as/bgp should be fine for most of the deployment use-cases. There are 2 ways to handle this: 1) Say inter-domain routes is out of scope of the RIB and any inter-domain extensions should be part of a separate draft. 2) Say inter-domain routes is an optional feature for i2rs agents. >>> The load balancing attributes seem to reflect a particular >>> implementation strategy. While a not unreasonable strategy, the >>> modeling seems pretty implementation specific. This applies to both >>>the >>> specifics of load balance weight and the interaction of that weight >>>with >>> protection preference. >> >> I would be happy to hear alternatives for modeling this. > >Maybe we should defer modeling the details of load balancing? If we ignore load-balancing, we'll miss on a big chunk of functionality. >>>Having no-decrementTTL has a general nexthop attribute seems a mistake. >>> In fact, having a next hop with no decrement seems very dangerous, >>>since >>> one could have a looping tunnel chain with no decrementing. Is this >>> really something we want in the model? (I can't stop someone from >>>doing >>> it in an implementation.) >> >> No-decrement-ttl is the only way to simulate a Pipe model. Someone has >>to >> be >> very careful in using this, otherwise as you said - they'll cause >>routing >> loops. But the same argument is true with any programming from the >> controller. >> I can always program the RIB of 2 edge routers in a way that packets are >> ping-ponging >> between them (until TTL expires). > >Well, my concern is exactly your parenthetical (until the TTL expires.) > I do understand that people want to support pipe mode. Is there some >way this could be attached to the tunnel entry behavior, rather than >being a general next-hop property. It is rather specific, and making it >general seems weak modeling. Let me think more about this... >>>While the model should permit handling the TTL propagation into and out >>> of tunnels, it should not mandate support for specific modes. How do >>>we >>> indicate that support for things like the NO_PROPAGATE_TTL flag is >>> optional, or conversely always set? >> >> ::=3D [] [] >> ::=3D [] [] >> >> >> Above indicates that nexthop-flags is an optional attribute. And it also >> indicates that the >> NO_PROPAGATE_TTL flag is an optional flag attribute. Support being >> optional is a matter of >> Data-model negotiation (outside scope of this document). Indicating >>always >> set - I don't have a >> good answer. > >I am not concerned with how we represent that something is optional in a >message. That's easy. And I understand that negotiation is outside the >scope of this model. But it is the model's job to indicate which >capabilities are required to be supported on the underlying device, and >which are optional. Yes, that's a good point. I haven't figured out a way to express this and I understand that expressing this is very important. Should this be expressed in the info-model or the data-model? >This presumably would then be reflected in the >negotiation or capabilities exchange mechanism. >As currently written, a >reader is led to conclude that a compliant device / I2RS Agent must >support all of the capabilities in the model. I hope that is not the >intent. Speaking as a router vendor - Not all Juniper devices will be able to support all the gory details in the rib model. So the intent is indeed NOT to enforce support of all the options. Each network device will support a subset of the features. And as you mentioned earlier, we Need to specify the REQUIRED vs OPTIONAL features. Thanks Nitin From nitinb@juniper.net Thu Oct 10 11:20: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 3D77121F9A31 for ; Thu, 10 Oct 2013 11:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 DcraE2BuSBWx for ; Thu, 10 Oct 2013 11:20:05 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5811F21F99F8 for ; Thu, 10 Oct 2013 11:19:57 -0700 (PDT) Received: from mail170-db9-R.bigfish.com (10.174.16.228) by DB9EHSOBE030.bigfish.com (10.174.14.93) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 18:19:56 +0000 Received: from mail170-db9 (localhost [127.0.0.1]) by mail170-db9-R.bigfish.com (Postfix) with ESMTP id 8783A42021A; Thu, 10 Oct 2013 18:19:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail170-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(51704005)(189002)(74366001)(46102001)(74706001)(79102001)(74876001)(63696002)(76482001)(66066001)(65816001)(53806001)(80022001)(56776001)(54356001)(54316002)(59766001)(77982001)(83506001)(85306002)(81342001)(69226001)(51856001)(31966008)(74662001)(74502001)(4396001)(76786001)(80976001)(76796001)(81816001)(76176001)(36756003)(47446002)(81542001)(56816003)(77096001)(83072001)(83322001)(81686001)(47736001)(50986001)(47976001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB050; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.54; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail170-db9 (localhost.localdomain [127.0.0.1]) by mail170-db9 (MessageSwitch) id 1381429152874345_25620; Thu, 10 Oct 2013 18:19:12 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.227]) by mail170-db9.bigfish.com (Postfix) with ESMTP id C66F6160385; Thu, 10 Oct 2013 18:19:12 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 18:19:12 +0000 Received: from BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 18:19:10 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB050.namprd05.prod.outlook.com (10.255.228.146) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 18:19:09 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.67]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.76]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 18:19:09 +0000 From: Nitin Bahadur To: Russ White , "'Joel M. Halpern'" Thread-Topic: [i2rs] RIB Model draft Thread-Index: AQHOsHuL5uA39Jk3+U6M9WjBc0bkKJnsw8GAgAB4gYCAAK0hAIAACrWA Date: Thu, 10 Oct 2013 18:19:08 +0000 Message-ID: In-Reply-To: <00c701cec5a5$2e99f340$8bcdd9c0$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.224.54] x-forefront-prvs: 0995196AA2 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "i2rs@ietf.org" Subject: Re: [i2rs] RIB Model draft 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, 10 Oct 2013 18:20:14 -0000 Hi Russ/Joel, > >Well, my concern is exactly your parenthetical (until the TTL expires.) >> I do understand that people want to support pipe mode. Is there some >> way this could be attached to the tunnel entry behavior, rather than >> being a general next-hop property. It is rather specific, and making it >> general seems weak modeling. > >Again, agreed... This could be a rewrite attribute, rather than a next hop >attribute --in fact, it should be. I can imagine cases where the next hop >can be reached either through a tunnel, or not through a tunnel, and >tunnel >entry depends on some policy. If you mark all traffic to a particular >destination "don't decrement the ttl," then you're risking a loop in >traffic >that's not entering the tunnel for policy reasons. Not a good thing. I think the key take away for me from here is that the "decrement" is a property of=20 the tunnel and not the route. So if one wants to treat the tunnel as a pipe, then they should configure it so on the tunnel and not on the route. Given that, it makes sense to get rid of the no-decrement-ttl and no-propagate-ttl from the draft. Thanks Nitin From nitinb@juniper.net Thu Oct 10 11:47:36 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 A814021F9D92 for ; Thu, 10 Oct 2013 11:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.567, 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 zdpdDiqPdG3C for ; Thu, 10 Oct 2013 11:47:07 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id BB35121F918C for ; Thu, 10 Oct 2013 11:46:46 -0700 (PDT) Received: from mail214-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE028.bigfish.com (10.174.4.91) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Oct 2013 18:46:40 +0000 Received: from mail214-db8 (localhost [127.0.0.1]) by mail214-db8-R.bigfish.com (Postfix) with ESMTP id 185BE1401E3; Thu, 10 Oct 2013 18:46:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85dhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h18c673h1de097h8275bhz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail214-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=nitinb@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(81816001)(80976001)(76786001)(76796001)(77096001)(56816003)(36756003)(76176001)(81542001)(47446002)(74502001)(31966008)(74662001)(4396001)(47736001)(47976001)(50986001)(49866001)(83322001)(83072001)(81686001)(16236675002)(74876001)(46102001)(74366001)(79102001)(74706001)(83506001)(77982001)(59766001)(51856001)(69226001)(81342001)(85306002)(76482001)(63696002)(80022001)(53806001)(66066001)(65816001)(54316002)(56776001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB052; H:BL2PR05MB049.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail214-db8 (localhost.localdomain [127.0.0.1]) by mail214-db8 (MessageSwitch) id 1381430798497510_13634; Thu, 10 Oct 2013 18:46:38 +0000 (UTC) Received: from DB8EHSMHS015.bigfish.com (unknown [10.174.8.233]) by mail214-db8.bigfish.com (Postfix) with ESMTP id 5E966240057; Thu, 10 Oct 2013 18:46:38 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS015.bigfish.com (10.174.4.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Oct 2013 18:46:38 +0000 Received: from BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 10 Oct 2013 18:46:34 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com (10.255.228.144) by BL2PR05MB052.namprd05.prod.outlook.com (10.255.228.156) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 10 Oct 2013 18:46:34 +0000 Received: from BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.67]) by BL2PR05MB049.namprd05.prod.outlook.com ([169.254.10.76]) with mapi id 15.00.0785.001; Thu, 10 Oct 2013 18:46:33 +0000 From: Nitin Bahadur To: Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00 Thread-Index: AQHOwxrtFOxDEtCoXU+I8ERz5cepz5nt1oIA Date: Thu, 10 Oct 2013 18:46:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.224.36] x-forefront-prvs: 0995196AA2 Content-Type: multipart/alternative; boundary="_000_CE7C40C9305F2nitinbjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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, 10 Oct 2013 18:47:36 -0000 --_000_CE7C40C9305F2nitinbjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alia, > I'd love to see a bit more detail fleshing out the events/notification se= ction and some thought given to what different mechanisms make sense for th= e information collection stream. For instance, what types of filtering or = thresholding can be done by a client who wants to learn the RIB information= . I think a variety of filtering is possible. I can start creating an exhaust= ive list...but need more input from WG (esp from those who intend on using = the RIB model from a RIB client) on what would be useful to them. Here are = a few possibilities. * Filter routes adds/deletes/updates based on: * Route address family * Route prefix (for IP) * Unicast vs Multicast (IP) * Filter lists of type "allow" and "exclude" Thresholding is tricky, esp if the rib agent has to implement it. If someon= e wants to slow down the number of updates sent/recd per sec, the simplest = way would be to set a small socket-buffer size on the TCP connection.... Adding logic in the rib agent to send only N updates per M seconds would co= mplicate things. > For the reading or notifications - is it possible to learn which protocol= has installed a particular route? > What types of filters beyond routing instance, RIB, and match can be used= for reading routes? Yes...there can be filter on protocol-type (yet to be defined). So you coul= d filter routes on installed only by ISIS. Learning who has installed a route in a particular RIB should be doable as = well. > Nit: The multicast match is missing from the in the BNF and from= Figure 2. (Some of the later figures aren't labeled either). Fixed. Thanks Nitin --_000_CE7C40C9305F2nitinbjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <18AD67204D21A440BC3634E61B1E6E1B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Alia,

> I'd love to see a bit more detail fleshing out the events/notific= ation section and some thought given to what different mechanisms make sens= e for the information collection stream.  For instance, what types of = filtering or thresholding can be done by a client who wants to learn the RIB information.

I think a variety of filtering is possible. I can start creating an ex= haustive list…but need more input from WG (esp from those who intend = on using the RIB model from a RIB client) on what would be useful to them. = Here are a few possibilities.

  • Filter routes adds/deletes/updates based on:
    • Route address family
    • Route prefix (for IP)
    • Unicast vs M= ulticast (IP)
  • Filter lists of type "allow" and "exclude"
Thresholding is tricky, esp if the rib agent has to implement it. If s= omeone wants to slow down the number of updates sent/recd per sec, the simp= lest way would be to set a small socket-buffer size on the TCP connection&#= 8230;.
Adding logic in the rib agent to send only N updates per M seconds wou= ld complicate things.

> For the reading or notifications - is it possible to learn which = protocol has installed a particular route?  
> What types of filters beyond routing instance, RIB, and match can= be used for reading routes?

Yes…there can be filter on protocol-type (yet to be defined). So= you could filter routes on installed only by ISIS. 
Learning who has installed a route in a particular RIB should be doabl= e as well.

> Nit:  The multicast match is missing from the <match> = in the BNF and from Figure 2.  (Some of the later figures aren't label= ed either).

Fixed.

Thanks
Nitin
--_000_CE7C40C9305F2nitinbjunipernet_-- From lucy.yong@huawei.com Thu Oct 10 13:41: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 7F79C21F9A70 for ; Thu, 10 Oct 2013 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SNcvurTOf1wy for ; Thu, 10 Oct 2013 13:41:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1CFD21F8426 for ; Thu, 10 Oct 2013 13:40:47 -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.7-GA FastPath queued) with ESMTP id AWR64055; Thu, 10 Oct 2013 20:40:40 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:40:01 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 10 Oct 2013 21:40:36 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0146.000; Thu, 10 Oct 2013 13:40:30 -0700 From: Lucy yong To: Nitin Bahadur , Alia Atlas , "i2rs@ietf.org" Thread-Topic: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00 Thread-Index: AQHOwxrrflEuvvp2SEGfjjc5fmTfQZnuwTeA//+fp4A= Date: Thu, 10 Oct 2013 20:40:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452D4D16@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.210] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452D4D16dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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, 10 Oct 2013 20:41:10 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452D4D16dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are my comments. * Why is the draft as informational not as a standard track? The te= xt body defines RIB data and grammar, and related actions. Do they need to = be standardized? * Regarding Rpf-check-interface, it only describes IP route and MPL= S route cases. How about MAC routes, etc? does it need to specifies each t= ype route case or just give an example. * Text: The outermost IP header is decided by the network device wh= ereas the MPLS header and GRE header are specified by the controller. -end= IMO: outer IP source address is decided by network devices. outer destin= ation address is decided by controller as well. * The description in Section 2.4.2. is for a specific solution. We = should keep it in a general. There are different ways to do load distributi= on. * Regarding tunnel-encap, we should mention UDP encapsulation. Nex= thop chains may be in mpls-in-udp, gre-in-udp, etc. * Edit: s/a inner/ an inner/, s/a MPLS/an MPLS/, s/a IP/an IP/ Lucy From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Nit= in Bahadur Sent: Thursday, October 10, 2013 1:47 PM To: Alia Atlas; i2rs@ietf.org Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00 Hi Alia, > I'd love to see a bit more detail fleshing out the events/notification se= ction and some thought given to what different mechanisms make sense for th= e information collection stream. For instance, what types of filtering or = thresholding can be done by a client who wants to learn the RIB information= . I think a variety of filtering is possible. I can start creating an exhaust= ive list...but need more input from WG (esp from those who intend on using = the RIB model from a RIB client) on what would be useful to them. Here are = a few possibilities. * Filter routes adds/deletes/updates based on: * Route address family * Route prefix (for IP) * Unicast vs Multicast (IP) * Filter lists of type "allow" and "exclude" Thresholding is tricky, esp if the rib agent has to implement it. If someon= e wants to slow down the number of updates sent/recd per sec, the simplest = way would be to set a small socket-buffer size on the TCP connection.... Adding logic in the rib agent to send only N updates per M seconds would co= mplicate things. > For the reading or notifications - is it possible to learn which protocol= has installed a particular route? > What types of filters beyond routing instance, RIB, and match can be used= for reading routes? Yes...there can be filter on protocol-type (yet to be defined). So you coul= d filter routes on installed only by ISIS. Learning who has installed a route in a particular RIB should be doable as = well. > Nit: The multicast match is missing from the in the BNF and from= Figure 2. (Some of the later figures aren't labeled either). Fixed. Thanks Nitin --_000_2691CE0099834E4A9C5044EEC662BB9D452D4D16dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are my comments.

 <= /p>

·      = ;   Why is the draft = as informational not as a standard track? The text body defines RIB data an= d grammar, and related actions. Do they need to be standardized?=

·      = ;   Regarding Rpf-che= ck-interface, it only describes IP route and MPLS route cases. How about MA= C routes, etc?  does it need to specifies each type route case or just give an example.

·      = ;   Text: The outermo= st IP header is decided by the network device whereas the MPLS header and G= RE header are specified by the controller.  –en= d   IMO: outer IP source address is decided by network devices. o= uter destination address is decided by controller as well.

·      = ;   The description i= n Section 2.4.2. is for a specific solution. We should keep it in a general= . There are different ways to do load distribution.

·      = ;   Regarding tunnel-= encap, we should mention UDP encapsulation.  Nexthop chains may be in = mpls-in-udp, gre-in-udp, etc.

·      = ;   Edit:  s/a i= nner/ an inner/, s/a MPLS/an MPLS/, s/a IP/an IP/

 <= /p>

Lucy

 <= /p>

From: i2rs-bou= nces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur
Sent: Thursday, October 10, 2013 1:47 PM
To: Alia Atlas; i2rs@ietf.org
Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00

 

Hi Alia,<= /p>

 

> I'd love to see a bit = more detail fleshing out the events/notification section and some thought g= iven to what different mechanisms make sense for the information collection stream.  For instance, what types of filtering or threshol= ding can be done by a client who wants to learn the RIB information.

 

I think a variety of filter= ing is possible. I can start creating an exhaustive list…but need mor= e input from WG (esp from those who intend on using the RIB model from a RIB client) on what would be useful to them. Here are a few possibi= lities.

 

  • Filter routes adds/deletes/updates based on:
    • Route address family
    • Route prefix (for IP)
    • Unicast vs Multicast (IP)
  • Filter lists of type "allow" and "exclude"=

Thresholding is tricky, esp= if the rib agent has to implement it. If someone wants to slow down the nu= mber of updates sent/recd per sec, the simplest way would be to set a small socket-buffer size on the TCP connection….

Adding logic in the rib age= nt to send only N updates per M seconds would complicate things.=

 

> For the reading or not= ifications - is it possible to learn which protocol has installed a particu= lar route?  

> What types of filters = beyond routing instance, RIB, and match can be used for reading routes?

 

Yes…there can be filt= er on protocol-type (yet to be defined). So you could filter routes on inst= alled only by ISIS. 

Learning who has installed = a route in a particular RIB should be doable as well.

 

> Nit:  The multica= st match is missing from the <match> in the BNF and from Figure 2. &n= bsp;(Some of the later figures aren't labeled either).

 

Fixed.

 

Thanks

Nitin

--_000_2691CE0099834E4A9C5044EEC662BB9D452D4D16dfweml509mbxchi_-- From ietfc@btconnect.com Fri Oct 11 02:07:15 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 11F8C21E80E0 for ; Fri, 11 Oct 2013 02:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.733 X-Spam-Level: X-Spam-Status: No, score=-4.733 tagged_above=-999 required=5 tests=[AWL=-1.866, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 ZedtnGhvXOx7 for ; Fri, 11 Oct 2013 02:07:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 61AB611E817D for ; Fri, 11 Oct 2013 02:06:53 -0700 (PDT) Received: from mail135-co9-R.bigfish.com (10.236.132.251) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Fri, 11 Oct 2013 09:06:52 +0000 Received: from mail135-co9 (localhost [127.0.0.1]) by mail135-co9-R.bigfish.com (Postfix) with ESMTP id B83CF80110; Fri, 11 Oct 2013 09:06:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hzc2hz8275ch1de098h1033IL1de097h8275bh8275dhz2dh2a8h5a9h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail135-co9 (localhost.localdomain [127.0.0.1]) by mail135-co9 (MessageSwitch) id 1381482410468885_29774; Fri, 11 Oct 2013 09:06:50 +0000 (UTC) Received: from CO9EHSMHS019.bigfish.com (unknown [10.236.132.228]) by mail135-co9.bigfish.com (Postfix) with ESMTP id 6D26E4E0085; Fri, 11 Oct 2013 09:06:50 +0000 (UTC) Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS019.bigfish.com (10.236.130.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 11 Oct 2013 09:06:50 +0000 Received: from DB3PRD0411HT003.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 11 Oct 2013 09:06:39 +0000 Message-ID: <019f01cec660$f2220940$4001a8c0@gateway.2wire.net> From: t.petch To: Nitin Bahadur , "Joel M. Halpern" , Russ White References: Date: Fri, 11 Oct 2013 09:57:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.53] 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 Subject: Re: [i2rs] RIB Model draft 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, 11 Oct 2013 09:07:15 -0000 ----- Original Message ----- From: "Nitin Bahadur" To: "Joel M. Halpern" ; "Russ White" Cc: Sent: Thursday, October 10, 2013 7:13 PM > >AS Paths are a BGP construct. If you are not running BGP then the >question above (about two paths from the I2RS agent) would seem to >apply. If you do have a BGP running, then the BGP is usually where that >sort of policy lives. My concern is that this mechanism assumes a RIB >agent that handles BGP specific operations. I would prefer to leave BGP >mediation to the BGP model. There were folks who had expressed interest in inter-domain paths. That's why this was added. I agree with you that the handling logic will be BGP'ish and there is an implicit assumption that the RIB agent can handle this. However, it's obvious (at least to me), that most of the use-cases for I2RS will be intra-domain and a device that does not support inter-as/bgp should be fine for most of the deployment use-cases. I keep on thinking that producing designs without agreed requirements, use cases, is often a costly mistake. My thinking on use cases was quite different, but unless and until we have the discussion on eg draft-white-irs-use-case-00.txt et al. who knows? Tom Petch From akatlas@gmail.com Fri Oct 11 05:47:04 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 3212F11E81BD for ; Fri, 11 Oct 2013 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, SARE_UNSUB18=0.131] 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 S1g7ikkHM2+Q for ; Fri, 11 Oct 2013 05:47:03 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B412B11E81A9 for ; Fri, 11 Oct 2013 05:47:00 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id g12so2417108oah.29 for ; Fri, 11 Oct 2013 05:47: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=JoF2oCwvddLhLKt3x5OtZqU80rlV9iQ9Ha9inJhIs2M=; b=CHsUKC52khfOBclm9lRuyL/y2yqWu9EVV93KBrRmm5Q83DO/xMGKy5uBJnP9QdhmRT eMG4DEUuVf/wqjURpXhqk43RK9F/UHlAj7GvXvibIWzomAHeaZW3TTpJh5tBWH52wacy aDSJdmbPjeVV40ehPL1jO02SlP/2GnUTW2u4/uF7Usm7VmGoqEeR2AxizblhVAb4ysoU 2lfQY9bfStvHE+7MjZHO5MDir6mPT+cKQ+ygyMsrXM+py9d/aEWdg++2veftxQyaLoia NzHCiDchsF3UwoE1+cVYi0Xu8QTAuI6Zc/t1NR69v6OVjcj38Aj+N5q4op/eP4TJv6Bz N28Q== MIME-Version: 1.0 X-Received: by 10.182.142.2 with SMTP id rs2mr393147obb.60.1381495620180; Fri, 11 Oct 2013 05:47:00 -0700 (PDT) Received: by 10.182.56.229 with HTTP; Fri, 11 Oct 2013 05:47:00 -0700 (PDT) In-Reply-To: <019f01cec660$f2220940$4001a8c0@gateway.2wire.net> References: <019f01cec660$f2220940$4001a8c0@gateway.2wire.net> Date: Fri, 11 Oct 2013 08:47:00 -0400 Message-ID: From: Alia Atlas To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c20e26b322bc04e876831c Cc: Russ White , "i2rs@ietf.org" , Nitin Bahadur , "Joel M. Halpern" Subject: Re: [i2rs] RIB Model draft 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, 11 Oct 2013 12:47:04 -0000 --001a11c20e26b322bc04e876831c Content-Type: text/plain; charset=ISO-8859-1 Tom, A discussion would be great! Why don't you start it? Alia On Fri, Oct 11, 2013 at 4:57 AM, t.petch wrote: > > ----- Original Message ----- > From: "Nitin Bahadur" > To: "Joel M. Halpern" ; "Russ White" > Cc: > Sent: Thursday, October 10, 2013 7:13 PM > > > > >AS Paths are a BGP construct. If you are not running BGP then the > >question above (about two paths from the I2RS agent) would seem to > >apply. If you do have a BGP running, then the BGP is usually where > that > >sort of policy lives. My concern is that this mechanism assumes a RIB > >agent that handles BGP specific operations. I would prefer to leave > BGP > >mediation to the BGP model. > > There were folks who had expressed interest in inter-domain paths. > That's > why this > was added. I agree with you that the handling logic will be BGP'ish and > there is an > implicit assumption that the RIB agent can handle this. > > However, it's obvious (at least to me), that most of the use-cases for > I2RS will be > intra-domain and a device that does not support inter-as/bgp should be > fine for > most of the deployment use-cases. > > > I keep on thinking that producing designs without agreed requirements, > use cases, is often a costly mistake. > > My thinking on use cases was quite different, but unless and until we > have the discussion on eg > draft-white-irs-use-case-00.txt et al. > who knows? > > Tom Petch > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c20e26b322bc04e876831c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tom,

A discussion would be great! =A0Wh= y don't you start it?

Alia


On Fri, Oct 11, 2013 = at 4:57 AM, t.petch <ietfc@btconnect.com> wrote:

----- Original Message -----
From: "Nitin Bahadur" <n= itinb@juniper.net>
To: "Joel M. Halpern" <= jmh@joelhalpern.com>; "Russ White" <russw@riw.us>
Cc: <i2rs@ietf.org>
Sent: Thursday, October 10, 2013 7:13 PM
<snip>
>
>AS Paths are a BGP construct. =A0If you are not running BGP then the >question above (about two paths from the I2RS agent) would seem to
>apply. =A0If you do have a BGP running, then the BGP is usually where that
>sort of policy lives. =A0My concern is that this mechanism assumes a RI= B
>agent that handles BGP specific operations. =A0I would prefer to leave<= br> BGP
>mediation to the BGP model.

There were folks who had expressed interest in inter-domain paths.
That's
why this
was added. I agree with you that the handling logic will be BGP'ish and=
there is an
implicit assumption that the RIB agent can handle this.

However, it's obvious (at least to me), that most of the use-cases for<= br> I2RS will be
intra-domain and a device that does not support inter-as/bgp should be
fine for
most of the deployment use-cases.

<tp>
I keep on thinking that producing designs without agreed requirements,
use cases, is often a costly mistake.

My thinking on use cases was quite different, but unless and until we
have the discussion on eg
=A0draft-white-irs-use-case-00.txt et al.
who knows?

Tom Petch




<snip>


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

--001a11c20e26b322bc04e876831c-- From russw@riw.us Fri Oct 11 09:01: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 1857921F9E76 for ; Fri, 11 Oct 2013 09:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_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 PLkFzpmTkPEb for ; Fri, 11 Oct 2013 09:01:10 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9E511E8182 for ; Fri, 11 Oct 2013 09:01:07 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:64570 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VUf99-0003n9-Fm; Fri, 11 Oct 2013 16:00:59 +0000 From: "Russ White" To: "'Nitin Bahadur'" , "'Alia Atlas'" , References: In-Reply-To: Date: Fri, 11 Oct 2013 12:01:10 -0400 Message-ID: <036c01cec69b$1af69040$50e3b0c0$@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: AQJc2wSrt3y87h51kge2OxRfku1CtJjTf+rA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 16:01:19 -0000 > I think a variety of filtering is possible. I can start creating an exhaustive > list.but need more input from WG (esp from those who intend on using the > RIB model from a RIB client) on what would be useful to them. Here are a > few possibilities. Rather than trying to come up with every possible filter, though, why don't we build an extensible infrastructure, and let use cases drive the filters actually specified? We would need a base set, but making an exhaustive list would, IMHO, be, well, err... exhausting. :-) Russ From jclarke@cisco.com Fri Oct 11 09:12: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 8A35821F9EB5 for ; Fri, 11 Oct 2013 09:12:45 -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 BNQO2D0aBXLd for ; Fri, 11 Oct 2013 09:12:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0C421F8AD5 for ; Fri, 11 Oct 2013 09:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2992; q=dns/txt; s=iport; t=1381507959; x=1382717559; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=nol3QN30TZ+GrO+CRRGfIELQ87+r02IogMamFObxHdA=; b=IElymUSpwHYvS1PhHPOmAACvpOjOPnSSEqVFojv7KdUfrSc8W6KoUV4/ QFg2kecjlxPxIdj7QK0G1MhfVUmn18K9kED7WTFiVFFxikqk+4b4af7xG veK8b1Jrit3Y7fgX9HD8ZGpD87Y2m/srd9JASxu0G5JeFZXrAm+24YXUB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALciWFKtJV2b/2dsb2JhbABWA4MHOMIigSMWdIIlAQEBAwEBAQEvAQU1ARkCCxgJJQ8CCgwwBgEMBgIBAYd8Bgy6awQEjXqBORcRhBIDmAWKTYc1g0AggTU X-IronPort-AV: E=Sophos;i="4.90,1081,1371081600"; d="scan'208";a="271064545" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2013 16:12:38 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9BGCbIC008315; Fri, 11 Oct 2013 16:12:38 GMT Message-ID: <52582375.20504@cisco.com> Date: Fri, 11 Oct 2013 12:12:37 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Nitin Bahadur , Alia Atlas , "i2rs@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 16:12:45 -0000 On 10/10/13 2:46 PM, Nitin Bahadur wrote: > Hi Alia, > > > I'd love to see a bit more detail fleshing out the > events/notification section and some thought given to what different > mechanisms make sense for the information collection stream. For > instance, what types of filtering or thresholding can be done by a > client who wants to learn the RIB information. > > I think a variety of filtering is possible. I can start creating an > exhaustive list…but need more input from WG (esp from those who intend > on using the RIB model from a RIB client) on what would be useful to > them. Here are a few possibilities. > > * Filter routes adds/deletes/updates based on: > o Route address family > o Route prefix (for IP) > o Unicast vs Multicast (IP) > * Filter lists of type "allow" and "exclude" > > Thresholding is tricky, esp if the rib agent has to implement it. If > someone wants to slow down the number of updates sent/recd per sec, the > simplest way would be to set a small socket-buffer size on the TCP > connection…. > Adding logic in the rib agent to send only N updates per M seconds would > complicate things. > >> For the reading or notifications - is it possible to learn which protocol has installed a particular route? > > What types of filters beyond routing instance, RIB, and match can be > used for reading routes? > > Yes…there can be filter on protocol-type (yet to be defined). So you > could filter routes on installed only by ISIS. > Learning who has installed a route in a particular RIB should be doable > as well. I think this is a good base set of filter criteria. I would also add VRF (or maybe VRF is assumed based on the RIB instance delivering the event). To summarize: * Address family * Prefix/prefix len * Unicast/multicast * Protocol * VRF And filter based on add/remove/update and include/exclude. Should we discuss what kind of route attributes an event would carry to the consumer? At a minimum, I think events should contain everything above (including event type) as well as: * Next hop interface * Next hop gateway * Time of route add/remove/update * Metric * Tag And to Russ' point, make things extensible for adding custom, per-vendor or per-protocol attributes as well. Joe > >> Nit: The multicast match is missing from the in the BNF and from Figure 2. (Some of the later figures aren't labeled either). > > Fixed. > > Thanks > Nitin > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- 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 edc@google.com Fri Oct 11 12:09: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 A33D021E80FA for ; Fri, 11 Oct 2013 12:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=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 gkhFVj5wya5S for ; Fri, 11 Oct 2013 12:09:38 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE37021E809B for ; Fri, 11 Oct 2013 12:09:34 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so1561148wib.12 for ; Fri, 11 Oct 2013 12:09:30 -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=d5/2ehE7ohrPsWTZYsUUl7d5Si/4XqzlWTr/P8gMIZQ=; b=DrX/ZaZD8xczxX6mPudv9VCnM3Te0LIV4ZVLOGs2ReUeQCSzEZP1HLrC3S2jCxA61B +D+B20MHXXRH/eh0hA2OL1R3oNocIKtDSZhyOJ0/i216QmEiCLk/e/CtvGdCueK88hK0 4ksSZ6FyBa2rASbuf6nq9gQAXJNFlAAxQU+xLQXhGXKFGQFG17KbxPV9s0hRq+v7fsLg Kj6CnkSja6MqrAxYSQTpEt33Wezdjxp0LJ19qhHCT8mKs0TjvjckrpwNuuNznOVSk/nW e6+xt7K26ecUKDNt2A2UJJl8RuGxgd5I0rvVWz368tjFk10LJ+30TTQjtqj79XlEd2bd Op7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=d5/2ehE7ohrPsWTZYsUUl7d5Si/4XqzlWTr/P8gMIZQ=; b=DL7iowtppZvTvwO3HxhBSDFTM00hoNlzNlLIZ29r6sEhqAzCQXuvrc/REq8srpvqCw cCThKF07FCbn7y7Y1amz+JJL9RPLX6Dc7RByFoixPSaYySxyXeOIoXNRifEimaooXnGr aRJVM5zAjB4WNe2IgJALwtL1PuNeWQLpdjCyi+1aKksGvq8D0RVTw4WgI3LZOOLoU2xj Zqfivur72oYMgMMoJdwIJSGWP6BFbbvcf8oKNTfcFfpPc9ugppg38YH3/1aH9kY45sgd bZWwEA1VenlMv0tmYzVDjcpG/YYNu39HDoB0255hSNgJYnSv8sb8Pna6SrJbzpGPcU9H kx8A== X-Gm-Message-State: ALoCoQmDYxPgWeP1xjfvLfGiJpoqXJPBYFfsQbUq46GGXtKjdlkZY+oR0Q32I+FtubIROoZBnuWaqacyFIGd+E7yC3Osf5M9CW5tJok4G15NL6ZXGymgSBsayZJzTpHwEQalDluapKwTeEvKlqYBCl85+tzIJg6UG3atJ7MK9haptYbrxHaywh7fbmOJa+FYLU8lzC9dMuvW X-Received: by 10.180.100.33 with SMTP id ev1mr1548714wib.18.1381518570504; Fri, 11 Oct 2013 12:09:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.23.3 with HTTP; Fri, 11 Oct 2013 12:08:50 -0700 (PDT) In-Reply-To: <036c01cec69b$1af69040$50e3b0c0$@riw.us> References: <036c01cec69b$1af69040$50e3b0c0$@riw.us> From: Edward Crabbe Date: Fri, 11 Oct 2013 12:08:50 -0700 Message-ID: To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Cc: "i2rs@ietf.org" , Nitin Bahadur , Alia Atlas Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 19:09:38 -0000 Couldn't agree more ^_^ On Fri, Oct 11, 2013 at 9:01 AM, Russ White wrote: > >> I think a variety of filtering is possible. I can start creating an > exhaustive >> list.but need more input from WG (esp from those who intend on using the >> RIB model from a RIB client) on what would be useful to them. Here are a >> few possibilities. > > Rather than trying to come up with every possible filter, though, why don't > we build an extensible infrastructure, and let use cases drive the filters > actually specified? We would need a base set, but making an exhaustive list > would, IMHO, be, well, err... exhausting. > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From akatlas@gmail.com Fri Oct 11 12:17: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 ADFE221E8130 for ; Fri, 11 Oct 2013 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 kWW+7Otq18cB for ; Fri, 11 Oct 2013 12:17:40 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC621E8127 for ; Fri, 11 Oct 2013 12:17:33 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so9412991iec.30 for ; Fri, 11 Oct 2013 12:17: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 :cc:content-type; bh=4fXGkqGrr3wWyN3XxZsHx6LQuIUzRqXPFTLGbLJG87Q=; b=CTvPrhWTGzzO4AEJ+WsjZ2BjID+IiW1GBqG4irEIhpQ13U46eRlHSj1c1FTHANciVq AlOEwLWD2PUczPIQuAxgs0b5ZrjM53JrdTMFiXdNBeOGw+fsJp2ZeYGSiejC3O3WGkoT K6P8IENA9YevWwmOEpdDaSDGThHL2JhTF0L5pAx+dOJ8OYt9XpGSq34Gy8er8uueADsZ 6tSvYlBHxKBQssSkT5UI1bUJ7hAMYsvhwqVMKDOjZoKUoQee9FpMlc3AHKAh9ryRL/u3 GC6PJVA7NCSngHJ7I9N2pe4zVVCcVZ0stV1r8Rc6QOSP+5dX0BPvrri2H/Mtjp/PoSHq HSFQ== MIME-Version: 1.0 X-Received: by 10.43.151.12 with SMTP id kq12mr1837937icc.55.1381519053409; Fri, 11 Oct 2013 12:17:33 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Fri, 11 Oct 2013 12:17:33 -0700 (PDT) In-Reply-To: References: <036c01cec69b$1af69040$50e3b0c0$@riw.us> Date: Fri, 11 Oct 2013 15:17:33 -0400 Message-ID: From: Alia Atlas To: Edward Crabbe Content-Type: multipart/alternative; boundary=001a11c2f8b86e29bb04e87bf859 Cc: Russ White , "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 19:17:40 -0000 --001a11c2f8b86e29bb04e87bf859 Content-Type: text/plain; charset=ISO-8859-1 I was looking for a reasonable base set to put in there. Alia On Fri, Oct 11, 2013 at 3:08 PM, Edward Crabbe wrote: > Couldn't agree more ^_^ > > On Fri, Oct 11, 2013 at 9:01 AM, Russ White wrote: > > > >> I think a variety of filtering is possible. I can start creating an > > exhaustive > >> list.but need more input from WG (esp from those who intend on using the > >> RIB model from a RIB client) on what would be useful to them. Here are a > >> few possibilities. > > > > Rather than trying to come up with every possible filter, though, why > don't > > we build an extensible infrastructure, and let use cases drive the > filters > > actually specified? We would need a base set, but making an exhaustive > list > > would, IMHO, be, well, err... exhausting. > > > > :-) > > > > Russ > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c2f8b86e29bb04e87bf859 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was looking for a reasonable base set to put in there.
Alia


On Fri, Oct 11, 2013 at 3:08 PM, Edward Crabbe <edc@goog= le.com> wrote:
Couldn't agree more ^_^

On Fri, Oct 11, 2013 at 9:01 AM, Russ White <russw@riw.us> wrote:
>
>> I think a variety of filtering is possible. I can start creating a= n
> exhaustive
>> list.but need more input from WG (esp from those who intend on usi= ng the
>> RIB model from a RIB client) on what would be useful to them. Here= are a
>> few possibilities.
>
> Rather than trying to come up with every possible filter, though, why = don't
> we build an extensible infrastructure, and let use cases drive the fil= ters
> actually specified? We would need a base set, but making an exhaustive= list
> would, IMHO, be, well, err... exhausting.
>
> :-)
>
> Russ
>
>
> __________________= _____________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--001a11c2f8b86e29bb04e87bf859-- From akatlas@gmail.com Fri Oct 11 13:06:04 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 5D0AF21E80FA for ; Fri, 11 Oct 2013 13:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=-0.694, 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 n1afJWhCtWkB for ; Fri, 11 Oct 2013 13:06:03 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 71A3D21E808E for ; Fri, 11 Oct 2013 13:06:03 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id x13so9575972ief.17 for ; Fri, 11 Oct 2013 13:06:02 -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=tuNXikwMTIJng8I0xO+P2vnPdzrDsAUI5etc9yvpXD4=; b=BPI1av3PJgpRAZfU6sCivlW9q+7WTVmhVaW/cF+xmN2rB4R4XSQiUDGtklQr8uX1eJ 8J91uMUsrSIhuabTfRAt2EWTZW58dz/It6HMk6IxjTgH42JWONjvZYHDdCYDuHHUtRuu Lv5AxAqZWZ6j+ws9N4fMwyjyfwkMGTy3VqFOmM7iVmIvoXKuB2BsyBiYZOleEIgmuHL0 VC86mtwiVWO0v1ME/DGnvIU0o1Sr34yw3ND3eEWQFVy73kSqNNx5OxSyqtqaFM8IEpZf aWJ2kY+hgZF1CahD5MEa48O2IIq+7ElL0bMqjPJr9BQvOszYNB6qs/hOAcuR7KnbNAv4 FYeA== MIME-Version: 1.0 X-Received: by 10.43.159.138 with SMTP id ly10mr1782355icc.60.1381521962829; Fri, 11 Oct 2013 13:06:02 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Fri, 11 Oct 2013 13:06:02 -0700 (PDT) In-Reply-To: <52582375.20504@cisco.com> References: <52582375.20504@cisco.com> Date: Fri, 11 Oct 2013 16:06:02 -0400 Message-ID: From: Alia Atlas To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=001a11c2d6aad8231304e87ca5c4 Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 20:06:04 -0000 --001a11c2d6aad8231304e87ca5c4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry - to be even clearer, I think that the list that Nitin and Joe suggested is a great start and sufficient until and unless we hear use-cases where that isn't so. I'd like to amplify on what "Tag" is meant - since I don't, off-hand, recall seeing it in the RIB Info model... Alia On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke wrot= e: > On 10/10/13 2:46 PM, Nitin Bahadur wrote: > >> Hi Alia, >> >> > I'd love to see a bit more detail fleshing out the >> events/notification section and some thought given to what different >> mechanisms make sense for the information collection stream. For >> instance, what types of filtering or thresholding can be done by a >> client who wants to learn the RIB information. >> >> I think a variety of filtering is possible. I can start creating an >> exhaustive list=85but need more input from WG (esp from those who intend >> on using the RIB model from a RIB client) on what would be useful to >> them. Here are a few possibilities. >> >> * Filter routes adds/deletes/updates based on: >> o Route address family >> o Route prefix (for IP) >> o Unicast vs Multicast (IP) >> * Filter lists of type "allow" and "exclude" >> >> >> Thresholding is tricky, esp if the rib agent has to implement it. If >> someone wants to slow down the number of updates sent/recd per sec, the >> simplest way would be to set a small socket-buffer size on the TCP >> connection=85. >> Adding logic in the rib agent to send only N updates per M seconds would >> complicate things. >> >> For the reading or notifications - is it possible to learn which >>> protocol has installed a particular route? >>> >> > What types of filters beyond routing instance, RIB, and match can be >> used for reading routes? >> >> Yes=85there can be filter on protocol-type (yet to be defined). So you >> could filter routes on installed only by ISIS. >> Learning who has installed a route in a particular RIB should be doable >> as well. >> > > I think this is a good base set of filter criteria. I would also add VRF > (or maybe VRF is assumed based on the RIB instance delivering the event). > To summarize: > > * Address family > * Prefix/prefix len > * Unicast/multicast > * Protocol > * VRF > > And filter based on add/remove/update and include/exclude. Should we > discuss what kind of route attributes an event would carry to the consume= r? > At a minimum, I think events should contain everything above (including > event type) as well as: > > * Next hop interface > * Next hop gateway > * Time of route add/remove/update > * Metric > * Tag > > And to Russ' point, make things extensible for adding custom, per-vendor > or per-protocol attributes as well. > > Joe > > >> Nit: The multicast match is missing from the in the BNF and >>> from Figure 2. (Some of the later figures aren't labeled either). >>> >> >> Fixed. >> >> Thanks >> Nitin >> >> >> ______________________________**_________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/**listinfo/i2rs >> >> > > -- > 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 > > ------------------------------**------------------------------** > ---------------- > --001a11c2d6aad8231304e87ca5c4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Sorry - to be even clearer, I think that the list that Nit= in and Joe suggested is a great start and sufficient until and unless we he= ar use-cases where that isn't so.

I'd like to am= plify on what "Tag" is meant - since I don't, off-hand, recal= l seeing it in the RIB Info model...

Alia


On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke = <jclarke@cisco.com> wrote:
On 10/10/13 2:46 PM, Nitin= Bahadur wrote:
Hi Alia,

=A0> I'd love to see a bit more detail fleshing out the
events/notification section and some thought given to what different
mechanisms make sense for the information collection stream. =A0For
instance, what types of filtering or thresholding can be done by a
client who wants to learn the RIB information.

I think a variety of filtering is possible. I can start creating an
exhaustive list=85but need more input from WG (esp from those who intend on using the RIB model from a RIB client) on what would be useful to
them. Here are a few possibilities.

=A0 * Filter routes adds/deletes/updates based on:
=A0 =A0 =A0 o Route address family
=A0 =A0 =A0 o Route prefix (for IP)
=A0 =A0 =A0 o Unicast vs Multicast (IP)
=A0 * Filter lists of type "allow" and "exclude"


Thresholding is tricky, esp if the rib agent has to implement it. If
someone wants to slow down the number of updates sent/recd per sec, the
simplest way would be to set a small socket-buffer size on the TCP
connection=85.
Adding logic in the rib agent to send only N updates per M seconds would complicate things.

For the reading or notifications - is it possible to learn which protocol h= as installed a particular route?
=A0> What types of filters beyond routing instance, RIB, and match can b= e
used for reading routes?

Yes=85there can be filter on protocol-type (yet to be defined). So you
could filter routes on installed only by ISIS.
Learning who has installed a route in a particular RIB should be doable
as well.

I think this is a good base set of filter criteria. =A0I would also add VRF= (or maybe VRF is assumed based on the RIB instance delivering the event). = =A0To summarize:

* Address family
* Prefix/prefix len
* Unicast/multicast
* Protocol
* VRF

And filter based on add/remove/update and include/exclude. =A0Should we dis= cuss what kind of route attributes an event would carry to the consumer? = =A0At a minimum, I think events should contain everything above (including = event type) as well as:

* Next hop interface
* Next hop gateway
* Time of route add/remove/update
* Metric
* Tag

And to Russ' point, make things extensible for adding custom, per-vendo= r or per-protocol attributes as well.

Joe


Nit: =A0The multicast match is missing from the <match> in the BNF an= d from Figure 2. =A0(Some of the later figures aren't labeled either).<= br>

Fixed.

Thanks
Nitin


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



--
Joe Marcus Clarke, CCIE #5384, =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0|
SCJP, SCSA, SCNA, SCSECA, VCP =A0 =A0 =A0 =A0||||| =A0 =A0 =A0|||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867 =A0 =A0 =A0 =A0 c i s c o =A0S y s t= e m s
Email: jclarke@cisco= .com

-------------------------------------------------------------= ---------------

--001a11c2d6aad8231304e87ca5c4-- From russw@riw.us Fri Oct 11 14:07: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 A6FB821E808C for ; Fri, 11 Oct 2013 14:07:32 -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 ffooQ0fOBbP4 for ; Fri, 11 Oct 2013 14:07:26 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id C3FBE21E8146 for ; Fri, 11 Oct 2013 14:07:26 -0700 (PDT) Received: from cpe-098-122-147-095.nc.res.rr.com ([98.122.147.95]:52559 helo=RussPC) by server.riw.us with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VUjvb-0006SD-Ly; Fri, 11 Oct 2013 21:07:19 +0000 From: "Russ White" To: "'Alia Atlas'" , "'Edward Crabbe'" References: <036c01cec69b$1af69040$50e3b0c0$@riw.us> In-Reply-To: Date: Fri, 11 Oct 2013 17:07:27 -0400 Message-ID: <00a101cec6c5$e4ebf910$aec3eb30$@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: AQJcshAk9hks7B8VUFxfzgc/xPU01wJc2wSrAn3auzQCbtG1FQIArgFRmInVzyA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Cc: i2rs@ietf.org, 'Nitin Bahadur' Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 21:07:32 -0000 > I was looking for a reasonable base set to put in there. Deny or permit anything in the TCP, UDP, or IP header, is probably a good start (?). :-) Russ From akatlas@gmail.com Fri Oct 11 14:19:04 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 548B711E80F9 for ; Fri, 11 Oct 2013 14:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 Jf911ENep242 for ; Fri, 11 Oct 2013 14:19:03 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF821F9DC9 for ; Fri, 11 Oct 2013 14:19:03 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so1872180iet.21 for ; Fri, 11 Oct 2013 14:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mnt+tNJx7uRmW8nXQ2KmTXOajx8qV1hC/ggxNL/uG0Q=; b=lEKLu4UIfcXGsTdu6CcL+uONNGeB0v+kEs2bfBLbLRMQ2s9/tygbUp1ydVoeQ1l9KC wxIivwQFG2+0UJt6/lfaSawT3HheddEnoXU442Qdzh6bnQqp86g3aHGylNDKPd+zRY2d Z4rJTWahDpO8Le27ge552dRI5PvRNQ/YZ1CtO9jA+cEgEdj8bF4lWpA6opupcv6rlK09 Ab2BPbnrvgPO99HTWW5pCiz5i8GIy8LledyQK8ykLiAfQzmFqUr5bFfqRfmcK+iYPMtM YCIdBVEu4OePIFYg0MKLkf1uLWpIl0tnIVvITYbdq7APbrs1a9pP9NW0hzA2epsnnegd ngvQ== MIME-Version: 1.0 X-Received: by 10.50.102.99 with SMTP id fn3mr4382373igb.5.1381526343087; Fri, 11 Oct 2013 14:19:03 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Fri, 11 Oct 2013 14:19:03 -0700 (PDT) In-Reply-To: <00a101cec6c5$e4ebf910$aec3eb30$@riw.us> References: <036c01cec69b$1af69040$50e3b0c0$@riw.us> <00a101cec6c5$e4ebf910$aec3eb30$@riw.us> Date: Fri, 11 Oct 2013 17:19:03 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=e89a8ffbae3fed836004e87daa52 Cc: "i2rs@ietf.org" , Nitin Bahadur , Edward Crabbe Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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: Fri, 11 Oct 2013 21:19:04 -0000 --e89a8ffbae3fed836004e87daa52 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 11, 2013 at 5:07 PM, Russ White wrote: > > > I was looking for a reasonable base set to put in there. > > Deny or permit anything in the TCP, UDP, or IP header, is probably a good > start (?). > In regards to the events and notifications coming from the RIB Manager??? Deny or permit anything in the TCP, UDP or IP header is much more policy-based routing - and I agree that we need someone to write up a reasonable and necessary set of fields to be a PBR model to extend the RIB info model :-) Alia > > :-) > > Russ > > > --e89a8ffbae3fed836004e87daa52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2013 at 5:07 PM, Russ White <russw@riw.us&= gt; wrote:
=

> I was looking for a reasonable base set to put in there.

Deny or permit anything in the TCP, UDP, or IP header, is probably a = good
start (?).

In regards to the events and= notifications coming from the RIB Manager??? =A0
Deny or permit = anything in the TCP, UDP or IP header is much more policy-based routing - a= nd I agree that we need someone to write up a reasonable and necessary set = of fields to be a PBR model to extend the RIB info model :-)

Alia=A0

:-)

Russ



--e89a8ffbae3fed836004e87daa52-- From akatlas@gmail.com Fri Oct 11 17:49: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 2FDFA11E81B1 for ; Fri, 11 Oct 2013 17:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 nwHzO4C8reRS for ; Fri, 11 Oct 2013 17:49:17 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84921E809A for ; Fri, 11 Oct 2013 17:49:12 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so2154565iet.35 for ; Fri, 11 Oct 2013 17:49:12 -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=BlaCOf1Cd/x479S+jOpv44Ng2+rzUMiYC76FW7h+Pho=; b=vLxkn4iyKCGQR8iW081OLdRVY9uaKZ5Y4UA8CdnIYCh4q5/6RP3R8qQLFjQK7qTwMZ om1VF4C5cFj2n3PWl6EIzCf343PyOnLbQltL3brgGQByZThzauoOcso9DrYzAI1YZAcV wT2b3MFprCfAqUCNtIFBbIIoKY2UAQkv16wEfsKDdFpkpIfJtQY4HddShUlrip6ztsqa Mgjrx1J/RqLHj5m5r6NmLZ4QjzCkL9HW5tipn9omyikp3F3kC38fFMUpn3tsfzcC0zy+ rEKqzSRCpFRjxgVAviSQp2UcMaXOWBTG6cAtHF/vxfROJ1VaERA4bSdGJVBUbwywU6oU B5sg== MIME-Version: 1.0 X-Received: by 10.50.128.137 with SMTP id no9mr4934439igb.36.1381538952624; Fri, 11 Oct 2013 17:49:12 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Fri, 11 Oct 2013 17:49:12 -0700 (PDT) Date: Fri, 11 Oct 2013 20:49:12 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=047d7b10cf0d83c0be04e8809a69 Subject: [i2rs] Please send agenda items and requests to Ed and I 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, 12 Oct 2013 00:49:18 -0000 --047d7b10cf0d83c0be04e8809a69 Content-Type: text/plain; charset=ISO-8859-1 I2RS will be meeting on Tuesday Nov 5 from 16:10 to 18:40. Please send both Ed and I any agenda items and requests. Drafts should, of course, be published in advanced and strongly preferably be discussed on the mailing list. Regards, Alia --047d7b10cf0d83c0be04e8809a69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I2RS will be meeting on Tuesday Nov 5 from 16:10 to 18:40.=

Please send both Ed and I any agenda items and requests= . =A0
Drafts should, of course, be published in advanced and stro= ngly
preferably be discussed on the mailing list.

= Regards,
Alia
--047d7b10cf0d83c0be04e8809a69-- From sriganeshkini@gmail.com Sat Oct 12 08:30: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 CC72B11E8149 for ; Sat, 12 Oct 2013 08:30:49 -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=[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 Q0XiFBiBdD25 for ; Sat, 12 Oct 2013 08:30:49 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 71CDC21F93BA for ; Sat, 12 Oct 2013 08:30:49 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so5537351pbb.0 for ; Sat, 12 Oct 2013 08:30: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:message-id :subject:to:cc:content-type; bh=IhRZeMbnWy2xSqCe0/bVBwJcZ4+2XC2afBjIDNQ1UsI=; b=sYQRWXlkY/g9bx51Rg73Fm+sH96ahy94GV8apM545NigGutvwBvmiDnVCmDCsk22mn CEaiWBzS0fXDBWW5+Alvb9WGs8AcAPDKUYbsgW9oDlNYcysGlZunUffqSdnMclFsUAsA SGUne2YnQqW7xYXXB6kcK99i/vw/JFzN7x3qzH7ThIXGIVplTwWnLvvXQVILzldZsAQ5 pJhUPbr6+HrDQkceTtVJ7Fg4sh88hEqP7ofW8r1OqkIj4copDPBVPzqP/+z0xhfNsddZ q1hs+r0Q1LceakWhrCQQ+5uv8KfrAt6vvn12h8F7A4RNpZXkTKgXAaDDT8pGM9+lwz1Q 66ig== X-Received: by 10.68.28.36 with SMTP id y4mr612443pbg.201.1381591849216; Sat, 12 Oct 2013 08:30:49 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.0.225 with HTTP; Sat, 12 Oct 2013 08:30:18 -0700 (PDT) In-Reply-To: References: <5255F2F3.9000902@joelhalpern.com> From: Sriganesh Kini Date: Sat, 12 Oct 2013 08:30:18 -0700 X-Google-Sender-Auth: jlUQAVp-keYhjK5DzBDrqa1Evpw Message-ID: To: Nitin Bahadur Content-Type: multipart/alternative; boundary=bcaec51ddbef65b5b504e88cebe7 Cc: Russ White , "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] RIB Model draft 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, 12 Oct 2013 15:30:49 -0000 --bcaec51ddbef65b5b504e88cebe7 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 10, 2013 at 11:13 AM, Nitin Bahadur wrote: > >Why would a single I2RS Client program two routes for the same prefix > >with different next-hops? Is there a use case that drives us to want to > >allow this? > > > I'll remove "route_metric" unless someone comes up with a useful use-case. I agree that a single I2RS client should never program two routes for the same prefix. If there are clients/applications other than the one that installed the route that would like to read the route_metric to take actions related to billing, SLA, alarms etc, would it read those routes directly from the client instead of the RIB ? - Sri --bcaec51ddbef65b5b504e88cebe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 10, 2013 at 11:13 AM, Nitin Bahadur <nitinb@juniper.net&g= t; wrote:
>Why would a single I2RS Client prog= ram two routes for the same prefix
>with different next-hops? =C2=A0Is there a use case that drives us to w= ant to
>allow this?


I'll remove "route_metric" unless someone comes up with= a useful use-case.

I agree that a single I2RS client= should never program two routes for the same prefix. If there are clients/= applications other than the one that installed the route that would like to= read the route_metric to take actions related to billing, SLA, alarms etc,= would it read those routes directly from the client instead of the RIB ?

- Sri
=
--bcaec51ddbef65b5b504e88cebe7-- From jclarke@cisco.com Sat Oct 12 10:27: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 BAB8121F9CB1 for ; Sat, 12 Oct 2013 10:27:16 -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 xt7E5HIluWJt for ; Sat, 12 Oct 2013 10:27:05 -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 DFAB811E80DC for ; Sat, 12 Oct 2013 10:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5136; q=dns/txt; s=iport; t=1381598824; x=1382808424; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3+Ud5WvOcULMBx9+/Vz66vIQUjDKbyW02pNddn/aY78=; b=gkdXn9SAAosf4M05SMky52P0CkmdO6yvcRoRLSD6rgqhWQtaZTu6yCNG oDNi/r9+Y2wWiVvX4KFgQUh+W2pNZecYqscwxbhNTqXDjoTh1PcpnfDQ7 vuC1/gj25SeUD8/Xe4J7Xygr5O3I9YmMkeOq17Jf/Kfn3kdYWCqigqmWy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFALiFWVKtJV2d/2dsb2JhbABWA4MHOMI1gRkWdIIlAQEBAwEBAQEvAQU1AQoBDgILDgoJFggHCQMCAQIBCQwfEQYNAQUCAQGHfAYMvWQEBI4FgTkQBxGEEgOYBYpNhzWDQCCBNA X-IronPort-AV: E=Sophos;i="4.93,481,1378857600"; d="scan'208";a="271388228" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 12 Oct 2013 17:27:04 +0000 Received: from rtp-jclarke-8919.cisco.com (rtp-jclarke-8919.cisco.com [10.117.46.170]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9CHR3Ix032230; Sat, 12 Oct 2013 17:27:03 GMT Message-ID: <52598666.9080904@cisco.com> Date: Sat, 12 Oct 2013 13:27:02 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alia Atlas References: <52582375.20504@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "i2rs@ietf.org" , Nitin Bahadur Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-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, 12 Oct 2013 17:27:16 -0000 On 10/11/13 4:06 PM, Alia Atlas wrote: > Sorry - to be even clearer, I think that the list that Nitin and Joe > suggested is a great start and sufficient until and unless we hear > use-cases where that isn't so. > > I'd like to amplify on what "Tag" is meant - since I don't, off-hand, > recall seeing it in the RIB Info model... Sorry, you're right. That is also an overloaded term. I was suggesting a parameter for the route that might tie this back to a particular client or instance. This was to address what Nitin said in his last sentence: "Learning who has installed a route in a particular RIB should be doable as well." If we have some kind of tag identifier, that might be one way of doing it. But it would need more definition. Joe > > Alia > > > On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke > wrote: > > On 10/10/13 2:46 PM, Nitin Bahadur wrote: > > Hi Alia, > > > I'd love to see a bit more detail fleshing out the > events/notification section and some thought given to what different > mechanisms make sense for the information collection stream. For > instance, what types of filtering or thresholding can be done by a > client who wants to learn the RIB information. > > I think a variety of filtering is possible. I can start creating an > exhaustive list…but need more input from WG (esp from those who > intend > on using the RIB model from a RIB client) on what would be useful to > them. Here are a few possibilities. > > * Filter routes adds/deletes/updates based on: > o Route address family > o Route prefix (for IP) > o Unicast vs Multicast (IP) > * Filter lists of type "allow" and "exclude" > > > Thresholding is tricky, esp if the rib agent has to implement it. If > someone wants to slow down the number of updates sent/recd per > sec, the > simplest way would be to set a small socket-buffer size on the TCP > connection…. > Adding logic in the rib agent to send only N updates per M > seconds would > complicate things. > > For the reading or notifications - is it possible to learn > which protocol has installed a particular route? > > > What types of filters beyond routing instance, RIB, and > match can be > used for reading routes? > > Yes…there can be filter on protocol-type (yet to be defined). So you > could filter routes on installed only by ISIS. > Learning who has installed a route in a particular RIB should be > doable > as well. > > > I think this is a good base set of filter criteria. I would also > add VRF (or maybe VRF is assumed based on the RIB instance > delivering the event). To summarize: > > * Address family > * Prefix/prefix len > * Unicast/multicast > * Protocol > * VRF > > And filter based on add/remove/update and include/exclude. Should > we discuss what kind of route attributes an event would carry to the > consumer? At a minimum, I think events should contain everything > above (including event type) as well as: > > * Next hop interface > * Next hop gateway > * Time of route add/remove/update > * Metric > * Tag > > And to Russ' point, make things extensible for adding custom, > per-vendor or per-protocol attributes as well. > > Joe > > > Nit: The multicast match is missing from the in the > BNF and from Figure 2. (Some of the later figures aren't > labeled either). > > > Fixed. > > Thanks > Nitin > > > _________________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/__listinfo/i2rs > > > > > -- > 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 > > ------------------------------__------------------------------__---------------- > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- 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 ramk@Brocade.com Sun Oct 13 22:07: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 9C85221E80B2 for ; Sun, 13 Oct 2013 22:07:59 -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 WgWyeQfk2feW for ; Sun, 13 Oct 2013 22:07:54 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE411E80E6 for ; Sun, 13 Oct 2013 22:07:53 -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 r9E56B8v023348 for ; Sun, 13 Oct 2013 22:07:53 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1feq4ksm25-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 13 Oct 2013 22:07:53 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 13 Oct 2013 22:07:52 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sun, 13 Oct 2013 22:07:52 -0700 From: ramki Krishnan To: "i2rs@ietf.org" Date: Sun, 13 Oct 2013 22:07:45 -0700 Thread-Topic: New Version Notification for draft-krishnan-i2rs-large-flow-use-case-00.txt Thread-Index: Ac7Imqqd1W9Qdke0R1OYqhgFoCw0hgAAHmUg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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-10-13_03:2013-10-11, 2013-10-13, 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-1310130204 Subject: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-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: Mon, 14 Oct 2013 05:07:59 -0000 RGVhciBBbGwsDQoNCllvdXIgY29tbWVudHMgb24gdGhpcyBkcmFmdCBhcmUgbW9zdCB3ZWxjb21l Lg0KDQpUaGFua3MsDQpSYW1raSAob24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzKQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFN1bmRheSwgT2N0b2JlciAx MywgMjAxMyAxMDowMyBQTQ0KVG86IERhdmUgTWNEeXNhbjsgRGF2ZSBNY2R5c2FuOyByYW1raSBL cmlzaG5hbjsgU3JpZ2FuZXNoIEtpbmk7IHJhbWtpIEtyaXNobmFuOyBBbm9vcCBHaGFud2FuaQ0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rcmlzaG5hbi1pMnJz LWxhcmdlLWZsb3ctdXNlLWNhc2UtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWtyaXNobmFuLWkycnMtbGFyZ2UtZmxvdy11c2UtY2FzZS0wMC50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFtIEtyaXNobmFuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQta3Jpc2huYW4taTJycy1sYXJnZS1m bG93LXVzZS1jYXNlDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBJMlJTIExhcmdlIEZsb3cgVXNl IENhc2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTEzDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rcmlzaG5hbi1pMnJzLWxhcmdlLWZsb3ct dXNlLWNhc2UtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQta3Jpc2huYW4taTJycy1sYXJnZS1mbG93LXVzZS1jYXNlDQpIdG1saXpl ZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtyaXNobmFuLWkycnMt bGFyZ2UtZmxvdy11c2UtY2FzZS0wMA0KDQoNCkFic3RyYWN0Og0KICAgRGVtYW5kcyBvbiBuZXR3 b3JraW5nIGJhbmR3aWR0aCBhcmUgZ3Jvd2luZyBleHBvbmVudGlhbGx5IGR1ZSB0bw0KICAgYXBw bGljYXRpb25zIHN1Y2ggYXMgbGFyZ2UgZmlsZSB0cmFuc2ZlcnMgYW5kIHRob3NlIHdpdGggcmlj aCBtZWRpYS4NCiAgIExpbmsgQWdncmVnYXRpb24gR3JvdXAgKExBRykgYW5kIEVxdWFsIENvc3Qg TXVsdGlwYXRoIChFQ01QKSBhcmUNCiAgIGV4dGVuc2l2ZWx5IGRlcGxveWVkIGluIG5ldHdvcmtz IHRvIHNjYWxlIHRoZSBiYW5kd2lkdGguIEhvd2V2ZXIsDQogICB0aGUgZmxvdyBiYXNlZCBsb2Fk IGJhbGFuY2luZyB0ZWNobmlxdWVzIHVzZWQgdG9kYXkgbWFrZSBpbmVmZmljaWVudA0KICAgdXNl IG9mIHRoZSBiYW5kd2lkdGggaW4gdGhlIHByZXNlbmNlIG9mIGxvbmcgbGl2ZWQgbGFyZ2UgZmxv d3MuIFRoaXMNCiAgIGRyYWZ0IHByZXNlbnRzIGEgdXNlLWNhc2UgdG8gaW1wcm92ZSB0aGUgZWZm aWNpZW5jeSB1bmRlciBzdWNoDQogICBjb25kaXRpb25zIGFuZCBhaW1zIHRvIGRyaXZlIHJlcXVp cmVtZW50cyBmb3IgdGhlIEkyUlMgV0cuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From IHussain@infinera.com Mon Oct 14 11:37:37 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 A801B21E80CD for ; Mon, 14 Oct 2013 11:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAczw-sUfX9A for ; Mon, 14 Oct 2013 11:37:33 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id CB64E21E80EE for ; Mon, 14 Oct 2013 11:37:31 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Mon, 14 Oct 2013 11:37:30 -0700 From: Iftekhar Hussain To: "Bitar, Nabil N" , "i2rs@ietf.org" Thread-Topic: [i2rs] soliciting WG feedback and comments on draft-bitar-i2rs-service-chaining-00 Thread-Index: AQHOuurlpzv9l7mJx0KLbSUBKnS5OJn0na0g Date: Mon, 14 Oct 2013 18:37:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53FAB3075SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [i2rs] soliciting WG feedback and comments on draft-bitar-i2rs-service-chaining-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: Mon, 14 Oct 2013 18:37:37 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FAB3075SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Few comments about this draft. a) "A new mechanism, to be defined, may also enrich the packet transit= ion in a service chain by passing service-specific information and/or info= rmation pertaining to preceding services in the chain along with the packet= being processed". Not clear what this means and if there is no intentio= n to elaborate on this why include here. b) ".... it is important to have a view of the Virtual Network (VN) to= pology (VNT)...". It is not clear why. Could you please elaborate why it is= important. c) section 3.1, service topology, this could be lot of information. d) sec 3.2, most of the discussion is about the generic QoS/utilizati= on related statistics counters. Are there any service chaining (the topic o= f this draft) specific counters requirements (e.g. FW, DPI etc) mentioned i= n section 3? e) Suggest to add a section that should list the scale requirements fo= r the use cases covered in the draft Thanks, Iftekhar From: Bitar, Nabil N [mailto:nabil.n.bitar@verizon.com] Sent: Thursday, September 26, 2013 7:16 AM To: i2rs@ietf.org Subject: [i2rs] soliciting WG feedback and comments on draft-bitar-i2rs-ser= vice-chaining-00 Hi, We had submitted the following draft http://tools.ietf.org/html/draft-bitar= -i2rs-service-chaining-00 last ietf. Your feedback and comments on the i2rs= mailing list are appreciated. We will be looking to update the draft. Thanks, Nabil --_000_D7D7AB44C06A2440B716F1F1F5E70AE53FAB3075SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Few comments about this d= raft.

 <= /p>

a) = ;     “A new mech= anism, to be defined, may also enrich the packet transition in a service ch= ain by passing service-specific information and/or  information pertaining to preceding services in the chain along with the packet being = processed”.    Not clear what this means and if there = is no intention to elaborate on this why include here.

b) = ;     “…. it is important to have a view of the Virtual Ne= twork (VN) topology (VNT)…”. It is not clear why. Could you ple= ase elaborate why it is important.

c) = ;      section 3.1, serv= ice topology,  this could be lot of information.

d) = ;      sec 3.2, mo= st of the discussion is about the generic QoS/utilization related statistic= s counters. Are there any service chaining (the topic of this draft) specific counters requirements (e.g. FW, DPI etc) mentioned in sect= ion 3?

e) = ;     Suggest to add a = section that should list the scale requirements for the use cases covered i= n the draft

 <= /p>

Thanks,=

Iftekhar

 <= /p>

From: Bitar, N= abil N [mailto:nabil.n.bitar@verizon.com]
Sent: Thursday, September 26, 2013 7:16 AM
To: i2rs@ietf.org
Subject: [i2rs] soliciting WG feedback and comments on draft-bitar-i= 2rs-service-chaining-00

 

Hi,

We had submitted the follow= ing draft http://tools.ietf.org/html/draft-bitar-i2rs-service-chainin= g-00 last ietf. Your feedback and comments on the i2rs mailing list are appreciated.= We will be looking to update the draft.

 

 

Thanks,

Nabil

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53FAB3075SVEXDBPROD1infi_-- From ghanwani@gmail.com Tue Oct 15 22:14: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 780AC11E825B for ; Tue, 15 Oct 2013 22:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=0.413, 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 CnV-oDovXQay for ; Tue, 15 Oct 2013 22:14:23 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B46DA11E8259 for ; Tue, 15 Oct 2013 22:14:23 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so594141ieb.37 for ; Tue, 15 Oct 2013 22:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dr5zz8/fomk2QWxX7FLY3VWD8DCLZTsgLOr+qBWANCU=; b=IX3craKP7OUj0dC+Cq3Z1OC630YHg8Fb8xEwIxm1A9AXW3wRqFicKNoa3yj2avEtpo vel4Z4X0z/S0I5eSS/FO2CourGJK1CbWOp8zwY96opbT82m0Y346YuBwtY2DmSJI8kdi wDNuihDpaTB+y51K1kTbg8A42RT7k+d1709AV9scDIDnCo0Ls2ri6L4x/9ckgxieG451 P4LDH3ApzjGgNt/nLjE/w8Fu9Pe79sjJhJ/PFmXDCsT7t8jE0fq7T0FbZz7v0YEj7nvQ Z1jTkMCjqMO6L5IXuRJvlhQwsOL2/5CpSQSa14xewI4TS0rj/WVDg87jjObAfdBG4hJ5 TgEg== MIME-Version: 1.0 X-Received: by 10.50.114.67 with SMTP id je3mr625741igb.59.1381900463070; Tue, 15 Oct 2013 22:14:23 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.50.114.97 with HTTP; Tue, 15 Oct 2013 22:14:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 22:14:23 -0700 X-Google-Sender-Auth: 17lzjxBkNYqJo5axlqEcOH5TgAA Message-ID: From: Anoop Ghanwani To: ramki Krishnan Content-Type: multipart/alternative; boundary=047d7b3a9b4037654d04e8d4c683 Cc: "i2rs@ietf.org" Subject: Re: [i2rs] FW: New Version Notification for draft-krishnan-i2rs-large-flow-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: Wed, 16 Oct 2013 05:14:24 -0000 --047d7b3a9b4037654d04e8d4c683 Content-Type: text/plain; charset=ISO-8859-1 As an attempt to get the discussion on this draft going... At a high-level level, this mechanisms detects flows (using methods outside of I2RS) that consume a certain % of link BW. Then, using I2RS' PBR, it pins that flow to a specific LAG/ECMP component (which may or may not match what regular hashing would have done) AND it adjusts the weights used to be used when hashing (which would affect all the "small" flows to account for the large flow. This is for what we call local load balancing. There's also global load balancing which involves programming a PBR entry throughout the path of the flow. Would appreciate any review/comments from folks. Thanks, Anoop On Sun, Oct 13, 2013 at 10:07 PM, ramki Krishnan wrote: > Dear All, > > Your comments on this draft are most welcome. > > Thanks, > Ramki (on behalf of the co-authors) > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, October 13, 2013 10:03 PM > To: Dave McDysan; Dave Mcdysan; ramki Krishnan; Sriganesh Kini; ramki > Krishnan; Anoop Ghanwani > Subject: New Version Notification for > draft-krishnan-i2rs-large-flow-use-case-00.txt > > > A new version of I-D, draft-krishnan-i2rs-large-flow-use-case-00.txt > has been successfully submitted by Ram Krishnan and posted to the > IETF repository. > > Filename: draft-krishnan-i2rs-large-flow-use-case > Revision: 00 > Title: I2RS Large Flow Use Case > Creation date: 2013-10-13 > Group: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-krishnan-i2rs-large-flow-use-case-00.txt > Status: > http://datatracker.ietf.org/doc/draft-krishnan-i2rs-large-flow-use-case > Htmlized: > http://tools.ietf.org/html/draft-krishnan-i2rs-large-flow-use-case-00 > > > Abstract: > Demands on networking bandwidth are growing exponentially due to > applications such as large file transfers and those with rich media. > Link Aggregation Group (LAG) and Equal Cost Multipath (ECMP) are > extensively deployed in networks to scale the bandwidth. However, > the flow based load balancing techniques used today make inefficient > use of the bandwidth in the presence of long lived large flows. This > draft presents a use-case to improve the efficiency under such > conditions and aims to drive requirements for the I2RS WG. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --047d7b3a9b4037654d04e8d4c683 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As an attempt to get the discussion on this draft going...=

At a high-level level, this mechanisms detects flows (u= sing methods outside of I2RS) that consume a certain % of link BW. =A0

Then, using I2RS' PBR, it pins that flow to a speci= fic LAG/ECMP component (which may or may not match what regular hashing wou= ld have done) AND it adjusts the weights used to be used when hashing (whic= h would affect all the "small" flows to account for the large flo= w. =A0This is for what we call local load balancing.

There's also global load balancing which involves p= rogramming a PBR entry throughout the path of the flow.

Would appreciate any review/comments from folks.

Thanks,
Anoop


=
On Sun, Oct 13, 2013 at 10:07 PM, ramki Krishnan= <ramk@brocade.com> wrote:
Dear All,

Your comments on this draft are most welcome.

Thanks,
Ramki (on behalf of the co-authors)

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Sunday, October 13, 2013 10:03 PM
To: Dave McDysan; Dave Mcdysan; ramki Krishnan; Sriganesh Kini; ramki Krish= nan; Anoop Ghanwani
Subject: New Version Notification for draft-krishnan-i2rs-large-flow-use-ca= se-00.txt


A new version of I-D, draft-krishnan-i2rs-large-flow-use-case-00.txt
has been successfully submitted by Ram Krishnan and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-krishnan-i2rs-large-flow-use-case
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 I2RS Large Flow Use Case
Creation date: =A0 2013-10-13
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-krishnan-i2rs-large-flow-use-case-00.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-krishnan-i2rs-large-flow-use-case
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-krishnan-i2rs-large-flow-use-case-00


Abstract:
=A0 =A0Demands on networking bandwidth are growing exponentially due to
=A0 =A0applications such as large file transfers and those with rich media.=
=A0 =A0Link Aggregation Group (LAG) and Equal Cost Multipath (ECMP) are
=A0 =A0extensively deployed in networks to scale the bandwidth. However, =A0 =A0the flow based load balancing techniques used today make inefficient=
=A0 =A0use of the bandwidth in the presence of long lived large flows. This=
=A0 =A0draft presents a use-case to improve the efficiency under such
=A0 =A0conditions and aims to drive requirements for the I2RS WG.




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

The IETF Secretariat

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

--047d7b3a9b4037654d04e8d4c683-- From akatlas@gmail.com Thu Oct 17 07:28: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 A4C7811E80F5 for ; Thu, 17 Oct 2013 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URGBIZ=0.725, URG_BIZ=1.585] 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 EXFIKrlZH172 for ; Thu, 17 Oct 2013 07:28:09 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17011E81CB for ; Thu, 17 Oct 2013 07:27:12 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so3909004iec.24 for ; Thu, 17 Oct 2013 07:27:11 -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=TWFLdZOCRWEmv+Ae+WUnM1sPREZt8v+v6ewuZ3R5XSU=; b=0JnfyzZCUq73SdvMGyKk9jc6KpMHK2LJCUirixSb5Z+OlIkoplVgrNrfKtzjA46bWP YyZViXiAXUG58PzTiRgCCG3yEPc9D2dJUbF9MbjrLjWxkaMCWPB1TAUgC1wMtW60vZX9 SC7fZAH4LCdsT6LT7Ic+HVgMpSuO4OS1a9IZ/vtpYov23RY7YN7c3+TYyI5FHXrxmhL7 65KAMwGkDBdm4E34j1Az+SyydX7RNcP3rmzNr3NadzeuqAYPyevZRQhzbIyNIhoagh9t RrKtRqOhnWET+xJpfRTalDDJ2pNTKWruEspkF3N19PbQOVVHuK63OTdKHusLSGjRd1i4 sEZQ== MIME-Version: 1.0 X-Received: by 10.50.120.104 with SMTP id lb8mr26488939igb.22.1382020031028; Thu, 17 Oct 2013 07:27:11 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 17 Oct 2013 07:27:10 -0700 (PDT) Received: by 10.64.78.72 with HTTP; Thu, 17 Oct 2013 07:27:10 -0700 (PDT) In-Reply-To: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> References: <20131017142434.21877.63746.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 10:27:10 -0400 Message-ID: From: Alia Atlas To: i2rs@ietf.org Content-Type: multipart/alternative; boundary=047d7bd76bb205a9b304e8f09d42 Subject: [i2rs] Fwd: NOMCOM - Critical shortage of nominees for multiple areas 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, 17 Oct 2013 14:28:09 -0000 --047d7bd76bb205a9b304e8f09d42 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: "NomCom Chair 2013" Date: Oct 17, 2013 10:25 AM Subject: NOMCOM - Critical shortage of nominees for multiple areas To: "IETF Announcement List" Cc: "IETF Discuss" [Catchier Subject line - apologies to those offended by a duplicate] A critically low number of people have accepted nominations for some of the IESG open positions. There is only one nominee per slot in APP, OPS and TSV, only two in INT and RAI. Many folks have declined nominations. While the Nomcom appreciates that support for two years of intense service is hard to assure, and while we are aware that there is much support for the incumbents who are standing, the IETF should continually be considering which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation. Therefore, we urgently request that more nominees come forward. DEADLINES Nominations - October 18 Questionnaires from nominees - October 25 Not coincidentally, this is a good time to think over and send your comments about the current statements of desired expertise of positions - this is part of the Nomcom's annual review process as well. Send them to nomcom13@ietf.org. Definitive location [*] of the current statements on desired expertise: https://datatracker.ietf.org/nomcom/2013/expertise/ Instructions and details on nomination [**]: https://datatracker.ietf.org/ann/nomcom/60602/ Thanks, everyone, Allison for the Nomcom [*] This year the Nomcom tools were recoded, and also transitioned into the datatracker. Apologies for a number of places where we didn't catch reference errors. [**] Yes, alas, the previous call for nominations used "OAM" instead of "OPS," but we have* corrected this (chair's pilot) error where it occurred in the Nomcom pages. --047d7bd76bb205a9b304e8f09d42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= "NomCom Chair 2013" <nomcom-chair-2013@ietf.org>
Date: Oct 17, 2013 10:25 AM
= Subject: NOMCOM - Critical shortage of nominees for multiple areas
To: "IETF Announcement List" <ietf-announce@ietf.org>
Cc: "IETF Discuss" &l= t;ietf@ietf.org>

[Catchier Subject line - apologies to those offended by a duplicate]

A critically low number of people have accepted nominations for some of the=
IESG open positions. =A0There is only one nominee per slot in APP, OPS and = TSV,
only two in INT and RAI. =A0Many folks have declined nominations.

While the Nomcom appreciates that support for two years of intense service<= br> is hard to assure, and while we are aware that there is much support for th= e
incumbents who are standing, the IETF should continually be considering
which new talent is available for our leadership, and the Nomcom process needs for there to be some review and deliberation.

Therefore, we urgently request that more nominees come forward.

DEADLINES
Nominations - October 18
Questionnaires from nominees - October 25

Not coincidentally, this is a good time to think over and send your comment= s
about the current statements of desired expertise of positions - this is pa= rt of
the Nomcom's annual review process as well. =A0Send them to nomcom13@ietf.org.

Definitive location [*] of the current statements on desired expertise:
=A0 =A0 =A0 https://datatracker.ietf.org/nomcom/2013/expertise/<= br>
Instructions and details on nomination [**]:
=A0 =A0 =A0 https://datatracker.ietf.org/ann/nomcom/60602/

Thanks, everyone,

Allison for the Nomcom

[*] This year the Nomcom tools were recoded, and also transitioned into the=
datatracker. =A0Apologies for a number of places where we didn't catch = reference
errors.

[**] Yes, alas, the previous call for nominations used "OAM" inst= ead of "OPS," but
we have* corrected this (chair's pilot) error where it occurred in the = Nomcom
pages.
--047d7bd76bb205a9b304e8f09d42-- From internet-drafts@ietf.org Fri Oct 18 09:52: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 2EBC311E831C; Fri, 18 Oct 2013 09:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 YdJWb9neDbF4; Fri, 18 Oct 2013 09:52:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A1311E8311; Fri, 18 Oct 2013 09:52:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018165232.4087.29733.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 09:52:32 -0700 Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-rib-info-model-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:52:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Interface to the Routing System Working G= roup of the IETF. Title : Routing Information Base Info Model Author(s) : Nitin Bahadur Ron Folkes Sriganesh Kini Jan Medved Filename : draft-ietf-i2rs-rib-info-model-01.txt Pages : 26 Date : 2013-10-18 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nitin_bahadur@yahoo.com Fri Oct 18 10:00:37 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 A460211E826F for ; Fri, 18 Oct 2013 10:00:37 -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 RiBZ9MTD5imV for ; Fri, 18 Oct 2013 10:00:32 -0700 (PDT) Received: from nm25-vm5.bullet.mail.ne1.yahoo.com (nm25-vm5.bullet.mail.ne1.yahoo.com [98.138.91.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6669211E833D for ; Fri, 18 Oct 2013 09:59:45 -0700 (PDT) Received: from [98.138.90.57] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2013 16:59:40 -0000 Received: from [98.138.226.127] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Oct 2013 16:59:40 -0000 Received: from [127.0.0.1] by smtp206.mail.ne1.yahoo.com with NNFMP; 18 Oct 2013 16:59:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1382115580; bh=csy0Hxm64jrBpQe/iK/9/ro3l/vR/6sg5euNS7baUTw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=HB+GqJ7t2UCnSqNrHxzH/LFngWHO4ZH7zwOuaaiyxvxQqmH2kcYoZiRQ6K6HoeN8/n3ZyRcrJy5GQlx1S7duiOzMzRUTFn9L0QAJ+ZbZG2LFmv4ZvMWPjmnwBQM4si2GZutJneKPva42hIBV8136MQWiW+tBlGc/gI/yX2Stei0= X-Yahoo-Newman-Id: 818803.73163.bm@smtp206.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6aDqNsQVM1nwXO46uhGwAirGk.4p8st_NolqmFynvU1y46S udPysvqPG7GXGdso9l5JECvWAvgbIqUuL5nyrf.bHwN4EdKGzHY14xcVUPjf oX.B8MAV0dxbmDCGh9A2zTXQX66JHMuDHLjXnFFliXEispolAR04_oh8bqFl bZbuTqPJZR8sQwzB0PnMR_Yt.Z5Vsh_6QyWUAlLo7TDbYnC4jvBVbNs4H1_w 8GvF8SMDiNolKrx6cVx5yYsj8HZcTBOYL8h7VLDon_x0ndYhfekfm5zCtNXj H.xsSZgsV_vuDyZniy8G19i3YgfZMBy7lK7ibVmnRE1A4Clcn1HJlXyKEzxZ wm9lC42D0Vwa8VUTEs81RljQPrU1UQjPIm0lTBQf3jcqxfAotFqGe97Cw_GC nbqZn_2jbK7fOZQZ5E0RSXXjv49jTpzAQv92mwEDpXsOrZPzDx_131RjVSqY 008SNmVyp4.fa0M4Ec9QdgpoNqOZriOohAY0wD.Yo02GnJA9xatQj7GU5hoE NDdlfZ_yBoqUU5yKC763yNztOiCL6jPAENx92_C09abFzrvk4QiaCbP1tXt_ BTAL1b638Ur8- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- X-Rocket-Received: from nitinb-sslvpn-nc.jnpr.net (nitin_bahadur@66.129.224.36 with ) by smtp206.mail.ne1.yahoo.com with SMTP; 18 Oct 2013 09:59:40 -0700 PDT From: Nitin Bahadur Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_18928D0D-12DD-4090-8AC7-79B5DD719C7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 18 Oct 2013 09:59:45 -0700 In-Reply-To: <20131018165232.4087.29733.idtracker@ietfa.amsl.com> To: i2rs@ietf.org References: <20131018165232.4087.29733.idtracker@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.1283) Subject: Re: [i2rs] I-D Action: draft-ietf-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: Fri, 18 Oct 2013 17:00:37 -0000 --Apple-Mail=_18928D0D-12DD-4090-8AC7-79B5DD719C7E Content-Type: multipart/alternative; boundary="Apple-Mail=_26FD31AE-B103-4E2A-8F3B-1AAE49073E43" --Apple-Mail=_26FD31AE-B103-4E2A-8F3B-1AAE49073E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii New version of the RIB info model has been posted. Main changes include: - Inter-domain (AS) specific stuff is out from the main grammar. I've added a new section called "Inter-domain extensions to the RIB" that = puts all the inter-domain stuff as optional augmentations. - Consolidated rib-family and nexthop-address-family into a single = thing. They were simply duplicates. - Got rid of fields nexthop-attributes. There was contention that things like NO_PROPAGATE_TTL and NO_DECREMENT_TTL are too implementation = specific and shouldn't be in the info model. Since those were only the only attributes currently present, there was no point in having a = nexthop-attr object that contained nothing. - Got rid of the INSTANCE_DISTINGUISHER. It was a topic of great discussion and everyone felt that INSTANCE_NAME and = INSTANCE_DISTINGUISHER were both the same thing (from a modeling perspective). - Fixed numbering for the figures - Added reference to multicast in the figures - Got rid of route-metric, since there was no strong use-case for a controller programming 2 routes with different metrics in the same RIB. - Enhanced ipv4/ipv6 route object so as to enable source based routing. Events and notifications section has not been updated in this rev. Thanks Nitin On Oct 18, 2013, at 9:52 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Interface to the Routing System = Working Group of the IETF. >=20 > Title : Routing Information Base Info Model > Author(s) : Nitin Bahadur > Ron Folkes > Sriganesh Kini > Jan Medved > Filename : draft-ietf-i2rs-rib-info-model-01.txt > Pages : 26 > Date : 2013-10-18 >=20 > 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 datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs Thanks Nitin --Apple-Mail=_26FD31AE-B103-4E2A-8F3B-1AAE49073E43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii added a new section = called "Inter-domain extensions to the RIB" that puts
all the inter-domain stuff as optional = augmentations.
- Consolidated = rib-family and nexthop-address-family into a single thing.
They were simply duplicates.

- Got rid of fields nexthop-attributes. There was contention = that things
like = NO_PROPAGATE_TTL and NO_DECREMENT_TTL are too implementation = specific
and shouldn't be in = the info model. Since those were only the only
attributes currently present, there = was no point in having a nexthop-attr
object that contained nothing.

- Got rid = of the INSTANCE_DISTINGUISHER. It was a topic of great
discussion and everyone felt that = INSTANCE_NAME and INSTANCE_DISTINGUISHER
were both the same thing (from a modeling = perspective).

- Fixed numbering for the = figures

- Added reference to multicast in the = figures

- Got rid of route-metric, since there = was no strong use-case for a

- Enhanced ipv4/ipv6 route object so = as to enable source based routing.

Events and = notifications section has not been updated in this rev.

Thanks
internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of = the Interface to the Routing System Working Group of the = IETF.

= Title =           : Routing = Information Base Info Model
Author(s) =       : Nitin Bahadur
=             &n= bsp;           &nbs= p;Ron Folkes
=             &n= bsp;           &nbs= p;Sriganesh Kini
=             &n= bsp;           &nbs= p;Jan Medved
= Filename        : = draft-ietf-i2rs-rib-info-model-01.txt
Pages =           : = 26
= Date =            : = 2013-10-18

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.


The IETF datatracker status page = for this draft is:
h= ttps://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model

= There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-i2rs-rib-info-model-01
A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-i2rs-rib-info-model-0= 1


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

Internet-Drafts are also available by = anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Thread-Topic: Soliciting WG feedback and comments on draft-jxf-i2rs-im-architecture-00 Thread-Index: AQHOzgg1pWVwZuPDwEGEQswkEvxVeA== Date: Mon, 21 Oct 2013 02:49:49 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.72.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Jixiaofeng \(Steven\)" , Lizhenbin , Yangang Subject: [i2rs] Soliciting WG feedback and comments on draft-jxf-i2rs-im-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: Mon, 21 Oct 2013 02:50:14 -0000 SGk6DQoNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUtMDAsIFlvdXIgZmVlZGJh Y2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVk Lg0KDQpXaGVuIHdlIGNvZGUgc29tZSBwcm9ncmFtLCBzb21lIHJ1bGVzIHdpbGwgaGVscCB1cyB0 byBkbyBzb21lIGRlc2lnbiwgbGlrZSAiaGlnaGx5IGNvaGVzaXZlIGFuZCBsb3cgY291cGxpbmci LCBidXQgaW4gZGVzaWduIG9mIGluZm9ybWF0aW9uIG1vZGVsLCBub3J0aGJvdW5kIGludGVyZmFj ZXMsIHRoZXJlIGFyZSBzb21lIGRpZmZpY3VsdCB0byBqdWRnZSBpZiB0aGlzIGRlc2lnbiBpcyBn b29kIG9yIG5vdCwgd2UgdHJ5IHRvIHByb3ZpZGUgYSBraW5kIG9mIHRoaXMgaW5mb3JtYXRpb24g bW9kZWwgc3RydWN0dXJlIG9mIHRoZSBuZXR3b3JrIGRldmljZSwgdHJ5IHRvIGdldCBzb21lIHJv bGVzIHRvIGRlc2lnbiB0aGUgaW5mb3JtYXRpb24gbW9kZWwuDQoNClRoYW5rcywNClJhaHVsLllh bg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6 IDIwMTPlubQxMOaciDE45pelIDE1OjE1DQrmlLbku7bkuro6IFRpbmEgVFNPVTsgSml4aWFvZmVu ZyAoU3RldmVuKTsgVGluYSBUU09VOyBZYW5nYW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtanhmLWkycnMtaW0tYXJjaGl0ZWN0dXJlLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9mZW5nIEppIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtanhmLWkycnMt aW0tYXJjaGl0ZWN0dXJlDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBBbiBpbmZvcm1hdGlvbiBt b2RlbCBhdGNoaXRlY3R1cmUgb2YgbmV0d29yayBkZXZpY2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEz LTEwLTE4DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog Nw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtanhmLWkycnMtaW0tYXJjaGl0ZWN0 dXJlDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWp4 Zi1pMnJzLWltLWFyY2hpdGVjdHVyZS0wMA0KDQoNCkFic3RyYWN0Og0KICAgQ3VycmVudGx5LCBu ZXR3b3JrIGVxdWlwbWVudCBhbHJlYWR5IGhhcyBzb21lIE5vcnRoYm91bmQgSW50ZXJmYWNlcywN CiAgIHN1Y2ggYXMgU05NUCwgTkVUQ09ORiwgVEwxOyBhbmQgc29tZSBsYW5ndWFnZXMgYXJlIGFs c28gcHJvdmlkZWQgdG8NCiAgIGRlc2NyaWJlIHRoZSBkYXRhIG1vZGVsLCBzdWNoIGFzIE1JQiwg U0NIRU1BIGFuZCBldmVuIFlBTkcuICBXaGlsZQ0KICAgdGlsbCBub3csIHRoZXJlIGlzIG5vdCBh IGNsZWFyIGRlZmluZWQgaW5mb3JtYXRpb24gbW9kZWwuICBJbiBORVRDT05GDQogICBkb21haW4s IHNvbWUgc3RhbmRhcmRzIGFyZSBiZWluZyBkZWZpbmVkLiAgSW4gb3JkZXIgdG8gcmVkdWNlIHRo ZQ0KICAgY29zdCBvZiBOTVMgaW50ZWdyYXRpb24gaW4gY3VzdG9tZXIgc2lkZSwgYSBjbGVhciBk ZWZpbmVkIGluZm9ybWF0aW9uDQogICBtb2RlbCBpcyBuZWNlc3NhcnksIGp1c3QgbGlrZSB0aGUg U0lEIGluIFRNRi4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From huangtieying@huawei.com Mon Oct 21 00:00: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 1D8F311E8175 for ; Mon, 21 Oct 2013 00:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 AsEoKkqXR3hY for ; Sun, 20 Oct 2013 23:59:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC9BD11E8110 for ; Sun, 20 Oct 2013 23:59:55 -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.7-GA FastPath queued) with ESMTP id AWZ97167; Mon, 21 Oct 2013 06:59:53 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 07:59:46 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 07:59:51 +0100 Received: from nkgeml510-mbs.china.huawei.com ([169.254.4.27]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 14:59:37 +0800 From: Huangtieying To: "i2rs@ietf.org" Thread-Topic: Soliciting WG feedback and comments on draft-huang-i2rs-mpls-te-usecases-00 Thread-Index: AQHOzg10EPLLCKT5G0GwBUqASWUFCg== Date: Mon, 21 Oct 2013 06:59:37 +0000 Message-ID: <79EA23FFD17CE645922E0A1D0E4653793CA9144E@nkgeml510-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.59] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Lizhenbin Subject: [i2rs] Soliciting WG feedback and comments on draft-huang-i2rs-mpls-te-usecases-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: Mon, 21 Oct 2013 07:00:01 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1odWFuZy1pMnJzLW1wbHMtdGUtdXNlY2FzZXMtMDAsIFlvdXIgZmVlZGJh Y2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBydGd3ZyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVk Lg0KDQpBbiBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcoVEUpIG5ldHdvcmsgaXMgdHlwaWNhbGx5 IGNvbmZpZ3VyZWQgYW5kIHJlc3VsdHMgb2YgaXRzIG9wZXJhdGlvbiBhcmUgYW5hbHl6ZWQgYnkg Q29tbWFuZCBMaW5lIEludGVyZmFjZShDTEkpLCBTTk1QIG9yIE5FVENPTkYuIEludGVyZmFjZSB0 byB0aGUgUm91dGluZyBTeXN0ZW0ncyAoSTJSUykgUHJvZ3JhbW1hdGljIGludGVyZmFjZXMsIGFz IGRlZmluZWQgaW4gW0ktRC53YXJkLWkycnMtZnJhbWV3b3JrXSwgcHJvdmlkZXMgYW4gYWx0ZXJu YXRlIHdheSB0byBjb250cm9sIHRoZSBjb25maWd1cmF0aW9uIGFuZCBkaWFnbm9zZSB0aGUgb3Bl cmF0aW9uIG9mIE1QTFMgVEUuIEkyUlMgbWF5IGJlIHVzZWQgZm9yIHRoZSBjb25maWd1cmF0aW9u LCBtYW5pcHVsYXRpb24sIHBvbGxpbmcgb3IgYW5hbHl6aW5nIE1QTFMgVEUuICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBzZXQgb2YgdXNlIGNhc2VzIGZvciB3aGljaCBJMlJTIGNhbiBiZSB1c2Vk IGZvciBNUExTIFRFLiAgSXQgaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIGJhc2UgZm9yIHRoZSBz b2x1dGlvbiBkcmFmdCBkZXNjcmliaW5nIGEgc2V0IG9mIGludGVyZmFjZXMgdG8gTVBMUyBURS4N Cg0KVGhhbmtzLA0KTW9ycnkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCreiy83KsbzkOiAyMDEzxOoxMNTCMjDI1SAyMzoyNg0KytW8/sjLOiBIdWFuZ3Rp ZXlpbmc7IExpemhlbmJpbg0K1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1odWFuZy1pMnJzLW1wbHMtdGUtdXNlY2FzZXMtMDAudHh0DQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaHVhbmctaTJycy1tcGxzLXRlLXVzZWNhc2VzLTAwLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaWV5aW5nIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJ RVRGIHJlcG9zaXRvcnkuDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWh1YW5nLWkycnMtbXBscy10 ZS11c2VjYXNlcw0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICBVc2UgQ2Fz ZXMgZm9yIGFuIEludGVyZmFjZSB0byBNUExTIFRFDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMTAt MjANCkdyb3VwOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFn ZXM6IDgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaHVhbmctaTJycy1tcGxzLXRlLXVzZWNhc2VzLTAwLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1YW5nLWkycnMtbXBs cy10ZS11c2VjYXNlcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1odWFuZy1pMnJzLW1wbHMtdGUtdXNlY2FzZXMtMDANCg0KQWJzdHJhY3Q6DQogICBB biBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcoVEUpIG5ldHdvcmsgaXMgdHlwaWNhbGx5IGNvbmZp Z3VyZWQgYW5kDQogICByZXN1bHRzIG9mIGl0cyBvcGVyYXRpb24gYXJlIGFuYWx5emVkIGJ5IENv bW1hbmQgTGluZSBJbnRlcmZhY2UNCiAgIChDTEkpLCBTTk1QIG9yIE5FVENPTkYuICBUaGVzZSBp bnRlcmFjdGlvbnMgdG8gY29udHJvbCBNUExTIFRFIGFuZA0KICAgZGlhZ25vc2UgaXRzIG9wZXJh dGlvbiBlbmNvbXBhc3M6IE1QTFMgVEUgY29uZmlndXJhdGlvbiwgTVBMUyBURQ0KICAgcHJvdGVj dGlvbiwgdHJhZmZpYyBzd2l0Y2hpbmctb3ZlciwgbW9uaXRvcmluZyBvZiBNUExTIFRFIGFuZCBm YXVsdA0KICAgZGV0ZWN0aW9uLg0KICAgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbSdz IChJMlJTKSBQcm9ncmFtbWF0aWMgaW50ZXJmYWNlcywgYXMNCiAgIGRlZmluZWQgaW4gW0ktRC53 YXJkLWkycnMtZnJhbWV3b3JrXSwgcHJvdmlkZXMgYW4gYWx0ZXJuYXRlIHdheSB0bw0KICAgY29u dHJvbCB0aGUgY29uZmlndXJhdGlvbiBhbmQgZGlhZ25vc2UgdGhlIG9wZXJhdGlvbiBvZiBNUExT IFRFLg0KICAgSTJSUyBtYXkgYmUgdXNlZCBmb3IgdGhlIGNvbmZpZ3VyYXRpb24sIG1hbmlwdWxh dGlvbiwgcG9sbGluZyBvcg0KICAgYW5hbHl6aW5nIE1QTFMgVEUuICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBzZXQgb2YgdXNlIGNhc2VzIGZvcg0KICAgd2hpY2ggSTJSUyBjYW4gYmUgdXNlZCBm b3IgTVBMUyBURS4gIEl0IGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYSBiYXNlDQogICBmb3IgdGhl IHNvbHV0aW9uIGRyYWZ0IGRlc2NyaWJpbmcgYSBzZXQgb2YgaW50ZXJmYWNlcyB0byBNUExTIFRF Lg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQpUaGUgSUVURiBTZWNyZXRh cmlhdA== From monica.zhangli@huawei.com Mon Oct 21 00:26: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 A208C11E834C for ; Mon, 21 Oct 2013 00:26:47 -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 D0yBvRX73f6E for ; Mon, 21 Oct 2013 00:26:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 46F3511E8135 for ; Mon, 21 Oct 2013 00:26:42 -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.7-GA FastPath queued) with ESMTP id AWZ99967; Mon, 21 Oct 2013 07:26:40 +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.3.146.0; Mon, 21 Oct 2013 08:26:21 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 08:26:27 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 15:26:16 +0800 From: "Zhangli (Monica, VRP)" To: "i2rs@ietf.org" Thread-Topic: [i2rs] Soliciting WG feedback and comments on draft-zhang-i2rs-mbb-usecases-00 Thread-Index: AQHOzgtYz9Iy7ugVg0ONI1oz7aJ+QZn+rpqggAACgbA= Date: Mon, 21 Oct 2013 07:26:15 +0000 Message-ID: <2E2F38F47A79124184DFA31B0E0B7BCD348FF941@nkgeml512-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.58.170] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Dapeng Liu , Lizhenbin , "Zhangli \(Monica, VRP\)" Subject: [i2rs] Soliciting WG feedback and comments on draft-zhang-i2rs-mbb-usecases-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: Mon, 21 Oct 2013 07:26:47 -0000 SGk6DQoNCldlIGhhZCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0IC16aGFuZy1pMnJzLW1iYi11c2VjYXNlcy0wMCwgWW91ciBmZWVkYmFjayBh bmQgY29tbWVudHMgb24gdGhlIHJ0Z3dnIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0ZWQuDQoN CkFzIGEgbmV0d29yayBzb2x1dGlvbiwgdGhlIGRlcGxveW1lbnRzIG9mIG1vYmlsZSBiYWNraGF1 bCBuZXR3b3JrIGFyZSBtdWNoIG1vcmUgZmxleGlibGUgYW5kIHVucHJlZGljdGFibGUgd2l0aCBt dWx0aXBsZSBuZXR3b3JrIGFwcGxpY2F0aW9ucywgdW5wcmVkaWN0YWJsZSByb3V0ZSBwb2xpY2ll cywgdmFyaW91cyBzZXJ2aWNlIHR1bm5lbHMsIHNlcGFyYXRlIHByb3RlY3Rpb24gbWVjaGFuaXNt cywgYW5kIGFjY3VyYXRlIG5ldHdvcmsgbW9uaXRvcmluZy4gVHJhZGl0aW9uYWwgZGV2aWNlLWxl dmVsIGNvbmZpZ3VyYXRpb24gYW5kIGRpYWdub3NlcyBtZWNoYW5pc20gYXJlIGlsbC1zdWl0ZWQg dG9kYXkuIFdlIHRyeSB0byBhbmFseXplIHRoZSBtYWluIHVzZSBjYXNlcyBvZiBtb2JpbGUgYmFj a2hhdWwgbmV0d29yayB0byBkZXNjcmliZSB0aGUgbmVlZHMgb2YgSTJSUydzIHByb2dyYW1tYWJs ZSBpbnRlcmZhY2UgaW4gdGhpcyBkcmFmdC4gICANCg0KVGhhbmtzLA0KTW9uaWNhLlpoYW5nIA0K DQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIw MTPlubQxMOaciDIx5pelIDExOjEyDQrmlLbku7bkuro6IExpIFpoYW5nOyBEYXBlbmcgTGl1OyBM aXpoZW5iaW4NCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGFu Zy1pMnJzLW1iYi11c2VjYXNlcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtemhhbmctaTJycy1tYmItdXNlY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IExpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtemhhbmctaTJycy1tYmItdXNlY2FzZXMNClJldmlzaW9uOgkg MDANClRpdGxlOgkJIFVzZSBDYXNlcyBvZiBJMlJTIGluIE1vYmlsZSBCYWNraGF1bCBOZXR3b3Jr DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0yMQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoYW5nLWkycnMtbWJiLXVzZWNhc2VzLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXpoYW5nLWkycnMtbWJiLXVzZWNhc2VzDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWkycnMtbWJiLXVzZWNhc2VzLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBJbiBtb2JpbGUgYmFja2hhdWwgbmV0d29yaywgdHJhZGl0aW9uYWwgY29uZmlndXJh dGlvbiBhbmQgZGlhZ25vc2VzDQogICBtZWNoYW5pc21zIGJhc2Ugb24gZGV2aWNlLWxldmVsIG1h bmFnZW1lbnQgdG9vbHMgYW5kIG1hbnVhbA0KICAgcHJvY2Vzc2luZyBhcmUgaWxsLXN1aXRlZCB0 byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgdG9kYXkncw0KICAgc2NhbGFibGUsIGZsZXhpYmxl LCBhbmQgY29tcGxleCBuZXR3b3JrLiAgVGhhbmtzIHRvIHRoZSBuZXcNCiAgIGlubm92YXRpb24g b2YgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5c3RlbSdzIChJMlJTKSBwcm9ncmFtbWF0aWMN CiAgIGludGVyZmFjZXMsIGFzIGRlZmluZWQgaW4gW0ktRC53YXJkLWkycnMtZnJhbWV3b3JrXSwg YW4gYWx0ZXJuYXRpdmUNCiAgIHdheSBoYXMgYmVlbiByb2xsZWQgb3V0IHRvIGNvbnRyb2wgdGhl IGNvbmZpZ3VyYXRpb24gYW5kIGRpYWdub3NlIHRoZQ0KICAgb3BlcmF0aW9uIHJlc3VsdHMuICBU aGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgdXNlIGNhc2Ugb2YgSTJSUyBpbg0KICAgbW9iaWxl IGJhY2toYXVsIG5ldHdvcmsuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg== From zhuangshunwan@huawei.com Mon Oct 21 04:19: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 5EB8E11E81A1 for ; Mon, 21 Oct 2013 04:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ozpzXSFpirZB for ; Mon, 21 Oct 2013 04:18:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACCE11E837C for ; Mon, 21 Oct 2013 04:18:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZH27447; Mon, 21 Oct 2013 11:18:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 12:17:58 +0100 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 12:18:53 +0100 Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com (10.82.67.95) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 19:18:41 +0800 From: Zhuangshunwan To: Date: Mon, 21 Oct 2013 19:18:40 +0800 Message-ID: <000d01cece4f$4bb1ba00$e3152e00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7ORWCniGMad4FKSDOnEbbExfV16wACH1oA Content-Language: zh-cn X-Originating-IP: [10.111.80.111] X-CFilter-Loop: Reflected Cc: yangang@huawei.com, jixiaofeng@huawei.com, 'Huangtieying' , 'Lizhenbin' Subject: [i2rs] Soliciting WG feedback and comments on draft-ji-i2rs-usecases-ccne-service-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: Mon, 21 Oct 2013 11:19:05 -0000 Hi, We had submitted a new draft: http://tools.ietf.org/html/ = draft-ji-i2rs-usecases-ccne-service-00. Your feedback and comments on = the i2rs mailing list are appreciated. We will be looking to update the = draft. Thanks, Shunwan Zhuang -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B410=E6=9C=8821=E6=97=A5 18:07 =E6=94=B6=E4=BB=B6=E4=BA=BA: Shunwan Zhuang; Xiaofeng Ji; Tieying Huang =E4=B8=BB=E9=A2=98: New Version Notification for = draft-ji-i2rs-usecases-ccne-service-00.txt A new version of I-D, draft-ji-i2rs-usecases-ccne-service-00.txt has been successfully submitted by Xiaofeng Ji and posted to the IETF repository. Filename: draft-ji-i2rs-usecases-ccne-service Revision: 00 Title: I2RS Use Cases for Control of Forwarding Path by Central = Control Network Element (CCNE) Creation date: 2013-10-21 Group: Individual Submission Number of pages: 11 URL: = http://www.ietf.org/internet-drafts/draft-ji-i2rs-usecases-ccne-service-0= 0.txt Status: = http://datatracker.ietf.org/doc/draft-ji-i2rs-usecases-ccne-service Htmlized: = http://tools.ietf.org/html/draft-ji-i2rs-usecases-ccne-service-00 Abstract: With the development of network technologies, more and more applications need to have a central control point for the network elements in one administrative domain, such central control point is a central control network element (CCNE). CCNE controls the network elements in its administrative domain, the type of CCNE can be RR Router, PCE Server, or a federation of RR Router and PCE Server, etc. CCNE is developed from the traditional network element, which plus some I2RS interfaces, can provide both traditional network services and I2RS services. This document describes requirement and use cases for which I2RS can be used for CCNE device. The use cases described in this document encompass: Control IP Network by RR Router, Control MPLS TE Network by PCE Server. The goal is to inform the community's understanding of where the I2RS CCNE extensions fit within the overall I2RS architecture. It is intended to provide a basis for the solutions draft describing the set of interfaces for the CCNE device. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From jescia.chenxia@huawei.com Mon Oct 21 04:54:42 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 E5A2211E8506 for ; Mon, 21 Oct 2013 04:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[AWL=2.253, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 cXEN6K-QjlcW for ; Mon, 21 Oct 2013 04:54:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 711F311E84F1 for ; Mon, 21 Oct 2013 04:54:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZH31180; Mon, 21 Oct 2013 11:54:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 12:54:24 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 12:54:30 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.102]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 19:54:17 +0800 From: "Chenxia (D)" To: "i2rs@ietf.org" Thread-Topic: Soliciting WG feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-00 Thread-Index: AQHOzlKdlq8lhN++Q0u8EMTR/gSvug== Date: Mon, 21 Oct 2013 11:54:16 +0000 Message-ID: <346809D6D8BB1849AF0886D035619F9C277D3412@nkgeml505-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.81.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Chenxia \(D\)" , Lizhenbin Subject: [i2rs] Soliciting WG feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-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: Mon, 21 Oct 2013 12:22:07 -0000 SGk6DQoNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGEgbmV3IGRyYWZ0OiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWkycnMtbXBscy1sZHAtdXNlY2FzZXMtMDAsIFlvdXIgZmVl ZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBpMnJzIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0 ZWQuDQpXZSBkZXNjcmliZSByZXF1aXJlbWVudCBhbmQgdXNlIGNhc2VzIGZvciB3aGljaCBJMlJT IGNhbiBiZSAgdXNlZCBmb3IgTERQIHByb3RvY29sLg0KDQpUaGFua3MsDQpYaWEgQ2hlbg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBMaXpoZW5iaW4N Creiy83KsbzkOiAyMDEzxOoxMNTCMjHI1SAxODowOA0KytW8/sjLOiBDaGVueGlhIChEKQ0K1vfM 4jog16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jaGVuLWkycnMtbXBs cy1sZHAtdXNlY2FzZXMtMDAudHh0DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3 osvNyrG85DogMjAxM8TqMTDUwjIwyNUgMjM6MjQNCsrVvP7IyzogQ2hlbnhpYW8gKEEpOyBMaXpo ZW5iaW4NCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbi1pMnJz LW1wbHMtbGRwLXVzZWNhc2VzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1jaGVuLWkycnMtbXBscy1sZHAtdXNlY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFhpYSBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtY2hlbi1pMnJzLW1wbHMtbGRwLXVzZWNhc2Vz DQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIFVzZSBDYXNlcyBmb3IgYW4g SW50ZXJmYWNlIHRvIExEUCBQcm90b2NvbA0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTEwLTIwDQpH cm91cDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3 DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNoZW4taTJycy1tcGxzLWxkcC11c2VjYXNlcy0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLWkycnMtbXBscy1sZHAt dXNlY2FzZXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2hlbi1pMnJzLW1wbHMtbGRwLXVzZWNhc2VzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUg TGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sIChMRFApIFtSRkM1MDM2XSBpcyBhIHByb3RvY29s IGRlZmluZWQNCiAgIGZvciBkaXN0cmlidXRpbmcgbGFiZWxzIGluIE1QTFMgZG9tYWluLiAgVHJh ZGl0aW9uYWxseSBMRFAgcHJvdG9jb2wNCiAgIG1heSBiZSBtYW5hZ2VkIHZpYSBDTEksIFNOTVAg b3IgTkVUQ09ORi4gIEludGVyZmFjZSB0byB0aGUgUm91dGluZw0KICAgU3lzdGVtJ3MgKEkyUlMp IFByb2dyYW1tYXRpYyBpbnRlcmZhY2VzLCBhcyBkZWZpbmVkIGluDQogICBbSS1ELndhcmQtaTJy cy1mcmFtZXdvcmtdLCBwcm92aWRlcyBhbiBhbHRlcm5hdGUgd2F5IHRvIGNvbnRyb2wgdGhlDQog ICBjb25maWd1cmF0aW9uIGFuZCBkaWFnbm9zZSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBMRFAgcHJv dG9jb2wuICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnQgYW5kIHVzZSBj YXNlcyBmb3Igd2hpY2ggSTJSUyBjYW4gYmUNCiAgIHVzZWQgZm9yIExEUCBwcm90b2NvbC4NCg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA== From jescia.chenxia@huawei.com Mon Oct 21 05:29: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 7771F11E82DA for ; Mon, 21 Oct 2013 05:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 57qG003hZGTp for ; Mon, 21 Oct 2013 05:29:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2708611E81B1 for ; Mon, 21 Oct 2013 05:29:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZH34378; Mon, 21 Oct 2013 12:29:24 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 13:29:15 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 13:29:21 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.102]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 20:29:09 +0800 From: "Chenxia (D)" To: "i2rs@ietf.org" Thread-Topic: Soliciting WG feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-00 Thread-Index: AQHOzlkjT4+e7/QxQ027scqwnyEtmg== Date: Mon, 21 Oct 2013 12:29:08 +0000 Message-ID: <346809D6D8BB1849AF0886D035619F9C277D370E@nkgeml505-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.81.24] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Chenxia \(D\)" , Lizhenbin Subject: [i2rs] Soliciting WG feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-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: Mon, 21 Oct 2013 12:29:31 -0000 SGk6DQpXZSBoYWQgc3VibWl0dGVkIHRoZSBhIG5ldyBkcmFmdDogaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtY2hlbi1pMnJzLW1wbHMtbGRwLXVzZWNhc2VzLTAwLCBZb3VyIGZlZWRi YWNrIGFuZCBjb21tZW50cyBvbiB0aGUgaTJycyBtYWlsaW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVk Lg0KV2UgZGVzY3JpYmUgcmVxdWlyZW1lbnQgYW5kIHVzZSBjYXNlcyBmb3Igd2hpY2ggSTJSUyBj YW4gYmUgIHVzZWQgZm9yIExEUCBwcm90b2NvbC4NClRoYW5rcywNClhpYSBDaGVuDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBMaXpoZW5iaW4N Creiy83KsbzkOiAyMDEzxOoxMNTCMjHI1SAxODowOA0KytW8/sjLOiBDaGVueGlhIChEKQ0K1vfM 4jog16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jaGVuLWkycnMtbXBs cy1sZHAtdXNlY2FzZXMtMDAudHh0DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQq3 osvNyrG85DogMjAxM8TqMTDUwjIwyNUgMjM6MjQNCsrVvP7IyzogQ2hlbnhpYW8gKEEpOyBMaXpo ZW5iaW4NCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hlbi1pMnJz LW1wbHMtbGRwLXVzZWNhc2VzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1jaGVuLWkycnMtbXBscy1sZHAtdXNlY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFhpYSBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtY2hlbi1pMnJzLW1wbHMtbGRwLXVzZWNhc2Vz DQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIFVzZSBDYXNlcyBmb3IgYW4g SW50ZXJmYWNlIHRvIExEUCBQcm90b2NvbA0KQ3JlYXRpb24gZGF0ZTogICAyMDEzLTEwLTIwDQpH cm91cDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3 DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNoZW4taTJycy1tcGxzLWxkcC11c2VjYXNlcy0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaGVuLWkycnMtbXBscy1sZHAt dXNlY2FzZXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtY2hlbi1pMnJzLW1wbHMtbGRwLXVzZWNhc2VzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUg TGFiZWwgRGlzdHJpYnV0aW9uIFByb3RvY29sIChMRFApIFtSRkM1MDM2XSBpcyBhIHByb3RvY29s IGRlZmluZWQNCiAgIGZvciBkaXN0cmlidXRpbmcgbGFiZWxzIGluIE1QTFMgZG9tYWluLiAgVHJh ZGl0aW9uYWxseSBMRFAgcHJvdG9jb2wNCiAgIG1heSBiZSBtYW5hZ2VkIHZpYSBDTEksIFNOTVAg b3IgTkVUQ09ORi4gIEludGVyZmFjZSB0byB0aGUgUm91dGluZw0KICAgU3lzdGVtJ3MgKEkyUlMp IFByb2dyYW1tYXRpYyBpbnRlcmZhY2VzLCBhcyBkZWZpbmVkIGluDQogICBbSS1ELndhcmQtaTJy cy1mcmFtZXdvcmtdLCBwcm92aWRlcyBhbiBhbHRlcm5hdGUgd2F5IHRvIGNvbnRyb2wgdGhlDQog ICBjb25maWd1cmF0aW9uIGFuZCBkaWFnbm9zZSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBMRFAgcHJv dG9jb2wuICBUaGlzDQogICBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnQgYW5kIHVzZSBj YXNlcyBmb3Igd2hpY2ggSTJSUyBjYW4gYmUNCiAgIHVzZWQgZm9yIExEUCBwcm90b2NvbC4NCg0K DQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA== From swhyte@google.com Mon Oct 21 14:02: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 2C3FB11E842C for ; Mon, 21 Oct 2013 14:02:43 -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 9j7SlxSWNfh1 for ; Mon, 21 Oct 2013 14:02:42 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E8B5811E84CF for ; Mon, 21 Oct 2013 14:02:36 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ia6so140980vcb.7 for ; Mon, 21 Oct 2013 14:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=R1Y54n90BkcMZ0EF+FybKSYaX/amr2lINB7SZHMm47s=; b=G7kBjTKsJ4SiPH92qK2wfE9msSHxoB86+DBJHIFr4Sj2+7um3fP49mABf+3hmbM92T o6g/AgtuKRwZkiWShxmtCAtINkk+Wk7VEKVP53SW1Z0hzehLL+vm0Cfe83CvN+IBlzto sQolctPCeaiN7qnIFIOJtzO+WyDRHH3wE5LB3o2JARA/RNfwdnjIoDpli/Vlca6SY4MQ ycJsX3FYWXG+YX06TJzSUAqOZUl/oRmU/OL0xxpcdW2fMZV0b9uw/CvJW2o21uEOFNs1 udHLAK7/Ps5M5vWDuJGjRndED8aI+FMd8kq91tbDZyURTLNep5MfsN5R9q1rqgNYMo6j dDJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=R1Y54n90BkcMZ0EF+FybKSYaX/amr2lINB7SZHMm47s=; b=MSpdD75yD67YD4msSPEVK1Vz448vzL5hK71DAo2lTX+CmlvlLPIXfzyE/hVFkqQShq lWIitcwFsKSaeSwgCi8lafIR8eAj691aCbI3uszLlQx+ud1FFH7PN1kOy1hG7Jm6RCUC hy/ONBaOWJjcxWIhPGikhxJuyGmV8tnkHC2UQNBVJw+KzPGrjsrHSceLXLD5z6+BKbr8 1O59jA5FFRXraH9qty96BKrvCpjRH4UiWNJgxPOly9N7PuVBXMP24JUM5a9DtUqlJTrs xD92nHKo9CR10ywbEjayMK1Bzd7nn1Z9CT714mlNBmFcb5PlyP3T1fJSVYyRKT2V2wqp b5PQ== X-Gm-Message-State: ALoCoQmiv2wgGfwrds4zmxu7s6xs2v1f8UD3KrQHUDXNT2BQ6PZDpoVb7mCdDHvfLtEBk9YW+akE4YnWnNJ5UvExvsGgrWrP0y3bwn9eGylD8pjuruq+w4MC7YxU5c11OzMYmNjQJ6iaF0Ao/wi/fR5KDphxKuY1O/gF3c0i8sVf8vxzsBROP8uDPT9V69CeDYIOftM0Jfr6 MIME-Version: 1.0 X-Received: by 10.58.156.106 with SMTP id wd10mr12192927veb.7.1382389356144; Mon, 21 Oct 2013 14:02:36 -0700 (PDT) Received: by 10.52.106.230 with HTTP; Mon, 21 Oct 2013 14:02:36 -0700 (PDT) Date: Mon, 21 Oct 2013 14:02:36 -0700 Message-ID: From: Scott Whyte To: i2rs@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: Warren Kumari , Marcus Hines Subject: [i2rs] Bulk data collection use cases draft submitted 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, 21 Oct 2013 21:02:43 -0000 We've submitted a draft of what we believe to be interesting bulk data collection use cases for I2RS, and the concomitant functionality missing from existing solutions. Please read and comment. Normative and informative references are still to be added, and the draft is still rough around the edges. Data model discussions are deliberately left out, hopefully the scope is sufficient. And of course other interesting use cases would be welcome. Thanks for having a look. -Scott ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 11:11 AM Subject: New Version Notification for draft-swhyte-i2rs-data-collection-system-00.txt To: Scott Whyte , Marcus Hines , Warren Kumari A new version of I-D, draft-swhyte-i2rs-data-collection-system-00.txt has been successfully submitted by Scott Whyte and posted to the IETF repository. Filename: draft-swhyte-i2rs-data-collection-system Revision: 00 Title: Bulk Network Data Collection System Creation date: 2013-10-21 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-swhyte-i2rs-data-collection-system-00.txt Status: http://datatracker.ietf.org/doc/draft-swhyte-i2rs-data-collection-system Htmlized: http://tools.ietf.org/html/draft-swhyte-i2rs-data-collection-system-00 Abstract: Collecting large amounts of data from network infrastructure devices has never been very easy. Existing methods generate CPU and memory loads that may be unacceptable, the output varies across implementations and can be difficult to parse, and these methods are often difficult to scale. I2RS programmatic interfacing with the routing system may exacerbate this problem: state needs to be collected from nodes and fed to consumers participating in the control plane that may not be physically close to the nodes. This state includes not only control plane information, but elements of the data plane that have a direct impact on control plane behavior, like traffic engineering. This document outlines a set of use cases requiring a flexible framework to collect routing system data, and the features and functionality needed to make such a framework useful for these use cases. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From jmedved@cisco.com Tue Oct 22 10:03: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 B9EB511E81F7 for ; Tue, 22 Oct 2013 10:03:45 -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 mMBmpG5quLOT for ; Tue, 22 Oct 2013 10:03:41 -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 E3EA511E81BF for ; Tue, 22 Oct 2013 10:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3249; q=dns/txt; s=iport; t=1382461421; x=1383671021; h=from:to:cc:subject:date:message-id:mime-version; bh=+GZrEsExgMMwL8CcMduIbzZWh4nNSkhp+89C0MfEzNE=; b=RXhjDVrFpSk9DdxZajan3zrdLOqwt5XDdgFmmFCwMLG1bG8xhQknpAYY 8aC3kXVR56BQ5NuJUr+PTaJRqz0r0NydQJGvaZBkV1qlzmRmfqJRcMmrq LGacLYL1ja1HFOenjldihRKJSkQWltelD1k7mG5+N1iJurnApxFU6bVLR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMHALiuZlKtJXG8/2dsb2JhbABZgwc4VKweiWaIRoEmFm0HgicBBHkSAQweVicEDg2Hfg26SY8dMYMmgQoDmTiQWIMkgio X-IronPort-AV: E=Sophos;i="4.93,549,1378857600"; d="scan'208,217";a="275006112" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 22 Oct 2013 17:03:40 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9MH3eX5004692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Oct 2013 17:03:40 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 22 Oct 2013 12:03:40 -0500 From: "Jan Medved (jmedved)" To: "i2rs@ietf.org" Thread-Topic: Network Topology drafts Thread-Index: AQHOz0inagZUBULO+0O95Ip+F/W2MA== Date: Tue, 22 Oct 2013 17:03:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.27.7.164] Content-Type: multipart/alternative; boundary="_000_ACC8AB2D98C05F4E9FBDA092017D97FC1B046129xmbalnx10ciscoc_" MIME-Version: 1.0 Cc: Thomas Nadeau , "Alexander Clemm \(alex\)" , "vlopez@tid.es" , "Nitin Bahadur \(nitinb@juniper.net\)" , "Stefano Previdi \(sprevidi\)" , "Hariharan Ananthakrishnan \(hanantha@juniper.net\)" Subject: [i2rs] Network Topology drafts 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, 22 Oct 2013 17:03:45 -0000 --_000_ACC8AB2D98C05F4E9FBDA092017D97FC1B046129xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We updated the Network Topology drafts - use cases (http://datatracker.ietf= .org/doc/draft-amante-i2rs-topology-use-cases/) and the topology informatio= n model (http://datatracker.ietf.org/doc/draft-medved-i2rs-topology-im/). = Please have a look - comments & feedback would be greatly appreciated. Also, as agreed at the last WG meeting in Berlin, we'd like to open a discu= ssion whether network topology (as defined in the above use cases and the i= nformation model) is in the WG charter. The statement "The ability to extr= act information about topology from the network" in the WG charter says tha= t topology is in charter, but does not exactly say how. Thanks, Jan --_000_ACC8AB2D98C05F4E9FBDA092017D97FC1B046129xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
We updated the Network Topology drafts - use cases (http://datatracker.ietf.org/doc/draft-amante-i2rs= -topology-use-cases/= ) and the topology information model (http://datatracker.ietf.org/doc/draft-medved-i2rs-topology-im/= ).  Please have a l= ook - comments & feedback would be greatly appreciated.

Also, as agreed at = the last WG meeting in Berlin, we'd like to open a discussion whether netwo= rk topology (as defined in the above use cases and the information model) i= s in the WG charter.  The statement "The ability to extract info= rmation about topology from the network" in the WG charter says that t= opology is in charter, but does not exactly say how. 



Thanks,
Jan

--_000_ACC8AB2D98C05F4E9FBDA092017D97FC1B046129xmbalnx10ciscoc_-- From jmh@joelhalpern.com Mon Oct 28 03:38: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 4391E21F8319 for ; Mon, 28 Oct 2013 03:38:30 -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 suTDrmmTbMij for ; Mon, 28 Oct 2013 03:38:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 514F611E8147 for ; Mon, 28 Oct 2013 03:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 280371C0E10 for ; Mon, 28 Oct 2013 03:38:20 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A65071C05AA for ; Mon, 28 Oct 2013 03:38:19 -0700 (PDT) Message-ID: <526E3E98.2070606@joelhalpern.com> Date: Mon, 28 Oct 2013 06:38:16 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20131021203337.32574.23797.idtracker@ietfa.amsl.com> In-Reply-To: <20131021203337.32574.23797.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [i2rs] I-D Action: draft-rfernando-i2rs-protocol-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 10:38:30 -0000 This strikes me as an interesting and useful step in our effort. I am however confused by certain aspects of the document. 1) The document introduces new terminology in several regards. It seems to replace the I2RS agent with "server". It makes no reference to Information model, but makes several references to different kinds of data models. And it makes these changes without any comment or observation about the change. Can you please motivate the changes? 2) I think that OP-3 on providing a detailed workflow for bringing about new services is a MAJOR new tasking for the WG, and does noit follow from the charter. I understand that it is useful. But many things are useful that are outside our charter. Detail: 3) GEN-3 and TR-4 seem to contradict each other. GEN-3 says that the client always initiates the transport connection to the server, and TR-4 says either participant may initiate the transport connection. 4) Is TR-12 intended to require persistent connections between clients and servers? I had thought this was still under discussion, with many of us at least wanting to avoid requiring a transport connection during the lifetime of the state created by an I2RS client. It is possible that you only mean the keep-alives for as long as the participants want the connection alive. It is not obvious that this is worth the cost, since failure will be detected (if communication has failed and not recovered) when the participant next attempts to use the transport connection. 5) ID-7 implicitly creates the notion of shared identity. Is that really the right model? Or should we have multi-part identity, one part for attribution purposes, and another part for permission purposes? (With all of it authenticated of course.) 6) MessageExchangePattern-2 says that capabilities can be exchanged in a fire-and-forget fashion that is the same as that used for notifications. fire-and-forget leads this reader to think unreliable. And capability exchange messages would seem to need reliability. 7) MessageExchangePatter-3 seems to require an application level acknowledgment even if we use a reliable transport. This may be reasonable, but if so it needs more motivation. And an explanation as to why a reliable transport is not sufficient would be appreciated. It may be that this requirement is merely intended to say that every operation should have a success or failure reply. I would not call that an acknowledgment. 8) API-11 seems to be a subset of what is called for in the WG architecture document. Shouldn't we either agree to change the architecture or put the full requirement in the protocol requirements? Minor: Can we find another term than MEP? I realize that acronyms are overloaded, and some collisions are inevitable. But MEP and MIP are sufficiently pervasive and confusing on their own in the OAM space, I would really like to avoid talking about the MEP (Message Exchange Pattern) for performing manipulation of the MEP (Maintenance End Point.) Could we use Communication Pattern or COmmunication Exchange Pattern? On 10/21/13 4:33 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : I2RS Protocol Requirements > Author(s) : Rex Fernando > Jan Medved > Edward Crabbe > Keyur Patel > Filename : draft-rfernando-i2rs-protocol-requirements-00.txt > Pages : 21 > Date : 2013-10-21 > ... > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rfernando-i2rs-protocol-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00 ... From jmedved@cisco.com Mon Oct 28 22:21:48 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 7FA5921E80B7 for ; Mon, 28 Oct 2013 22:21:48 -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=[AWL=0.000, 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 GF4JKc1o1Q8j for ; Mon, 28 Oct 2013 22:21:43 -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 8226411E80F2 for ; Mon, 28 Oct 2013 22:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6255; q=dns/txt; s=iport; t=1383024103; x=1384233703; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=A7j3SfljE70oAI7lKQ6tEgxoauoklou8sSmQwbhCcyI=; b=bS5ps8uYy/hb1dvbPMT/nOw996hQuJuZdsY2FzEKSlZgoCUNFXxzZ2T8 M+qLscGegLRi6RNsYi7veV4ziuU9omF4Tc81Ej2/R/baf5pdnQqUcXGbN 8Al//jCS8a1J+KJ2mafx9faYxv4QtizJK8+ySLLKNAhBJ2FQ/FDWYnUts g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJFFb1KtJXG8/2dsb2JhbABQCYMHOFS+cYEtFnSCJQEBAQMBAQEBNzQQDQEIEgYKFDcLFw4CBAESCId5Bg24VI4FgRE4gx+BDQOZOZBZgyaCKg X-IronPort-AV: E=Sophos;i="4.93,590,1378857600"; d="scan'208";a="274851518" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2013 05:21:23 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9T5LNgN013560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 05:21:23 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 00:21:23 -0500 From: "Jan Medved (jmedved)" To: "Joel M. Halpern" , "i2rs@ietf.org" Thread-Topic: [i2rs] I-D Action: draft-rfernando-i2rs-protocol-requirements-00.txt Thread-Index: AQHO1Ga12NiRpsqookO4YSjbapCvaw== Date: Tue, 29 Oct 2013 05:21:22 +0000 Message-ID: In-Reply-To: <526E3E98.2070606@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.97.68] Content-Type: text/plain; charset="us-ascii" Content-ID: <05A538EE11C40840BCF8E2950C65904A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [i2rs] I-D Action: draft-rfernando-i2rs-protocol-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 05:21:48 -0000 Hi Joel, Thanks a lot for the review & comments. Please see inline. /Jan On 10/28/13 3:38 AM, "Joel M. Halpern" wrote: >This strikes me as an interesting and useful step in our effort. I am >however confused by certain aspects of the document. > >1) The document introduces new terminology in several regards. It seems >to replace the I2RS agent with "server". It makes no reference to >Information model, but makes several references to different kinds of >data models. And it makes these changes without any comment or >observation about the change. Can you please motivate the changes? This is an oversight. The draft's terminology will be aligned with the I2RS terminology > >2) I think that OP-3 on providing a detailed workflow for bringing about >new services is a MAJOR new tasking for the WG, and does noit follow >from the charter. I understand that it is useful. But many things are >useful that are outside our charter. I agree. We can leave it out of the draft for now. > >Detail: >3) GEN-3 and TR-4 seem to contradict each other. GEN-3 says that the >client always initiates the transport connection to the server, and TR-4 >says either participant may initiate the transport connection. Thanks for catching this. My preference would be a client connecting to the server (I2RS Agent), but there are examples of each behavior deployed in real world (client connecting to server: Netconf, server connecting to client: OpenFlow).=20 =20 > >4) Is TR-12 intended to require persistent connections between clients >and servers? =20 Yes. >I had thought this was still under discussion, with many >of us at least wanting to avoid requiring a transport connection during >the lifetime of the state created by an I2RS client. It is possible >that you only mean the keep-alives for as long as the participants want >the connection alive. We were requiring a persistent transport connection during the state's lifetime. I can understand the desire to ease this requirement, but this introduces complexity in other parts of the system. For example, we have to allow either the Agent or the client to initiate the transport connection (The Agent in case it wants to notify to the client about a state change). Also, the state cleanup/timeout procedures & policies will likely be more complex. I agree that this is something that we should discuss and consider all the pros/cons. > It is not obvious that this is worth the cost, >since failure will be detected (if communication has failed and not >recovered) when the participant next attempts to use the transport >connection. Failure detection w/o keepalives can take a long time. Detecting a failure early is critical in some applications. But, I think we could make keepalives optional. > >5) ID-7 implicitly creates the notion of shared identity. Is that >really the right model? We need to have something to support redundant clients implementation. Alternatively, we could have explicit state delegation (similar to PCEP) - but that's probably more complex. > Or should we have multi-part identity, one part >for attribution purposes, and another part for permission purposes? >(With all of it authenticated of course.) That's a viable model too. But how would it support redundant client implementation? > >6) MessageExchangePattern-2 says that capabilities can be exchanged in a >fire-and-forget fashion that is the same as that used for notifications. > fire-and-forget leads this reader to think unreliable. And capability >exchange messages would seem to need reliability. I think you're right. For capabilities exchange we need app-level reliability, which can only be achieved by request-response (where the reply is an ACK), not by fire-and-forget. > >7) MessageExchangePatter-3 seems to require an application level >acknowledgment even if we use a reliable transport. This may be >reasonable, but if so it needs more motivation. And an explanation as >to why a reliable transport is not sufficient would be appreciated. Ok. A reliably delivered request does not mean an operation has truly been performed - a positive 'ACK' response is needed. The document will be updated. > It may be that this requirement is merely intended to say that every >operation should have a success or failure reply. That's another way to describe it. > I would not call that an acknowledgment. > >8) API-11 seems to be a subset of what is called for in the WG >architecture document. Shouldn't we either agree to change the >architecture or put the full requirement in the protocol requirements? I'd rather put the full requirements in one place - the protocol requirement document. > >Minor: >Can we find another term than MEP? I realize that acronyms are >overloaded, and some collisions are inevitable. But MEP and MIP are >sufficiently pervasive and confusing on their own in the OAM space, I >would really like to avoid talking about the MEP (Message Exchange >Pattern) for performing manipulation of the MEP (Maintenance End Point.) > Could we use Communication Pattern or COmmunication Exchange Pattern? I like that, will be changed in the next rev of the document. > >On 10/21/13 4:33 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : I2RS Protocol Requirements >> Author(s) : Rex Fernando >> Jan Medved >> Edward Crabbe >> Keyur Patel >> Filename : draft-rfernando-i2rs-protocol-requirements-00.txt >> Pages : 21 >> Date : 2013-10-21 >> >... >> >> The IETF datatracker status page for this draft is: >>=20 >>https://datatracker.ietf.org/doc/draft-rfernando-i2rs-protocol-requiremen >>ts >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00 >... >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From lizhenbin@huawei.com Mon Oct 28 23:48: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 883FA11E80F5 for ; Mon, 28 Oct 2013 23:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, FRT_POSSIBLE=2.697, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 qZdeKIRvE+wT for ; Mon, 28 Oct 2013 23:48:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2EC21E8064 for ; Mon, 28 Oct 2013 23:48:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP05837; Tue, 29 Oct 2013 06:48:22 +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.3.158.1; Tue, 29 Oct 2013 06:48:03 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 06:48:19 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 14:48:10 +0800 From: Lizhenbin To: "i2rs@ietf.org" Thread-Topic: [I2RS] Soliciting feedback and comments on draft-zhang-i2rs-mbb-usecases-00 Thread-Index: Ac7UcJ0ew7fisyLJRuGE9Hu3uXnXBg== Date: Tue, 29 Oct 2013 06:48:10 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF78@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.223] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF78nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [i2rs] [I2RS] Soliciting feedback and comments on draft-zhang-i2rs-mbb-usecases-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, 29 Oct 2013 06:48:30 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF78nkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBoYXZlIHByb3Bvc2VkIHRoZSBkcmFmdCAiVXNlIENhc2VzIG9mIEkyUlMg aW4gTW9iaWxlIEJhY2toYXVsIE5ldHdvcmsiLiBZb3UgY29tbWVudHMgaW4gdGhlIG1haWxpbmcg bGlzdCBhcmUgYXBwcmVjaWF0ZWQuDQoNClRoZSBJUC9NUExTLWJhc2VkIHNvbHV0aW9uIGZvciB0 aGUgbW9iaWxlIGJhY2toYXVsIG5ldHdvcmsgaW52b2x2ZXMgYSBsb3Qgb2YgZmVhdHVyZXMgaW5j bHVkaW5nIEJHUC9NUExTL0wzVlBOL0wyVlBOL09BTSwgZXRjLiBJbiBhZGR0aW9uLCB0aGUgc29s dXRpb25zIGFyZSBhbHdheXMgYXJlIGRlcGxveWVkIHRocm91Z2ggbmV0d29yayBtYW5hZ2VtZW50 IHN5c3RlbS4gV2UgcHJvcG9zZSB0aGUgdXNlIGNhc2VzIG9mIG1vYmlsZSBiYWNraGF1bHQgbmV0 d29yayB0byBkZWZpbmUgdGhlIHBvc3NpYmxlIHJlcXVpcmVtZW50cyB3aGljaCBzaG91bGQgYmUg ZGVmaW5lZCBhbmQgZW5oYW5jZWQgaW4gSTJSUyBiZXNpZGVzIHRoZSBleGlzdGluZyBUb3BvbG9n eSwgQkdQLCBSSUIgd29yay4gTW9yZW92ZXIsIHRocm91Z2ggdGhlIHVzZSBjYXNlcyBpdCBjYW4g YmUgc2VlbiB0aGF0IGhvdyB0aGUgSTJSUyBpbnRlcmZhY2UgY2FuIGNvbXBvc2UgYSBjb21wbGV0 ZSBuZXR3b3JrIHNvbHV0aW9ucyBmb3IgYWxsIHBvc3NzaWJsZSBzZXJ2aWNlcy4NCg0KDQoNCg0K DQpSZWdhcmRzLA0KDQpSb2Jpbg0KDQoNCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF78nkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

We have proposed the draft "Use Cases of I2RS in Mobile Backhaul Ne= twork". You comments in the mailing list are appreciated.

The IP/MPLS-based solution for the mobile backhaul network involves a lo= t of features including BGP/MPLS/L3VPN/L2VPN/OAM, etc. In addtion, the solu= tions are always are deployed through network management system. We propose= the use cases of mobile backhault network to define the possible requirements which should be defined and en= hanced in I2RS besides the existing Topology, BGP, RIB work. Moreover, thro= ugh the use cases it can be seen that how the I2RS interface can compose a = complete network solutions for all posssible services.

 

 

Regards,

Robin


 

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF78nkgeml506mbxchi_-- From lizhenbin@huawei.com Tue Oct 29 00: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 78EA911E8188 for ; Tue, 29 Oct 2013 00:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=1.984, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 NlNF5RgXj-Hs for ; Tue, 29 Oct 2013 00:03:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29C3E11E8220 for ; Tue, 29 Oct 2013 00:03:02 -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.7-GA FastPath queued) with ESMTP id AXI02576; Tue, 29 Oct 2013 07:03:00 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 07:02:40 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 07:02:59 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.252]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 15:02:53 +0800 From: Lizhenbin To: "i2rs@ietf.org" Thread-Topic: [I2RS] Soliciting feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-00/draft-huang-i2rs-mpls-te-usecases-00 Thread-Index: AQHO1HQGuxe27Ugvhku1jJ6e+ng5Rw== Date: Tue, 29 Oct 2013 07:02:52 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF9C@nkgeml506-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.223] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF9Cnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [i2rs] [I2RS] Soliciting feedback and comments on draft-chen-i2rs-mpls-ldp-usecases-00/draft-huang-i2rs-mpls-te-usecases-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, 29 Oct 2013 07:03:09 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF9Cnkgeml506mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpXZSBoYXZlIHByb3Bvc2VkIHRoZSB0d28gZHJhZnQgdG8gZGVzY3JpYmUgdGhl IHVzZSBjYXNlcyBvZiBJMlJTIGludGVyZmFjZSB0byBNUExTIExEUCBhbmQgTVBMUyBURS4gIFlv dSBjb21tZW50cyBpbiB0aGUgbWFpbGluZyBsaXN0IGFyZSBhcHByZWNpYXRlZC4NCg0KQXMgY2Fu IGJlIHNlZW4gaW4gdGhlIGRyYWZ0IGRyYWZ0LXpoYW5nLWkycnMtbWJiLXVzZWNhc2VzLTAwPGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctaTJycy1tYmItdXNlY2Fz ZXMvPiwgaXQgaXMgbmVjZXNzYXJ5IHRvIGRlZmluZSBtb3JlIGluZm9ybWF0aW9uIG1vZGVscyB0 byBzdXBwb3J0IGEgY29tcGxlbWVudCBuZXR3b3JrIHNvbHV0aW9uIGZvciBhbGwgcG9zc2libGUg c2VydmljZXMuIEJhc2VkIG9uIHRoaXMsIGl0IGlzIG5lY2Vzc2FyeSB0byBkZWZpbmUgdGhlIEky UlMgaW50ZXJmYWNlIHRvIE1QTFMvVlBOIGJlc2lkZXMgdGhlIGV4aXN0aW5nIHVzZWNhc2VzIG9y IGluZm9ybWF0aW9uIG1vZGVscyBvbiBUb3BvbG9neSwgUklCIG9yIEJHUCBwcm90b2NvbHMuIElu IHRoZSB0d28gZHJhZnRzLCB3ZSBwcm9wb3NlIHRoZSB1c2UgY2FzZXMgb2YgSTJSUyB1c2UgY2Fz ZXMgdG8gTVBMUyBMRFAgYW5kIE1QTFMgVEUgdG8gZGVzY3JpYmUgaG93IHRoZSBJMlJTIHByb2dy YW1tYWJsZSBpbnRlcmZhY2UgdG8gc2F0aXNmeSB0aGUgcG9zc2libGUgc2VydmljZSByZXF1aXJl bWVudHMuDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0KUm9iaW4NCg== --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF9Cnkgeml506mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

We have proposed the two draft to describe the use cases of I2RS interfa= ce to MPLS LDP and MPLS TE.  You comments in the mailing list are= appreciated.

As can be seen in the draft draft-zhang-i2rs-mbb-usecases-00, it is necessary to define more inform= ation models to support a complement network solution for all possible serv= ices. Based on this, it is necessary to define the I2RS interface to MPLS/V= PN besides the existing usecases or information models on Topology, RIB or BGP protocols. In the two drafts= , we propose the use cases of I2RS use cases to MPLS LDP and MPLS TE&n= bsp;to describe how the I2RS programmable interface to satisfy the possible=  service requirements.

 

 

Regards,

Robin

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D081CEF9Cnkgeml506mbxchi_-- From jmh@joelhalpern.com Tue Oct 29 00:48: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 A52B511E81BF for ; Tue, 29 Oct 2013 00:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 nvOSm5Hw0YCq for ; Tue, 29 Oct 2013 00:48:42 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 554D821F9D70 for ; Tue, 29 Oct 2013 00:48:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 1BEE91C0546; Tue, 29 Oct 2013 00:48:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 317841C03B5; Tue, 29 Oct 2013 00:48:40 -0700 (PDT) Message-ID: <526F6857.8030205@joelhalpern.com> Date: Tue, 29 Oct 2013 03:48:39 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Jan Medved (jmedved)" 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] I-D Action: draft-rfernando-i2rs-protocol-requirements-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 07:48:47 -0000 Thank you for the detailed reply. Looks like there are some items worth discussing, but no major disconnects. In particular, I agree that we should put all the requirements together, and this document seems a good place to do so. Yours, Joel On 10/29/13 1:21 AM, Jan Medved (jmedved) wrote: > Hi Joel, > > Thanks a lot for the review & comments. Please see inline. > > > /Jan > > On 10/28/13 3:38 AM, "Joel M. Halpern" wrote: > >> This strikes me as an interesting and useful step in our effort. I am >> however confused by certain aspects of the document. >> >> 1) The document introduces new terminology in several regards. It seems >> to replace the I2RS agent with "server". It makes no reference to >> Information model, but makes several references to different kinds of >> data models. And it makes these changes without any comment or >> observation about the change. Can you please motivate the changes? > > This is an oversight. The draft's terminology will be aligned with the > I2RS terminology > >> >> 2) I think that OP-3 on providing a detailed workflow for bringing about >> new services is a MAJOR new tasking for the WG, and does noit follow >>from the charter. I understand that it is useful. But many things are >> useful that are outside our charter. > > I agree. We can leave it out of the draft for now. > >> >> Detail: >> 3) GEN-3 and TR-4 seem to contradict each other. GEN-3 says that the >> client always initiates the transport connection to the server, and TR-4 >> says either participant may initiate the transport connection. > > Thanks for catching this. My preference would be a client connecting to > the server (I2RS Agent), but there are examples of each behavior deployed > in real world (client connecting to server: Netconf, server connecting to > client: OpenFlow). > >> >> 4) Is TR-12 intended to require persistent connections between clients >> and servers? > > Yes. > >> I had thought this was still under discussion, with many >> of us at least wanting to avoid requiring a transport connection during >> the lifetime of the state created by an I2RS client. It is possible >> that you only mean the keep-alives for as long as the participants want >> the connection alive. > > We were requiring a persistent transport connection during the state's > lifetime. I can understand the desire to ease this requirement, but this > introduces complexity in other parts of the system. For example, we have > to allow either the Agent or the client to initiate the transport > connection (The Agent in case it wants to notify to the client about a > state change). Also, the state cleanup/timeout procedures & policies will > likely be more complex. > > I agree that this is something that we should discuss and consider all the > pros/cons. > >> It is not obvious that this is worth the cost, >> since failure will be detected (if communication has failed and not >> recovered) when the participant next attempts to use the transport >> connection. > > Failure detection w/o keepalives can take a long time. Detecting a failure > early is critical in some applications. But, I think we could make > keepalives optional. > >> >> 5) ID-7 implicitly creates the notion of shared identity. Is that >> really the right model? > > We need to have something to support redundant clients implementation. > Alternatively, we could have explicit state delegation (similar to PCEP) - > but that's probably more complex. > >> Or should we have multi-part identity, one part >> for attribution purposes, and another part for permission purposes? >> (With all of it authenticated of course.) > > That's a viable model too. But how would it support redundant client > implementation? > >> >> 6) MessageExchangePattern-2 says that capabilities can be exchanged in a >> fire-and-forget fashion that is the same as that used for notifications. >> fire-and-forget leads this reader to think unreliable. And capability >> exchange messages would seem to need reliability. > > I think you're right. For capabilities exchange we need app-level > reliability, which can only be achieved by request-response (where the > reply is an ACK), not by fire-and-forget. >> >> 7) MessageExchangePatter-3 seems to require an application level >> acknowledgment even if we use a reliable transport. This may be >> reasonable, but if so it needs more motivation. And an explanation as >> to why a reliable transport is not sufficient would be appreciated. > > Ok. A reliably delivered request does not mean an operation has truly been > performed - a positive 'ACK' response is needed. The document will be > updated. > >> It may be that this requirement is merely intended to say that every >> operation should have a success or failure reply. > > That's another way to describe it. > >> I would not call that an acknowledgment. >> >> 8) API-11 seems to be a subset of what is called for in the WG >> architecture document. Shouldn't we either agree to change the >> architecture or put the full requirement in the protocol requirements? > > I'd rather put the full requirements in one place - the protocol > requirement document. > >> >> Minor: >> Can we find another term than MEP? I realize that acronyms are >> overloaded, and some collisions are inevitable. But MEP and MIP are >> sufficiently pervasive and confusing on their own in the OAM space, I >> would really like to avoid talking about the MEP (Message Exchange >> Pattern) for performing manipulation of the MEP (Maintenance End Point.) >> Could we use Communication Pattern or COmmunication Exchange Pattern? > > I like that, will be changed in the next rev of the document. > >> >> On 10/21/13 4:33 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : I2RS Protocol Requirements >>> Author(s) : Rex Fernando >>> Jan Medved >>> Edward Crabbe >>> Keyur Patel >>> Filename : draft-rfernando-i2rs-protocol-requirements-00.txt >>> Pages : 21 >>> Date : 2013-10-21 >>> >> ... >>> >>> The IETF datatracker status page for this draft is: >>> >>> https://datatracker.ietf.org/doc/draft-rfernando-i2rs-protocol-requiremen >>> ts >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-rfernando-i2rs-protocol-requirements-00 >> ... >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From jixiaofeng@huawei.com Tue Oct 29 01:45: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 3F0CA11E8151 for ; Tue, 29 Oct 2013 01:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 LMfl4riZH3yO for ; Tue, 29 Oct 2013 01:45:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 430E411E8146 for ; Tue, 29 Oct 2013 01:45:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP17079; Tue, 29 Oct 2013 08:45:12 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 08:44:51 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 08:45:10 +0000 Received: from NKGEML505-MBS.china.huawei.com ([169.254.2.105]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 16:44:58 +0800 From: "Jixiaofeng (Steven)" To: Zhuangshunwan , "i2rs@ietf.org" Thread-Topic: [i2rs] Soliciting WG feedback and comments on draft-ji-i2rs-usecases-ccne-service-00.txt Thread-Index: Ac7ORWCniGMad4FKSDOnEbbExfV16wACH1oAAY0ZLVA= Date: Tue, 29 Oct 2013 08:44:58 +0000 Message-ID: <966D0EE2A4DEE1468C80E49065FEDBD12F9E9255@nkgeml505-mbs.china.huawei.com> References: <000d01cece4f$4bb1ba00$e3152e00$@com> In-Reply-To: <000d01cece4f$4bb1ba00$e3152e00$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.71.94] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yangang , Huangtieying , Lizhenbin Subject: [i2rs] =?utf-8?b?562U5aSNOiAgU29saWNpdGluZyBXRyBmZWVkYmFjayBhbmQg?= =?utf-8?q?comments_on_draft-ji-i2rs-usecases-ccne-service-00=2Etxt?= 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, 29 Oct 2013 08:45:18 -0000 RGVhciBhbGwsDQoNCldlIGhhZCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sLyBkcmFmdC1qaS1pMnJzLXVzZWNhc2VzLWNjbmUtc2VydmljZS0wMC4gWW91 ciBmZWVkYmFjayBhbmQgY29tbWVudHMgb24gdGhlIGkycnMgbWFpbGluZyBsaXN0IGFyZSBhcHBy ZWNpYXRlZC4gV2Ugd2lsbCBiZSBsb29raW5nIHRvIHVwZGF0ZSB0aGUgZHJhZnQuDQoNClBTOg0K DQpROg0KV2hhdCBjb3N0IG9mIENDTkU/DQpBOg0KQ2VudHJhbCBjb250cm9sIG90aGVyIE5FIGJ5 IENDTkUNCjEgIFVuaWZpZWQgcGxhbm5pbmcgYW5kIGRlcGxveW1lbnQgcGF0aC4NCjIgIFRydWUg b2YgdGhlIHdob2xlIG5ldHdvcmsgdHJhZmZpYyBlbmdpbmVlcmluZywgaW5jbHVkaW5nIHRyYWZm aWMgb3B0aW1pemF0aW9uLCB0cmFmZmljIHNjaGVkdWxpbmcuDQozICBOZXR3b3JrLWxldmVsIGZh dWx0IHNpbXVsYXRpb24gYW5kIGFuYWx5c2lzDQo0ICBOZXR3b3JrLWxldmVsIHNlY3VyaXR5IHBv bGljeSBkZXBsb3ltZW50LCBuZXR3b3JrLWxldmVsIFFvUyBwb2xpY3kgZGVwbG95bWVudCwgZXRj Lg0KDQrnuqrmmZPls7AgIO+8iEpJIFhpYW9mZW5n77yJDQoNCkh1YXdlaSBUZWNobm9sb2dpZXMg Q28uLCBMdGQuDQpQaG9uZTogKzg2LTAxMC0gNjA2MTM2NzgNCkZheDogKzg2LTAxMC02MDYxMzY3 OA0KTW9iaWxlOiArODYtMTM2ODMyNjQzMjkNCuS4reWbvShDaGluYSkt5YyX5LqsKEJlaWppbmcp Lea1t+a3gOWMuuS4reWFs+adkeWMl+a4hei3rzE1NuWPt+WunuWIm+enkeaKgOekuuiMg+WbreWN juS4uuWFrOWPuFExNQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y bWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5DQpmb3IgdGhlIHBlcnNv biBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4NCmFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgb3IgZGlzc2VtaW5hdGlvbikgDQpieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVk IHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBp biBlcnJvciwgcGxlYXNlIA0Kbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hk u7bkuro6IFpodWFuZ3NodW53YW4gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOaciDIx5pelIDE5 OjE5DQrmlLbku7bkuro6IGkycnNAaWV0Zi5vcmcNCuaKhOmAgTogSHVhbmd0aWV5aW5nOyBKaXhp YW9mZW5nIChTdGV2ZW4pOyBMaXpoZW5iaW47IFlhbmdhbmcNCuS4u+mimDogW2kycnNdIFNvbGlj aXRpbmcgV0cgZmVlZGJhY2sgYW5kIGNvbW1lbnRzIG9uIGRyYWZ0LWppLWkycnMtdXNlY2FzZXMt Y2NuZS1zZXJ2aWNlLTAwLnR4dA0KDQpIaSwNCg0KV2UgaGFkIHN1Ym1pdHRlZCBhIG5ldyBkcmFm dDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvIGRyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2Nu ZS1zZXJ2aWNlLTAwLiBZb3VyIGZlZWRiYWNrIGFuZCBjb21tZW50cyBvbiB0aGUgaTJycyBtYWls aW5nIGxpc3QgYXJlIGFwcHJlY2lhdGVkLiBXZSB3aWxsIGJlIGxvb2tpbmcgdG8gdXBkYXRlIHRo ZSBkcmFmdC4NCg0KDQpUaGFua3MsDQpTaHVud2FuIFpodWFuZw0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOaciDIx5pelIDE4 OjA3DQrmlLbku7bkuro6IFNodW53YW4gWmh1YW5nOyBYaWFvZmVuZyBKaTsgVGlleWluZyBIdWFu Zw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWppLWkycnMtdXNl Y2FzZXMtY2NuZS1zZXJ2aWNlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1qaS1pMnJzLXVzZWNhc2VzLWNjbmUtc2VydmljZS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgWGlhb2ZlbmcgSmkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1qaS1pMnJzLXVzZWNhc2VzLWNjbmUtc2Vydmlj ZQ0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgSTJSUyBVc2UgQ2FzZXMgZm9yIENvbnRyb2wgb2Yg Rm9yd2FyZGluZyBQYXRoIGJ5IENlbnRyYWwgQ29udHJvbCBOZXR3b3JrIEVsZW1lbnQgKENDTkUp DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0yMQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpOdW1iZXIgb2YgcGFnZXM6IDExDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2NuZS1zZXJ2aWNl LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2NuZS1zZXJ2aWNlDQpIdG1saXplZDogICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppLWkycnMtdXNlY2FzZXMtY2NuZS1zZXJ2 aWNlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBXaXRoIHRoZSBkZXZlbG9wbWVudCBvZiBuZXR3b3Jr IHRlY2hub2xvZ2llcywgbW9yZSBhbmQgbW9yZQ0KICAgYXBwbGljYXRpb25zIG5lZWQgdG8gaGF2 ZSBhIGNlbnRyYWwgY29udHJvbCBwb2ludCBmb3IgdGhlIG5ldHdvcmsNCiAgIGVsZW1lbnRzIGlu IG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHN1Y2ggY2VudHJhbCBjb250cm9sIHBvaW50IGlz DQogICBhIGNlbnRyYWwgY29udHJvbCBuZXR3b3JrIGVsZW1lbnQgKENDTkUpLiAgQ0NORSBjb250 cm9scyB0aGUgbmV0d29yaw0KICAgZWxlbWVudHMgaW4gaXRzIGFkbWluaXN0cmF0aXZlIGRvbWFp biwgdGhlIHR5cGUgb2YgQ0NORSBjYW4gYmUgUlINCiAgIFJvdXRlciwgUENFIFNlcnZlciwgb3Ig YSBmZWRlcmF0aW9uIG9mIFJSIFJvdXRlciBhbmQgUENFIFNlcnZlciwgZXRjLg0KICAgQ0NORSBp cyBkZXZlbG9wZWQgZnJvbSB0aGUgdHJhZGl0aW9uYWwgbmV0d29yayBlbGVtZW50LCB3aGljaCBw bHVzDQogICBzb21lIEkyUlMgaW50ZXJmYWNlcywgY2FuIHByb3ZpZGUgYm90aCB0cmFkaXRpb25h bCBuZXR3b3JrIHNlcnZpY2VzDQogICBhbmQgSTJSUyBzZXJ2aWNlcy4NCg0KICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgcmVxdWlyZW1lbnQgYW5kIHVzZSBjYXNlcyBmb3Igd2hpY2ggSTJSUyBj YW4NCiAgIGJlIHVzZWQgZm9yIENDTkUgZGV2aWNlLiAgVGhlIHVzZSBjYXNlcyBkZXNjcmliZWQg aW4gdGhpcyBkb2N1bWVudA0KICAgZW5jb21wYXNzOiBDb250cm9sIElQIE5ldHdvcmsgYnkgUlIg Um91dGVyLCBDb250cm9sIE1QTFMgVEUgTmV0d29yaw0KICAgYnkgUENFIFNlcnZlci4gIFRoZSBn b2FsIGlzIHRvIGluZm9ybSB0aGUgY29tbXVuaXR5J3MgdW5kZXJzdGFuZGluZw0KICAgb2Ygd2hl cmUgdGhlIEkyUlMgQ0NORSBleHRlbnNpb25zIGZpdCB3aXRoaW4gdGhlIG92ZXJhbGwgSTJSUw0K ICAgYXJjaGl0ZWN0dXJlLiAgSXQgaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIGJhc2lzIGZvciB0 aGUgc29sdXRpb25zDQogICBkcmFmdCBkZXNjcmliaW5nIHRoZSBzZXQgb2YgaW50ZXJmYWNlcyBm b3IgdGhlIENDTkUgZGV2aWNlLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From jixiaofeng@huawei.com Tue Oct 29 02:37: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 40DEF11E81BC for ; Tue, 29 Oct 2013 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.847 X-Spam-Level: X-Spam-Status: No, score=-4.847 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 IHJIR3gEwSM2 for ; Tue, 29 Oct 2013 02:36:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2047B11E8151 for ; Tue, 29 Oct 2013 02:36:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP22498; Tue, 29 Oct 2013 09:36:39 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 09:36:21 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Oct 2013 09:36:37 +0000 Received: from NKGEML505-MBS.china.huawei.com ([169.254.2.105]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 17:36:26 +0800 From: "Jixiaofeng (Steven)" To: Yangang , "i2rs@ietf.org" Thread-Topic: Soliciting WG feedback and comments on draft-jxf-i2rs-im-architecture-00 Thread-Index: AQHOzgg1pWVwZuPDwEGEQswkEvxVeJoLbChw Date: Tue, 29 Oct 2013 09:36:26 +0000 Message-ID: <966D0EE2A4DEE1468C80E49065FEDBD12F9E92A7@nkgeml505-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.71.94] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Lizhenbin , Linda Dunbar Subject: [i2rs] =?utf-8?b?562U5aSNOiBTb2xpY2l0aW5nIFdHIGZlZWRiYWNrIGFuZCBj?= =?utf-8?q?omments_on_draft-jxf-i2rs-im-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, 29 Oct 2013 09:37:01 -0000 RGVhciBhbGwsDQoNCldlIGhhZCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sLyBkcmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUtMDEuIFlvdXIgZmVl ZGJhY2sgYW5kIGNvbW1lbnRzIG9uIHRoZSBpMnJzIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0 ZWQuIFdlIHdpbGwgYmUgbG9va2luZyB0byB1cGRhdGUgdGhlIGRyYWZ0Lg0KDQpQUzoNCg0KQ29z dCBvZiBJTSBhcmNoaXRlY3R1cmUNCjEpIEd1aWRhbmNlIG1vZGVsLWRyaXZlbiBkZXZlbG9wbWVu dC4NCjIpIEVhY2ggbW9kdWxlIGNhbiBmaW5kIHRoZWlyIHBsYWNlIGFuZCByZWxhdGlvbiBtb2R1 bGUuDQozKSBNYW5hZ2VtZW50IHJlbGF0aW9uDQo0KSBCZW5lZmljaWFsIGN1dHRpbmcgdGhlIHN5 c3RlbQ0KNSkgLi4uDQoNClEmQSAgDQoNClhpYW9mZW5nIEppIHdpdGggIEVkd2FyZCBDcmFiYmUN Cg0KUToNCldoaWxlIHRoZSB0b3BpYyBpcyBkZWZpbml0ZWx5IGludGVyZXN0aW5nLCB0aGlzIGRy YWZ0IGlzIGEgbGl0dGxlIHRvIHNrZWxldGFsIHRvIGJlIGFibGUgdG8gZGV0ZXJtaW5lIHdoYXQg eW91J2xsIGFjdHVhbGx5IGJlIHByZXNlbnRpbmcgb24uICBDYW4geW91IHByb3ZpZGUgc29tZSBk ZXRhaWxzPw0KSW4gZ2VuZXJhbCwgd2Ugd2FudCBkb2N1bWVudHMgYmVpbmcgcHJlc2VudGVkIHRv IHRoZSB3ZyB0byAxKSBoYXZlIHN1ZmZpY2llbnQgbWF0ZXJpYWwgdG8gd2FycmFudCBpbml0aWFs IHN1Ym1pc3Npb24gYW5kIDIpIGhhdmUgYmVlbiBwb3N0ZWQgb24gdGhlIGxpc3QgYW5kIHByZWZl cmFibHkgdG8gaGF2ZSBoYWQgc29tZSBjb252ZXJzYXRpb24gYXJvdW5kIHRoZW0uDQoNCkE6DQpB ZnRlciBkZWZpbmluZyB0aGUgdXNlIGNhc2VzLCB3ZSB3aWxsIGdvIG9uIHRvIGRlZmluZSB0aGUg aW5mb3JtYXRpb24gbW9kZWxzLiBCZWZvcmUgdGhlIHdvcmssIHdlIGhvcGUgdGhlIGluZm9ybWF0 aW9uIG1vZGVsIGFyY2hpdGVjdHVyZSBjYW4gYmUgZGVmaW5lZCB0byBndWlkZSB1cyB0byBkZWZp bmUgaW5mb3JtYXRpb24gbW9kZWxzIHN0ZXAgYnkgc3RlcC4NClRoaXMgZG9jdW1lbnQncyBnb2Fs IHdhbnQgcHJvdmlkZSBhIGFyY2hpdGVjdHVyZSBmb3IgYWxsIGkycnMgaW5mb3JtYXRpb24gbW9k ZWwuICBJbiBjb250cm9sbGVyIGFuZCByb3V0ZXIgYWxyZWFkeSB1c2UgdGhlIGFyY2hpdGVjdHVy ZSAsIGp1c3Qgb25lIGFyY2hpdGVjdHVyZS4NCkJlY2F1c2Ugd2UgY29uc2lkZXIgdGhlcmUgYXJl IG1hbnkgY29tbW9uIHJlcXVpcmVzIGZvciBpMnJzIGFuZCB0aGVyZSBhcmUgbWFueSByZWxhdGlv bnMgYmV0d2VlbiBtb2RlbCBwYWNrYWdlcy4gLCAgZm9yIGV4YW1wbGUgdG9wb2xvZ3kgbW9kZWws IGludmVudG9yeSBtb2RlbChpbnRlcmZhY2Ugb2JqZWN0LCB0dW5uZWwgb2JqZWN0LCBldGMuKS4N CkZvciBtYW5hZ2VyIHRoZXNlIG1vZGVsIHBhY2thZ2VzIGFuZCByZWxhdGlvbnMsIHdlIHByb3Zp ZGUgYSBhcmNoaXRlY3R1cmUgIGFuZCBndWlkZSB0byBkZWZpbmUgaW5mb3JtYXRpb24gbW9kZWxz IHN0ZXAgYnkgc3RlcC4NCldlIGhhdmUgYWxyZWFkeSBkaXNjdXNzIHdpdGggWWFvaHVpIEppbihq aW55QHNpdHUuZWR1LmNuKSwgIGJ1dCB1c2UgQ2hpbmVzZSB0ZXh0IGluIGVtYWlsLiAgSW4gZnV0 dXJlLCB3ZSB3aWxsIGJlIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGUgSUVURi4NCg0KDQpYaWFvZmVu ZyBKaSB3aXRoICBYdWFuIEx1byBhbmQgWWFvaHVpIEppbg0KDQpROg0KZmlsZSBtYW5hZ2VtZW50 5LiOc29mdHdhcmUgaW5zdGFsbCZ1cGRhdGXlvojlpJrml7blgJnmmK/kuIDoh7TnmoTvvIzlsKTl hbblnKjln7rkuo5saW51eOWGheaguOeahOaTjeS9nOezu+e7n+S4re+8jOi/memHjOaYr+WmguS9 leWIh+WIhuWIsOS4pOWxgueahO+8nw0KSW4gbW9zdCBjYXNlcywgZmlsZSBtYW5hZ2VtZW50IGFu ZCBzb2Z0d2FyZSBpbnN0YWxsICYgdXBkYXRlIGlzIHRoZSBzYW1lLCBlc3BlY2lhbGx5IGluIHRo ZSBsaW51eCBrZXJuZWwtYmFzZWQgb3BlcmF0aW5nIHN5c3RlbSwgd2h5IGFzc2lnbiB0byB0d28t bGF5ZXI/DQpBOg0KSnhm77yaDQrmlofku7bns7vnu5/lkozova/ku7blronoo4Xmm7TmlrDvvIwg 5oiR5Lus6K6k5Li65piv5Lik5Liq5bGC77yMIOaWh+S7tueuoeeQhuebuOW9k+S6juaTjeS9nOez u+e7nzXlpKfnrqHnkIbkuK3nmoTkuIDkuKrvvIwg6ICM6L2v5Lu2566h55CG5piv5pON5L2c57O7 57uf5LmL5LiK55qE5LiA5Liq5bqU55So44CCDQpGaWxlIG1hbmFnZW1lbnQgYW5kIHNvZnR3YXJl IGluc3RhbGwmdXBkYXRlLCB3ZSBjb25zaWRlciB0aGF0IHRoZSB0d28gbGF5ZXJzLCBmaWxlIG1h bmFnZW1lbnQgaXMgb25lIG9mIDUgbWFuYWdlbWVudCBmdW5jdGlvbnMgaW4gb3BlcmF0aW5nIHN5 c3RlbSwgYnV0IHNvZnR3YXJlIG1hbmFnZW1lbnQgaXMgYW4gYXBwbGljYXRpb24gb24gdGhlIG9w ZXJhdGluZyBzeXN0ZW0uDQoNClE6IA0KbGF5ZXLkuI5sYXllcuS5i+mXtOacieS+nei1luWFs+ez u+WQl++8n+WmguaenOacieS+nei1luWFs+ezu++8jOaIkeS4jeWkqueQhuino+S4uuS7gOS5iHJl c291cmNl5Lya5L6d6LWW5LqOcG9saWN577yfDQpJcyB0aGVyZSBkZXBlbmRlbnQgcmVsYXRpb25z aGlwIGJldHdlZW4gbGF5ZXIgYW5kIHRoZSBsYXllcj8gSWYgYSBkZXBlbmRlbnQgcmVsYXRpb25z aGlwIGV4aXN0cywgSSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB3aHkgdGhlIHJlc291cmNlIHdp bGwgZGVwZW5kIG9uIHRoZSBwb2xpY3k/DQoNCkE6DQpKeGbvvJoNCuS4iuWxgmxheWVy5L6d6LWW 5LiL5bGCbGF5ZXLvvIwg5LiN6IO95Y+N5ZCR77yMIA0K6L+Z6YeMcG9saWN55ZKMcmVzb3VyY2Xn moTlhbPns7vmmK/ov5nmoLfnmoTvvIwgDQrmr5TlpoLmiJHku6zliLblrprkuIDkuKrigJzpu5Hl kI3ljZXnrZbnlaXigJ3vvIzlroPmmK/lhajnvZHopoHpg6jnvbLnmoTvvIwg5LiN5ZKM5p+Q5Y+w 5YW35L2T6K6+5aSH55u45YWz44CC5oiR5Lus6K+055qEUG9saWN55piv5oyH6L+Z56eN5LiN5L6d 6LWW5LqO6LWE5rqQ55qEUG9saWN544CCDQrogIxQb2xpY3nlkoxyZXNvdXJjZeeahOe7k+WQiO+8 jCDmmK/lnKjkuJrliqHlsYLlrozmiJDnmoTjgIINCg0KMSkgWWVz77yMdGhlcmUgaXMgZGVwZW5k ZW50IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGxheWVyIGFuZCB0aGUgbGF5ZXIgLiBUaGUgdXBwZXIg bGF5ZXIgZGVwZW5kcyBvbiB0aGUgdW5kZXJseWluZyBsYXllciwgY2FuIG5vdCBiZSByZXZlcnNl ZCwNCjIpIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBwb2xpY3kgYW5kIHJlc291cmNlOg0KRm9y IGV4YW1wbGUsIHdlIGRldmVsb3BlZCBhICJibGFja2xpc3QgcG9saWN5IiwgaXQgaXMgdGhlIHdo b2xlIG5ldHdvcmsgdG8gYmUgZGVwbG95ZWQsIGFuZCBpdCBkb2VzIG5vdCBkZXBlbmQgc3BlY2lm aWMgZGV2aWNlLiBTbyB0aGUgUG9saWN5IGlzIG5vdCBkZXBlbmRlbnQgb24gdGhlIHJlc291cmNl cy4NClRoZSBQb2xpY3kgYW5kIHJlc291cmNlIGNvbWJpbmF0aW9uIGlzIGRvbmUgaW4gdGhlIG5l dHdvcmsgc2VydmljZSBsYXllci4NCg0KUToNCuWvueS6jm5ldHdvcmsgY29udGFpbmVyIGxheWVy 5LiN5aSq55CG6Kej77yM57uZ5Ye655qE5Yeg5Liq5L6L5a2QTDNWUE4vTDJWUE4vVkxBTu+8jOS4 quS6uuiupOS4uumDveWxnuS6jm5ldHdvcmsgc2VydmljZeOAgiANCkkgZG8gbm90IHVuZGVyc3Rh bmQgbmV0d29yayBjb250YWluZXIgbGF5ZXIsICBnaXZlbiBhIGZldyBleGFtcGxlcyBvZiBMM1ZQ Ti9MMlZQTi9WTEFOLCAgcGVyc29uYWxseSBJIHRoaW5rIHRoYXQgYWxsIGJlbG9uZyB0byBuZXR3 b3JrIHNlcnZpY2UgbGF5ZXIuDQoNCkE6CQ0KSnhm77yaDQrlhbfkvZPlu7rmqKHml7blsLHkvJrl j5HnjrDvvIwgIOWmguaenOayoeacieS4gOS4qlZQTklE77yMIOiuuOWkmuaooeWei+agueacrOaX oOazleaehOW7uuS4i+WOu+S6hu+8jOWboOS4uuimgeS+nei1lui/meS4qklE77yMIA0K5omA5Lul 5pyA5bqV5bGC5pyJ5LiA5Liq572R57uc5a655Zmo77yM5a6D6Iez5bCR5o+Q5L6b572R57uc44CB 5a2Q572R44CB6Jma5ouf572R57uc55qESUTjgIHlkI3np7DnrYnlhajlsYDkv6Hmga/vvIwg5YW2 5LuW5Lia5Yqh5L+h5oGv5b2T54S26L+Y5piv5Lia5Yqh5bGC44CCDQrlvojml6nnmoTmqKHlnovm sqHmnInov5nkuKpJRO+8jCDmmK/lm6DkuLrnvZHnu5zov5jmsqHmnInnp4HmnInpmpTnprvvvIhW UE7ov5jmsqHlh7rnjrDvvInvvIwg55uu5YmN5a+86Ie05aSn6YeP5Lia55WM5oiQ5Z6L55qE5qih 5Z6L6ZyA6KaB6YeN5p6E44CCDQrpooTop4HliLDov5nkuKrlj5jljJbvvIwg5omA5Lul5oiR5Lus 5aKe5Yqg5LqG6L+Z5Liq5bGC44CCDQpGb3Igc3BlY2lmaWMgbW9kZWxpbmcgd2l0aG91dCBhIFZQ TklELCBtYW55IG1vZGVscyBzaW1wbHkgY2FuIG5vdCBidWlsZCBhbnltb3JlLCBiZWNhdXNlIHRo ZXkgcmVseSBvbiB0aGUgSUQsIHNvIHRoZSBib3R0b20gbGF5ZXIgbXVzdCBoYXZlIGEgbmV0d29y ayBjb250YWluZXIuDQpJdCBwcm92aWRlcyBhdHRyaWJ1dGUoIElELCBuYW1lLCBldGMuIGdsb2Jh bCBpbmZvcm1hdGlvbikgIG9mICBjb250YWluZXIgIG9iamVjdCAobmV0d29yaywgc3VibmV0cywg dmlydHVhbCBuZXR3b3JrKS4NCg0KRWFybHkgbW9kZWxzIGRvIG5vdCBoYXZlIHRoaXMgSUQsIGJl Y2F1c2UgdGhlIG5ldHdvcmsgaGFzIG5vIHByaXZhdGUgaXNvbGF0aW9uIChWUE4gbm90IGFwcGVh cmVkKSwgdGhleSByZXN1bHRlZCBpbiBzdWJzdGFudGlhbCBuZWVkIGZvciByZWNvbnN0cnVjdGlv biBtb2xkaW5nIGluZHVzdHJ5LiANCkZvcmVzZWVuIHRoaXMgY2hhbmdlLCBzbyB3ZSBhZGRlZCB0 aGlzIGxheWVyLg0KDQrnuqrmmZPls7AgIO+8iEpJIFhpYW9mZW5n77yJDQoNCkh1YXdlaSBUZWNo bm9sb2dpZXMgQ28uLCBMdGQuDQpQaG9uZTogKzg2LTAxMC0gNjA2MTM2NzgNCkZheDogKzg2LTAx MC02MDYxMzY3OA0KTW9iaWxlOiArODYtMTM2ODMyNjQzMjkNCuS4reWbvShDaGluYSkt5YyX5Lqs KEJlaWppbmcpLea1t+a3gOWMuuS4reWFs+adkeWMl+a4hei3rzE1NuWPt+WunuWIm+enkeaKgOek uuiMg+WbreWNjuS4uuWFrOWPuFExNQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCBpcyBpbnRlbmRlZCBvbmx5DQpmb3Ig dGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1 c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4NCmFueSB3YXkgKGluY2x1 ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgDQpieSBwZXJzb25zIG90aGVyIHRoYW4gdGhl IGludGVuZGVkIHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlz IGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIA0Kbm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3Ig ZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KDQotLS0tLemCruS7tuWOn+S7ti0t LS0tDQrlj5Hku7bkuro6IFlhbmdhbmcgDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQxMOaciDIx5pel IDEwOjUwDQrmlLbku7bkuro6IGkycnNAaWV0Zi5vcmcNCuaKhOmAgTogWWFuZ2FuZzsgSml4aWFv ZmVuZyAoU3RldmVuKTsgTGl6aGVuYmluDQrkuLvpopg6IFNvbGljaXRpbmcgV0cgZmVlZGJhY2sg YW5kIGNvbW1lbnRzIG9uIGRyYWZ0LWp4Zi1pMnJzLWltLWFyY2hpdGVjdHVyZS0wMA0KDQpIaToN Cg0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgYSBuZXcgZHJhZnQ6IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWp4Zi1pMnJzLWltLWFyY2hpdGVjdHVyZS0wMCwgWW91ciBmZWVkYmFjayBh bmQgY29tbWVudHMgb24gdGhlIHJ0Z3dnIG1haWxpbmcgbGlzdCBhcmUgYXBwcmVjaWF0ZWQuDQoN CldoZW4gd2UgY29kZSBzb21lIHByb2dyYW0sIHNvbWUgcnVsZXMgd2lsbCBoZWxwIHVzIHRvIGRv IHNvbWUgZGVzaWduLCBsaWtlICJoaWdobHkgY29oZXNpdmUgYW5kIGxvdyBjb3VwbGluZyIsIGJ1 dCBpbiBkZXNpZ24gb2YgaW5mb3JtYXRpb24gbW9kZWwsIG5vcnRoYm91bmQgaW50ZXJmYWNlcywg dGhlcmUgYXJlIHNvbWUgZGlmZmljdWx0IHRvIGp1ZGdlIGlmIHRoaXMgZGVzaWduIGlzIGdvb2Qg b3Igbm90LCB3ZSB0cnkgdG8gcHJvdmlkZSBhIGtpbmQgb2YgdGhpcyBpbmZvcm1hdGlvbiBtb2Rl bCBzdHJ1Y3R1cmUgb2YgdGhlIG5ldHdvcmsgZGV2aWNlLCB0cnkgdG8gZ2V0IHNvbWUgcm9sZXMg dG8gZGVzaWduIHRoZSBpbmZvcm1hdGlvbiBtb2RlbC4NCg0KVGhhbmtzLA0KUmFodWwuWWFuDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAx M+W5tDEw5pyIMTjml6UgMTU6MTUNCuaUtuS7tuS6ujogVGluYSBUU09VOyBKaXhpYW9mZW5nIChT dGV2ZW4pOyBUaW5hIFRTT1U7IFlhbmdhbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUtMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWp4Zi1pMnJzLWltLWFyY2hpdGVjdHVyZS0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2ZlbmcgSmkgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1qeGYtaTJycy1pbS1h cmNoaXRlY3R1cmUNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEFuIGluZm9ybWF0aW9uIG1vZGVs IGF0Y2hpdGVjdHVyZSBvZiBuZXR3b3JrIGRldmljZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMTAt MTgNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWp4Zi1pMnJzLWltLWFyY2hpdGVjdHVyZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qeGYtaTJycy1pbS1hcmNoaXRlY3R1cmUN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtanhmLWky cnMtaW0tYXJjaGl0ZWN0dXJlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBDdXJyZW50bHksIG5ldHdv cmsgZXF1aXBtZW50IGFscmVhZHkgaGFzIHNvbWUgTm9ydGhib3VuZCBJbnRlcmZhY2VzLA0KICAg c3VjaCBhcyBTTk1QLCBORVRDT05GLCBUTDE7IGFuZCBzb21lIGxhbmd1YWdlcyBhcmUgYWxzbyBw cm92aWRlZCB0bw0KICAgZGVzY3JpYmUgdGhlIGRhdGEgbW9kZWwsIHN1Y2ggYXMgTUlCLCBTQ0hF TUEgYW5kIGV2ZW4gWUFORy4gIFdoaWxlDQogICB0aWxsIG5vdywgdGhlcmUgaXMgbm90IGEgY2xl YXIgZGVmaW5lZCBpbmZvcm1hdGlvbiBtb2RlbC4gIEluIE5FVENPTkYNCiAgIGRvbWFpbiwgc29t ZSBzdGFuZGFyZHMgYXJlIGJlaW5nIGRlZmluZWQuICBJbiBvcmRlciB0byByZWR1Y2UgdGhlDQog ICBjb3N0IG9mIE5NUyBpbnRlZ3JhdGlvbiBpbiBjdXN0b21lciBzaWRlLCBhIGNsZWFyIGRlZmlu ZWQgaW5mb3JtYXRpb24NCiAgIG1vZGVsIGlzIG5lY2Vzc2FyeSwganVzdCBsaWtlIHRoZSBTSUQg aW4gVE1GLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From swhyte@google.com Wed Oct 30 17:41:03 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 C6A3011E81D9 for ; Wed, 30 Oct 2013 17:41:03 -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.311, BAYES_00=-2.599, 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 nOikiQJoXxr4 for ; Wed, 30 Oct 2013 17:41:03 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2102B11E8142 for ; Wed, 30 Oct 2013 17:41:02 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id r10so1715161pdi.18 for ; Wed, 30 Oct 2013 17:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=j+cmIIBR1K+6qhQva8xTIRkH21J1BhoT+9wYzUlwZ3g=; b=ILhYhx32gbQOQP4AvMTFspv2Z/rbqkEcT6yf8EMvGoMDDItBEDoZ/o8QBrsszOjjGt km7Kd2Ka17z0zDlASkDuzWNSeU9ca9yMjgzAgWeyZcdjCwvISuJF9JhvNl1/IZmqolsj xJdLHcDlB2ZvFq+T3R8ENLyzUaX/5g2f0RiKl0cBcQY9QKAhCcu+DzY+Ndki0I4Q3fB0 eqW4CfK7Dezjx2Dp2z/AlF3JAFlxlcV9OidrTbqW69RQlx8YgODwO9qaHfig1T2hkbJK SWwQVLeZ9kXjYvjpZmSd88R13shIjmV3uwTwaWmDO/5S7s2aErvp9607R9p9Cpq/AS/x FfGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=j+cmIIBR1K+6qhQva8xTIRkH21J1BhoT+9wYzUlwZ3g=; b=NpS/6yC/utfSciWRel8l1ocROmu7LgIRCb8yIAtdjETi7Eflq3jLfaV2vuTd3wnIA8 zzoCi7QjgtOJq2eAMlEOxgNxclK2RfJ0MabwxTe78UENn/IMQNMKfokH0Phub35PsT7s btvQgHb91yyONU4+ZojIwJJhOBjaO+gBH5DkiuZSbzubBqdTYcZlnf7FGZVksQvPj1vm nAaaHecRIfrX98O/P+iUXl/TArXI1O+Ce8QPVKEim5YjFnZ94EkuclbEGD4drJN2rlg+ IaLfiq3SRXjEIym8QjbrYvD9zQQ4Yf9WMuCJ8l0aGEwjucQbEvUf4XUunnNqZk8Gu1kN zBWw== X-Gm-Message-State: ALoCoQkBZDjwNXU5Ko9mOBt12+SYVVD//8DxuJjzL5VWAbip47/1/8vlatNjCkq0kRVFZVlC1ZAlVLHvA/Bso0kmkT0m6+jIWOgMJiBFZ8pyghNvDR7iIOhiT6wb/27drVRX0cP8E7VsGOPf4ynXanWmGD5etomuDLAQlTouvpSAM0P6DNbGxqvcr+NXZSOP6NgCIgNq02i4 X-Received: by 10.68.170.163 with SMTP id an3mr408435pbc.91.1383180062644; Wed, 30 Oct 2013 17:41:02 -0700 (PDT) Received: from localhost ([2620:0:1000:3202:baac:6fff:fe7c:df72]) by mx.google.com with ESMTPSA id rp8sm624174pbc.25.2013.10.30.17.41.00 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 30 Oct 2013 17:41:01 -0700 (PDT) Date: Wed, 30 Oct 2013 17:40:59 -0700 From: Scott Whyte To: "Jan Medved (jmedved)" Message-ID: <20131031004059.GA2984@google.com> 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) Cc: "i2rs@ietf.org" , Thomas Nadeau , "Alexander Clemm \(alex\)" , "vlopez@tid.es" , "Nitin Bahadur \(nitinb@juniper.net\)" , "Stefano Previdi \(sprevidi\)" , "Hariharan Ananthakrishnan \(hanantha@juniper.net\)" Subject: Re: [i2rs] Network Topology drafts 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, 31 Oct 2013 00:41:04 -0000 On Tue, Oct 22, 2013 at 05:03:39PM +0000, Jan Medved (jmedved) wrote: > We updated the Network Topology drafts - use cases > (http://datatracker.ietf.org/doc/draft-amante-i2rs-topology-use-cases/) > and the topology information model > (http://datatracker.ietf.org/doc/draft-medved-i2rs-topology-im/). > Please have a look - comments & feedback would be greatly > appreciated. > > Also, as agreed at the last WG meeting in Berlin, we'd like to open > a discussion whether network topology (as defined in the above use > cases and the information model) is in the WG charter. The > statement "The ability to extract information about topology from > the network" in the WG charter says that topology is in charter, but > does not exactly say how. Jan, WRT to the use-case draft: If section 2 would explicitly define Topology that would help. The draft abstract seems to define topology as "routing, forwarding and policy information". Section 1 seems to treat Topology as graph information only, separate from inventory and stastics. Section 3 seems to flip that and go back to the abstract's definition. WRT the IM draft: There seems to be a differentiation made between topology and topology model. If I read it correctly, a topology model consists of graph information (what I think of as topology), and other baggage. If I got that right, this seems similar to my mental model of ISIS: the topology consists of information describing how the nodes are connected, and IP information is essentially baggage that makes it possible to route IP packets. Personally I think defining a topology model that uses different graphs and corresponding baggage to provide useful abstractions is in scope. I'd like it if you could tighten up the language though. -Scott > > > > Thanks, Jan > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From jmedved@cisco.com Thu Oct 31 23:54: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 38D7611E8256 for ; Thu, 31 Oct 2013 23:54:12 -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 0LH2xjfE8pNc for ; Thu, 31 Oct 2013 23:54:07 -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 C77B411E8246 for ; Thu, 31 Oct 2013 23:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2414; q=dns/txt; s=iport; t=1383288847; x=1384498447; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ul1jKuay6a8hKPHW3VPlqvsLiB0T+9fzXo8/3iTEvvI=; b=jJUk7s6T3BWxV1TohuGmbCI5gF0BkrITNq8XW/HyUm88frTtFNzvCE+o K/CvTWd8rm6ZCzQ44SaKNlDrIuPaZ407LjumAC7sI8MtMS1LwH5wH+9ja SuZD1lcazJQTg5gdzf4Wkt8y2o4dR797ZNYfkSORjj2iVUdwDC/gInY9e M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACpPc1KtJV2Y/2dsb2JhbABZgwc4VL9hgSIWdIIlAQEBBAEBATc0CxIBCA4KChQ3CyUCBA4FCId/DbxsjycxB4MggQ4DmTmQWoMmgio X-IronPort-AV: E=Sophos;i="4.93,614,1378857600"; d="scan'208";a="279339233" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2013 06:54:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA16s5XW008404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 06:54:06 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.143]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 1 Nov 2013 01:54:05 -0500 From: "Jan Medved (jmedved)" To: Scott Whyte Thread-Topic: [i2rs] Network Topology drafts Thread-Index: AQHOz0inagZUBULO+0O95Ip+F/W2MJoOWPyAgAGFOIA= Date: Fri, 1 Nov 2013 06:54:04 +0000 Message-ID: In-Reply-To: <20131031004059.GA2984@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.27.7.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "i2rs@ietf.org" , Thomas Nadeau , "Alexander Clemm \(alex\)" , "vlopez@tid.es" , "Nitin Bahadur \(nitinb@juniper.net\)" , "Stefano Previdi \(sprevidi\)" , "Hariharan Ananthakrishnan \(hanantha@juniper.net\)" Subject: Re: [i2rs] Network Topology drafts 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, 01 Nov 2013 06:54:12 -0000 Hi Scott, Thanks a lot for the comments - please see inline. On 10/30/13 5:40 PM, "Scott Whyte" wrote: >On Tue, Oct 22, 2013 at 05:03:39PM +0000, Jan Medved (jmedved) wrote: >> We updated the Network Topology drafts - use cases >> (http://datatracker.ietf.org/doc/draft-amante-i2rs-topology-use-cases/) >> and the topology information model >> (http://datatracker.ietf.org/doc/draft-medved-i2rs-topology-im/). >> Please have a look - comments & feedback would be greatly >> appreciated. >>=20 >> Also, as agreed at the last WG meeting in Berlin, we'd like to open >> a discussion whether network topology (as defined in the above use >> cases and the information model) is in the WG charter. The >> statement "The ability to extract information about topology from >> the network" in the WG charter says that topology is in charter, but >> does not exactly say how. > >Jan, > >WRT to the use-case draft: >If section 2 would explicitly define Topology that would help. Ok. >The draft abstract seems to define topology as "routing, forwarding and >policy information". Section 1 seems to treat Topology as graph >information only, separate from inventory and stastics. Section 3 >seems to flip that and go back to the abstract's definition. Good point. We'll align better Section 1 with the the rest of the draft. > >WRT the IM draft: >There seems to be a differentiation made between topology and topology >model. If I read it correctly, a topology model consists of graph >information (what I think of as topology), and other baggage. If I >got that right, this seems similar to my mental model of ISIS: the >topology consists of information describing how the nodes are >connected, and IP information is essentially baggage that makes it >possible to route IP packets. Correct. Also, the graph seems to be common for all kinds of topologies (L2, L3, service, VPN, etc), while the baggage is specific to a given typology type. > >Personally I think defining a topology model that uses different >graphs and corresponding baggage to provide useful abstractions is in >scope. I'd like it if you could tighten up the language though. Ok. > >-Scott Thanks,=20 Jan >>=20 > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >