From nobody Sun Mar 1 17:39:48 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4561A1E0F for ; Sun, 1 Mar 2015 17:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPbViE_9f3SB for ; Sun, 1 Mar 2015 17:39:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A719D1A19E4 for ; Sun, 1 Mar 2015 17:39:44 -0800 (PST) Received: from [172.29.37.143] (66.129.241.11) by CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 2 Mar 2015 01:39:25 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Mar 2015 20:39:13 -0500 Message-ID: To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: CY1PR09CA0024.namprd09.prod.outlook.com (25.160.223.34) To CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB732; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:CO2PR05MB732; X-Forefront-PRVS: 0503FF9A3E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(54014002)(164054003)(92566002)(122386002)(23726002)(42186005)(50226001)(77096005)(83716003)(66066001)(86362001)(46102003)(47776003)(87976001)(46406003)(40100003)(33656002)(82746002)(57306001)(110136001)(97756001)(77156002)(62966003)(36756003)(50466002)(50986999)(229853001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB732; H:[172.29.37.143]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB732; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2015 01:39:25.9125 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB732 Archived-At: Cc: Hares Susan Subject: [Idr] IETF-92 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 01:39:46 -0000 Folks, IDR will meet at IETF-92 on Tuesday, March 24, from 3:20 to 5:20. = Please forward any IDR agenda items you might have to Sue and me. The = deadline is March 9 (a week from Monday) by 10:00 U.S. Eastern Time. = Priority will be given to those who get their requests in by the = deadline, though if agenda space permits it we will consider requests = gotten in before March 16 at 10:00 U.S. Eastern Time. If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation = this time. If you have requested to present the same work at multiple = WGs, please note this so that we can coordinate as needed. If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting, though again, earlier is better. If we don't have your slides = by the deadline, you may lose your slot. Please number your slides for = the benefit of remote attendees, and if you plan to use any fancy builds = or transitions you must arrange this with us in advance -- otherwise you = should assume your slides may be converted to PDF and presented from the = PDF. Finally, if you request an agenda slot, please do so by replying to this = message, making sure to include both Sue and me in the To: or Cc: and = don't change the subject line. Please include the name of the person who = will be presenting and give an estimate for how much time you think = you'll need (including Q/A). Thanks, --John & Sue From nobody Sun Mar 1 22:06:34 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575AD1A1A28; Sun, 1 Mar 2015 22:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX9vuC1MBd8J; Sun, 1 Mar 2015 22:06:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE091A1A2E; Sun, 1 Mar 2015 22:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302060616.20481.58893.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 22:06:16 -0800 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 06:06:33 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ From nobody Sun Mar 1 22:06:35 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7A04B1A1A2D; Sun, 1 Mar 2015 22:06:33 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575AD1A1A28; Sun, 1 Mar 2015 22:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX9vuC1MBd8J; Sun, 1 Mar 2015 22:06:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE091A1A2E; Sun, 1 Mar 2015 22:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302060616.20481.58893.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 22:06:16 -0800 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 06:06:33 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ From nobody Mon Mar 2 00:13:23 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788EB1A6F01; Mon, 2 Mar 2015 00:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CjjwQTR9CAD; Mon, 2 Mar 2015 00:13:21 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 391C01A6EF2; Mon, 2 Mar 2015 00:13:17 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 2 Mar 2015 03:13:12 -0500 Message-ID: <002a01d054c0$bac9b660$305d2320$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01D05496.D1F55C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBUwLLWrjJuU7tMS0GBJTZzzWrjxw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: IETF Secretariat Subject: [Idr] Interim on 3/2/2015 at 10:00 - 11:30 ET is cancelled X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 08:13:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002B_01D05496.D1F55C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR Interim on 3/2/2105 at 10:00am - 11:00am is cancelled. Sue Hares ------=_NextPart_000_002B_01D05496.D1F55C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR = Interim on 3/2/2105 at 10:00am – 11:00am is cancelled. =

 

Sue Hares

------=_NextPart_000_002B_01D05496.D1F55C10-- From nobody Mon Mar 2 02:55:21 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4DD1A86F7 for ; Mon, 2 Mar 2015 02:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO8wC_Y1uNhT for ; Mon, 2 Mar 2015 02:55:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BF7951A86FC for ; Mon, 2 Mar 2015 02:54:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: References: <050701d03405$cd9836d0$68c8a470$@ndzh.com> <54EB86C1.5060408@cisco.com> In-Reply-To: <54EB86C1.5060408@cisco.com> Date: Mon, 2 Mar 2015 05:54:49 -0500 Message-ID: <013601d054d7$4e5f3ab0$eb1db010$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01D054AD.6589F600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJtp6va5v9ej5Bykj+yKjPQJ5I1JAFkITM2m8M9xXA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'John G. Scudder'" Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-sla-exchange-04 (2/19/2015 rto 2/5/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 10:55:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0137_01D054AD.6589F600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The document draft-ietf-idr-sla-exchange-04 has passed WG LC. The WG chairs welcome any additional comments on this draft and any additional implementation reports. Sue Hares On 1/19/15 8:34 AM, Susan Hares wrote: This is to begin a 2 week Wg LC for draft-ietf-idr-sla-exchange. Please comment on the usefulness of the draft in deployments and on the technical pros/cons of the draft. In your comments please include: "support" or "no support" indicate. Authors should indicate if any IPR exists for this draft, and the number of implementations that exist. If this draft does not have 2 implementations, it will go to a state of WG LC completed, awaiting 2 implementations. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/ Sue Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0137_01D054AD.6589F600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document = draft-ietf-idr-sla-exchange-04 has passed WG LC.   The WG = chairs welcome any additional comments on this draft and any additional = implementation reports.

 

Sue Hares =

 


On 1/19/15 = 8:34 AM, Susan Hares wrote:

 

This is to = begin a 2 week Wg LC for draft-ietf-idr-sla-exchange.   Please = comment on the usefulness of the draft in deployments and on the = technical pros/cons of the draft.  In your comments please = include:  “support” or “no support” = indicate.  Authors should indicate if any IPR exists for this = draft, and the number of implementations that exist.

 

If this = draft does not have 2 implementations, it will go to a state of WG LC = completed, awaiting 2 implementations.

 

The draft = can be found at:

 

htt= p://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/<= /p>

 

Sue = Hares 




__________________=
_____________________________
Idr mailing =
list
Idr@ietf.org
https://www.ietf.org/m=
ailman/listinfo/idr

 

------=_NextPart_000_0137_01D054AD.6589F600-- From nobody Mon Mar 2 03:00:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C311A0362 for ; Mon, 2 Mar 2015 03:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJJY5sTi4WrF for ; Mon, 2 Mar 2015 03:00:17 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC771A8700 for ; Mon, 2 Mar 2015 03:00:06 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 2 Mar 2015 05:59:59 -0500 Message-ID: <014501d054d8$072552a0$156ff7e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01D054AE.1E505C10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBU0qB4pF85xGC/Q8GzWeBkQsIizg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 11:00:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0146_01D054AE.1E505C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit draft-ietf-idr-ix-bgp-route-server has passed WG LC with a strong consensus of operators and will be forwarded to the IESG. Sue Hares ------=_NextPart_000_0146_01D054AE.1E505C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-idr-ix-bgp-route-server has passed WG LC = with a strong consensus of operators and will be forwarded to the IESG. =

 

Sue Hares

------=_NextPart_000_0146_01D054AE.1E505C10-- From nobody Mon Mar 2 03:33:20 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2231A871D for ; Mon, 2 Mar 2015 03:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.156 X-Spam-Level: X-Spam-Status: No, score=-97.156 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR--prnPhhmY for ; Mon, 2 Mar 2015 03:33:18 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC581A870D for ; Mon, 2 Mar 2015 03:33:18 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 2 Mar 2015 06:33:10 -0500 Message-ID: <018c01d054dc$a9f1d180$fdd57480$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBU3GU7nG4SfkKqRSOb+IAh+zA0bg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015) - Intent to Adopt Call (3/2 - 3/6) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 11:33:19 -0000 The IDR Chairs intend to adopt draft-hao-idr-flowspec-evpn-03 as a IDR WG document on 3/6/2015. Any concerns regarding the WG adoption of this draft should sent to this mail list or send to the idr chairs by 3/5/2015. Sue Hares From nobody Mon Mar 2 08:45:01 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5C3B41A19EF; Sun, 1 Mar 2015 21:56:57 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400781A0E10 for ; Sun, 1 Mar 2015 21:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMIAlXLoNnE6 for ; Sun, 1 Mar 2015 21:56:56 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [IPv6:2607:f170:8000:1500::de]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA711A0AF8 for ; Sun, 1 Mar 2015 21:56:56 -0800 (PST) Received: from smtp01.icann.org ([192.0.33.81]:48275 helo=smtp1.lax.icann.org) by gamay.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YSJLa-0004xk-1k for draft-ietf-idr-error-handling.all@tools.ietf.org; Mon, 02 Mar 2015 00:56:54 -0500 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t225uf2t013042; Mon, 2 Mar 2015 05:56:41 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 791B2C202BA; Mon, 2 Mar 2015 05:56:41 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150226210111.16401.21034.idtracker@ietfa.amsl.com> References: <20150226210111.16401.21034.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #810453 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 02 Mar 2015 05:56:41 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-idr-error-handling.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000) X-SA-Exim-Scanned: Yes (on gamay.tools.ietf.org) Resent-To: draft-ietf-idr-error-handling.all@ietf.org Resent-Message-Id: <20150302055656.1BA711A0AF8@ietfa.amsl.com> Resent-Date: Sun, 1 Mar 2015 21:56:56 -0800 (PST) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 08:44:59 -0800 Cc: draft-ietf-idr-error-handling.all@tools.ietf.org, iesg@ietf.org Subject: [Idr] [IANA #810453] Last Call: (Revised Error Handling for BGP UPDATE Messages) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 05:56:57 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-idr-error-handling-18, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Amanda Baber IANA Request Specialist ICANN (END IANA LAST CALL COMMENTS) On Thu Feb 26 21:01:39 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the Inter-Domain Routing WG (idr) to > consider the following document: > - 'Revised Error Handling for BGP UPDATE Messages' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > According to the base BGP specification, a BGP speaker that receives > an UPDATE message containing a malformed attribute is required to > reset the session over which the offending attribute was received. > This behavior is undesirable, because a session reset would impact > not only routes with the offending attribute, but also other, valid > routes exchanged over the session. This document partially revises > the error handling for UPDATE messages and provides guidelines for > the authors of documents defining new attributes. Finally, it > revises the error handling procedures for a number of existing > attributes. > > This document updates error handling for RFCs 1997, 4271, 4360, 4456, > 4760, 5543, 5701 and 6368. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Mon Mar 2 10:44:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336181A8888 for ; Mon, 2 Mar 2015 10:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXC0xbZGROiB for ; Mon, 2 Mar 2015 10:44:17 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAD901A700B for ; Mon, 2 Mar 2015 10:44:17 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 2 Mar 2015 13:44:11 -0500 Message-ID: <007601d05518$e031f1d0$a095d570$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01D054EE.F75C37F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBVGK1cK2YRo323SIKHBVZVfHIH0w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 18:44:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01D054EE.F75C37F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for draft-ymbk-idr-rs-bfd-00.txt Please review and comment on this draft and indicate why this is useful to add to the BGP mechanism. In your comments please include "support" or "no support" for the WG Adoption of this draft. Sue Hares and John Scudder ------=_NextPart_000_0077_01D054EE.F75C37F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for draft-ymbk-idr-rs-bfd-00.txt =

 

Please review and comment on this draft and indicate = why this is useful to add to the BGP mechanism.   In your = comments please include “support” or “no = support” for the WG Adoption of this draft.

 

Sue Hares = and John Scudder

------=_NextPart_000_0077_01D054EE.F75C37F0-- From nobody Wed Mar 4 05:55:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186D91A032D for ; Wed, 4 Mar 2015 05:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quqni0ROq-6R for ; Wed, 4 Mar 2015 05:55:12 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C114C1A0222 for ; Wed, 4 Mar 2015 05:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7183; q=dns/txt; s=iport; t=1425477312; x=1426686912; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=URnIOmr+RnOmQShvUdGVSuRVZwmCcy/bMFuIxHRk4o4=; b=FGf+dAiFSK7qSp3Eq+fOKBXG65z7/cqitpZBD7WK+qS2iK84cAFmm0B+ Py81dTnkZVJ5kXY7dv5Ji7lzlR0lYVZkJP2OpWfDqo6hPl8Dl7xEaoNkr DrNGlUM0/YR7vxJWJsGFjtPOdtViucvL7EFmXunUnfu0q/mpQUy3j20IE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpBQBRDvdU/xbLJq1QCoNUWoMLvggBCYVxAoFzAQEBAQEBfIQPAQEBBAEBASBLChEcAwECCgMTCwICCQMCAQIBFSYCCBMGAgEBBQuIGw28dpoXAQEBAQEBBAEBAQEBAQEbixKEDAYKAgEtERgGgmKBQwWTYoVpgVOFHox3I4NvPTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.09,687,1418083200"; d="scan'208,217";a="364792242" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 04 Mar 2015 13:55:10 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t24Dt99D028403 for ; Wed, 4 Mar 2015 13:55:09 GMT Message-ID: <54F70EBD.8060007@cisco.com> Date: Wed, 04 Mar 2015 14:55:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: idr@ietf.org References: <54F70B64.4010608@cisco.com> In-Reply-To: <54F70B64.4010608@cisco.com> X-Forwarded-Message-Id: <54F70B64.4010608@cisco.com> Content-Type: multipart/alternative; boundary="------------010109010203040208020802" Archived-At: Subject: [Idr] Fwd: Some background on the L3VPN Service YANG Model work X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 13:55:14 -0000 This is a multi-part message in MIME format. --------------010109010203040208020802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI. Sorry for the potential duplicates. Regards, Benoit -------- Forwarded Message -------- Subject: Some background on the L3VPN Service YANG Model work Date: Wed, 04 Mar 2015 14:40:52 +0100 From: Benoit Claise To: l3sm@ietf.org Dear all, Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM) Three months ago, Adrian Farrel and I set up a design team to create a L3VPN _service _YANG model. It needs to be clearly understood that this L3VPN _service _model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers. Therefore, that design team was composed of operators only. That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list. Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model. See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are. IMO, the advantage/driver for this work is explained in the charter proposal: The deliverable from this working group will provide information to evaluate the set of YANG models that have already been developed or are under development, and will help identify any missing models or details. The deliverable can be viewed as driving requirements for protocol configuration model so that the service parameters can be mapped into inputs used by the protocol models. Don't hesitate to forward this email. List address: l3sm@ietf.org Archive: http://www.ietf.org/mail-archive/web/l3sm/ To subscribe: https://www.ietf.org/mailman/listinfo/l3sm Regards, Benoit --------------010109010203040208020802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI. Sorry for the potential duplicates.

Regards, Benoit


-------- Forwarded Message --------
Subject: Some background on the L3VPN Service YANG Model work
Date: Wed, 04 Mar 2015 14:40:52 +0100
From: Benoit Claise <bclaise@cisco.com>
To: l3sm@ietf.org


Dear all,

Let me give you some background on this new piece of work: The Layer Three Virtual Private Network Service Model (L3SM)

Three months ago, Adrian Farrel and I set up a design team to create a L3VPN service YANG model.
It needs to be clearly understood that this L3VPN service model is not an L3VPN configuration model. That is, it does not provide details for configuring network elements or protocols. Instead it contains the characteristics of the service, as discussed between the operators and their customers.  Therefore, that design team was composed of operators only.

That design team created a first draft: http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/
Now that the draft has been posted, the work and discussion should continue in a public forum, i.e. this l3sm@ietf.org mailing list.

Next step? we're busy trying to create a new short-lived WG, focusing solely on this L3VPN service YANG model.
See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/
If this WG is created (This proposal is on the IESG telechat this week for external review approval), this would be a good test for the IETF community: are we ready to standardize a first service YANG model? Personally, I believe we are.
IMO, the advantage/driver for this work is explained in the charter proposal:
The deliverable from this working group will provide information to evaluate the
set of YANG models that have already been developed or are under development,
and will help identify any missing models or details.  The deliverable can be
viewed as driving requirements for protocol configuration model so that the
service parameters can be mapped into inputs used by the protocol models.
Don't hesitate to forward this email.
    List address: l3sm@ietf.org
    Archive: http://www.ietf.org/mail-archive/web/l3sm/
    To subscribe: https://www.ietf.org/mailman/listinfo/l3sm

Regards, Benoit





--------------010109010203040208020802-- From nobody Wed Mar 4 06:46:40 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C41A1F73 for ; Wed, 4 Mar 2015 06:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trneZX1A2qPK for ; Wed, 4 Mar 2015 06:46:37 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 979741A1BE7 for ; Wed, 4 Mar 2015 06:46:37 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Benoit Claise'" , References: <54F70B64.4010608@cisco.com> <54F70EBD.8060007@cisco.com> In-Reply-To: <54F70EBD.8060007@cisco.com> Date: Wed, 4 Mar 2015 09:46:33 -0500 Message-ID: <052b01d0568a$024b0190$06e104b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_052C_01D05660.19760B00" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFTDL69ZbbHprq1RUN2ME2I7AvFHwMloeytne3NE1A= X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Fwd: Some background on the L3VPN Service YANG Model work X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 14:46:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_052C_01D05660.19760B00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benoit: =20 Will there be interaction between the layers of the modules (L3VPN = service), and BGP module?=20 =20 Sue=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Wednesday, March 04, 2015 8:55 AM To: idr@ietf.org Subject: [Idr] Fwd: Some background on the L3VPN Service YANG Model work =20 FYI. Sorry for the potential duplicates. Regards, Benoit=20 -------- Forwarded Message --------=20 Subject:=20 Some background on the L3VPN Service YANG Model work Date:=20 Wed, 04 Mar 2015 14:40:52 +0100 From:=20 Benoit Claise To:=20 l3sm@ietf.org Dear all, Let me give you some background on this new piece of work: The Layer = Three Virtual Private Network Service Model (L3SM) Three months ago, Adrian Farrel and I set up a design team to create a = L3VPN service YANG model. It needs to be clearly understood that this L3VPN service model is not = an L3VPN configuration model. That is, it does not provide details for = configuring network elements or protocols. Instead it contains the = characteristics of the service, as discussed between the operators and = their customers. Therefore, that design team was composed of operators = only. That design team created a first draft: = http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/=20 Now that the draft has been posted, the work and discussion should = continue in a public forum, i.e. this l3sm@ietf.org mailing list. Next step? we're busy trying to create a new short-lived WG, focusing = solely on this L3VPN service YANG model. See the proposal at https://datatracker.ietf.org/doc/charter-ietf-l3sm/ If this WG is created (This proposal is on the IESG telechat this week = for external review approval), this would be a good test for the IETF = community: are we ready to standardize a first service YANG model? = Personally, I believe we are.=20 IMO, the advantage/driver for this work is explained in the charter = proposal: The deliverable from this working group will provide information to = evaluate the set of YANG models that have already been developed or are under = development, and will help identify any missing models or details. The deliverable = can be viewed as driving requirements for protocol configuration model so that = the service parameters can be mapped into inputs used by the protocol = models. Don't hesitate to forward this email.=20 List address: l3sm@ietf.org=20 Archive: http://www.ietf.org/mail-archive/web/l3sm/=20 To subscribe: https://www.ietf.org/mailman/listinfo/l3sm Regards, Benoit =20 ------=_NextPart_000_052C_01D05660.19760B00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Benoit:

 

Will there be interaction between the layers of the modules (L3VPN = service), and BGP module?

 

Sue

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Benoit = Claise
Sent: Wednesday, March 04, 2015 8:55 AM
To: = idr@ietf.org
Subject: [Idr] Fwd: Some background on the L3VPN = Service YANG Model work

 

FYI. Sorry = for the potential duplicates.

Regards, Benoit =



-------- Forwarded = Message --------

<= /table>



Dear all,

Let me give you = some background on this new piece of work: The Layer Three Virtual = Private Network Service Model (L3SM)

Three months ago, Adrian = Farrel and I set up a design team to create a L3VPN service YANG = model.
It needs to be clearly understood that this L3VPN service = model is not an L3VPN configuration model. That is, it does not = provide details for configuring network elements or protocols. Instead = it contains the characteristics of the service, as discussed between the = operators and their customers.  Therefore, that design team was = composed of operators only.

That design team created a first = draft: http:/= /datatracker.ietf.org/doc/draft-l3vpn-service-yang/
Now that the = draft has been posted, the work and discussion should continue in a = public forum, i.e. this l3sm@ietf.org mailing = list.

Next step? we're busy trying to create a new short-lived = WG, focusing solely on this L3VPN service YANG model.
See the = proposal at https://data= tracker.ietf.org/doc/charter-ietf-l3sm/
If this WG is created = (This proposal is on the IESG telechat this week for external review = approval), this would be a good test for the IETF community: are we = ready to standardize a first service YANG model? Personally, I believe = we are.
IMO, the advantage/driver for this work is explained in the = charter proposal:

The deliverable from this working =
group will provide information to evaluate the
set =
of YANG models that have already been developed or are under =
development,
and will help identify any missing =
models or details.  The deliverable can =
be
viewed as driving requirements for protocol =
configuration model so that the
service parameters =
can be mapped into inputs used by the protocol =
models.

Don't hesitate to forward this email. =
    List address: l3sm@ietf.org
    = Archive: http://www.ietf.org/m= ail-archive/web/l3sm/
    To subscribe: https://www.ietf.org/= mailman/listinfo/l3sm

Regards, = Benoit



 

------=_NextPart_000_052C_01D05660.19760B00-- From nobody Wed Mar 4 19:51:50 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478F71A8BB5; Wed, 4 Mar 2015 19:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAb5OEOHpM_A; Wed, 4 Mar 2015 19:51:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143AF1A0191; Wed, 4 Mar 2015 19:51:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTH25865; Thu, 05 Mar 2015 03:51:44 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Mar 2015 03:51:43 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 5 Mar 2015 11:51:39 +0800 From: Xuxiaohu To: idr wg , "bier@ietf.org" Thread-Topic: New Version Notification for draft-xu-idr-bier-extensions-01.txt Thread-Index: AQHQVvcRu3WJRy8hr0yVTZ6AxgI65p0NQHrw Date: Thu, 5 Mar 2015 03:51:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830FD5F@NKGEML512-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.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 03:51:48 -0000 SGkgYWxsLA0KDQpUaGUgdXBkYXRlZCB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZC4gDQoNCkFu eSBmdXJ0aGVyIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJz ZGF5LCBNYXJjaCAwNSwgMjAxNSAxMTo0NyBBTQ0KPiBUbzogTWFjaCBDaGVuOyBYdXhpYW9odTsg VG9ueSBQcnp5Z2llbmRhOyBYdXhpYW9odTsgSUpzYnJhbmQgV2lqbmFuZHM7IEtleXVyDQo+IFBh dGVsOyBBbnRvbmkgUHJ6eWdpZW5kYTsgS2V5dXIgUGF0ZWw7IElKc2JyYW5kIFdpam5hbmRzOyBN YWNoIENoZW4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14 dS1pZHItYmllci1leHRlbnNpb25zLTAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC14dS1pZHItYmllci1leHRlbnNpb25zLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQteHUtaWRyLWJpZXItZXh0ZW5zaW9ucw0KPiBS ZXZpc2lvbjoJMDENCj4gVGl0bGU6CQlCR1AgRXh0ZW5zaW9ucyBmb3IgQklFUg0KPiBEb2N1bWVu dCBkYXRlOgkyMDE1LTAzLTAzDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBh Z2VzOgkJNw0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXh1LWlkci1iaWVyLWV4dGVuc2lvbnMtMDEudHh0DQo+IFN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1pZHItYmllci1leHRlbnNpb25z Lw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUt aWRyLWJpZXItZXh0ZW5zaW9ucy0wMQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC14dS1pZHItYmllci1leHRlbnNpb25zLTAxDQo+IA0KPiBBYnN0cmFj dDoNCj4gICAgQml0IEluZGV4IEV4cGxpY2l0IFJlcGxpY2F0aW9uIChCSUVSKSBpcyBhIG5ldyBt dWx0aWNhc3QgZm9yd2FyZGluZw0KPiAgICBhcmNoaXRlY3R1cmUgd2hpY2ggZG9lc24ndCByZXF1 aXJlIGFuIGV4cGxpY2l0IHRyZWUtYnVpbGRpbmcgcHJvdG9jb2wNCj4gICAgYW5kIGRvZXNuJ3Qg cmVxdWlyZSBpbnRlcm1lZGlhdGUgcm91dGVycyB0byBtYWludGFpbiBhbnkgbXVsdGljYXN0DQo+ ICAgIHN0YXRlLiAgQklFUiBpcyBhcHBsaWNhYmxlIGluIGEgbXVsdGktdGVuYW50IGRhdGEgY2Vu dGVyIG5ldHdvcmsNCj4gICAgZW52aXJvbm1lbnQgZm9yIGVmZmljaWVudCBkZWxpdmVyeSBvZiBC cm9hZGNhc3QsIFVua25vd24tdW5pY2FzdCBhbmQNCj4gICAgTXVsdGljYXN0IChCVU0pIHRyYWZm aWMgd2hpbGUgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIG1haW50YWluaW5nIGENCj4gICAgaHVn ZSBhbW91bnQgb2YgbXVsdGljYXN0IHN0YXRlIGluIHRoZSB1bmRlcmxheS4gIFRoaXMgZG9jdW1l bnQNCj4gICAgZGVzY3JpYmVzIEJHUCBleHRlbnNpb25zIGZvciBhZHZlcnRpc2luZyB0aGUgQklF Ui1zcGVjaWZpYw0KPiAgICBpbmZvcm1hdGlvbi4gIFRoZXNlIGV4dGVuc2lvbnMgYXJlIGFwcGxp Y2FibGUgaW4gdGhvc2UgbXVsdGktdGVuYW50DQo+ICAgIGRhdGEgY2VudGVycyB3aGVyZSBCR1Ag aW5zdGVhZCBvZiBJR1AgaXMgZGVwbG95ZWQgYXMgYW4gdW5kZXJsYXkgZm9yDQo+ICAgIG5ldHdv cmsgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQuICBUaGVzZSBleHRlbnNpb25zIG1heSBhbHNv IGJlDQo+ICAgIGFwcGxpY2FibGUgaW4gb3RoZXIgc2NlbmFyaW9zLg0KPiANCj4gDQo+IA0KPiAN Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K From nobody Thu Mar 5 07:58:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00661A0095 for ; Thu, 5 Mar 2015 07:58:04 -0800 (PST) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOW4X7EHbWO9 for ; Thu, 5 Mar 2015 07:58:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74261A00BD for ; Thu, 5 Mar 2015 07:58:01 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 7A91CC0C1F; Thu, 5 Mar 2015 16:58:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4EC73158111; Thu, 5 Mar 2015 16:58:00 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.247]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Thu, 5 Mar 2015 16:58:00 +0100 From: To: Susan Hares , 'Benoit Claise' , "idr@ietf.org" Thread-Topic: [Idr] Fwd: Some background on the L3VPN Service YANG Model work Thread-Index: AQHQVoLcioFR9bBJIE6k9iCcaDmZhZ0MVjqAgAG2ggA= Date: Thu, 5 Mar 2015 15:58:00 +0000 Message-ID: <21515_1425571080_54F87D08_21515_7335_1_9E32478DFA9976438E7A22F69B08FF9215C38FD7@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: <54F70B64.4010608@cisco.com> <54F70EBD.8060007@cisco.com> <052b01d0568a$024b0190$06e104b0$@ndzh.com> In-Reply-To: <052b01d0568a$024b0190$06e104b0$@ndzh.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9215C38FD7OPEXCLILM34corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.5.122419 Archived-At: Subject: Re: [Idr] Fwd: Some background on the L3VPN Service YANG Model work X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:58:04 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9215C38FD7OPEXCLILM34corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VzYW4sDQoNCk5vdCBkaXJlY3RseSwgTDNWUE4gc2VydmljZSBtb2R1bGUgaXMgcmVhbGx5 IGFuIGFic3RyYWN0aW9uIChubyBpbnRlcmFjdGlvbiB3aXRoIG5ldHdvcmsgZWxlbWVudHMpLiBC dXQgd2UgbWF5IGV4cGVjdCB0aGF0IHN5c3RlbXMgaW5zdGFudGlhdGluZyB0aGlzIG1vZHVsZSB3 aWxsIHRyYW5zbGF0ZSB0aGVzZSBhYnN0cmFjdGlvbnMgdG8gY29uZmlndXJhdGlvbiBvZiBuZXR3 b3JrIGVsZW1lbnRzIHRoYXQgY2FuIGJlIGRvbmUgYWxzbyB0aHJvdWdoIE5ldENvbmYvWWFuZyBh bmQgaGVyZSBCR1AgbW9kdWxlIG1heSBiZSBjYWxsZWQuDQoNCkhvcGUgaXQgaGVscHMsDQoNClN0 ZXBoYW5lDQoNCg0KRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTdXNhbiBIYXJlcw0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNCwgMjAxNSAxNTo0 Nw0KVG86ICdCZW5vaXQgQ2xhaXNlJzsgaWRyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkcl0g RndkOiBTb21lIGJhY2tncm91bmQgb24gdGhlIEwzVlBOIFNlcnZpY2UgWUFORyBNb2RlbCB3b3Jr DQoNCkJlbm9pdDoNCg0KV2lsbCB0aGVyZSBiZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBsYXll cnMgb2YgdGhlIG1vZHVsZXMgKEwzVlBOIHNlcnZpY2UpLCBhbmQgQkdQIG1vZHVsZT8NCg0KU3Vl DQoNCkZyb206IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QmVub2l0IENsYWlzZQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAwNCwgMjAxNSA4OjU1IEFNDQpU bzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSBGd2Q6 IFNvbWUgYmFja2dyb3VuZCBvbiB0aGUgTDNWUE4gU2VydmljZSBZQU5HIE1vZGVsIHdvcmsNCg0K RllJLiBTb3JyeSBmb3IgdGhlIHBvdGVudGlhbCBkdXBsaWNhdGVzLg0KDQpSZWdhcmRzLCBCZW5v aXQNCg0KDQotLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDoNCg0K U29tZSBiYWNrZ3JvdW5kIG9uIHRoZSBMM1ZQTiBTZXJ2aWNlIFlBTkcgTW9kZWwgd29yaw0KDQpE YXRlOg0KDQpXZWQsIDA0IE1hciAyMDE1IDE0OjQwOjUyICswMTAwDQoNCkZyb206DQoNCkJlbm9p dCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPjxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+DQoN ClRvOg0KDQpsM3NtQGlldGYub3JnPG1haWx0bzpsM3NtQGlldGYub3JnPg0KDQoNCg0KRGVhciBh bGwsDQoNCkxldCBtZSBnaXZlIHlvdSBzb21lIGJhY2tncm91bmQgb24gdGhpcyBuZXcgcGllY2Ug b2Ygd29yazogVGhlIExheWVyIFRocmVlIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIFNlcnZpY2Ug TW9kZWwgKEwzU00pDQoNClRocmVlIG1vbnRocyBhZ28sIEFkcmlhbiBGYXJyZWwgYW5kIEkgc2V0 IHVwIGEgZGVzaWduIHRlYW0gdG8gY3JlYXRlIGEgTDNWUE4gc2VydmljZSBZQU5HIG1vZGVsLg0K SXQgbmVlZHMgdG8gYmUgY2xlYXJseSB1bmRlcnN0b29kIHRoYXQgdGhpcyBMM1ZQTiBzZXJ2aWNl IG1vZGVsIGlzIG5vdCBhbiBMM1ZQTiBjb25maWd1cmF0aW9uIG1vZGVsLiBUaGF0IGlzLCBpdCBk b2VzIG5vdCBwcm92aWRlIGRldGFpbHMgZm9yIGNvbmZpZ3VyaW5nIG5ldHdvcmsgZWxlbWVudHMg b3IgcHJvdG9jb2xzLiBJbnN0ZWFkIGl0IGNvbnRhaW5zIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2Yg dGhlIHNlcnZpY2UsIGFzIGRpc2N1c3NlZCBiZXR3ZWVuIHRoZSBvcGVyYXRvcnMgYW5kIHRoZWly IGN1c3RvbWVycy4gIFRoZXJlZm9yZSwgdGhhdCBkZXNpZ24gdGVhbSB3YXMgY29tcG9zZWQgb2Yg b3BlcmF0b3JzIG9ubHkuDQoNClRoYXQgZGVzaWduIHRlYW0gY3JlYXRlZCBhIGZpcnN0IGRyYWZ0 OiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWwzdnBuLXNlcnZpY2UteWFu Zy8NCk5vdyB0aGF0IHRoZSBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQsIHRoZSB3b3JrIGFuZCBkaXNj dXNzaW9uIHNob3VsZCBjb250aW51ZSBpbiBhIHB1YmxpYyBmb3J1bSwgaS5lLiB0aGlzIGwzc21A aWV0Zi5vcmc8bWFpbHRvOmwzc21AaWV0Zi5vcmc+IG1haWxpbmcgbGlzdC4NCg0KTmV4dCBzdGVw PyB3ZSdyZSBidXN5IHRyeWluZyB0byBjcmVhdGUgYSBuZXcgc2hvcnQtbGl2ZWQgV0csIGZvY3Vz aW5nIHNvbGVseSBvbiB0aGlzIEwzVlBOIHNlcnZpY2UgWUFORyBtb2RlbC4NClNlZSB0aGUgcHJv cG9zYWwgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWwz c20vDQpJZiB0aGlzIFdHIGlzIGNyZWF0ZWQgKFRoaXMgcHJvcG9zYWwgaXMgb24gdGhlIElFU0cg dGVsZWNoYXQgdGhpcyB3ZWVrIGZvciBleHRlcm5hbCByZXZpZXcgYXBwcm92YWwpLCB0aGlzIHdv dWxkIGJlIGEgZ29vZCB0ZXN0IGZvciB0aGUgSUVURiBjb21tdW5pdHk6IGFyZSB3ZSByZWFkeSB0 byBzdGFuZGFyZGl6ZSBhIGZpcnN0IHNlcnZpY2UgWUFORyBtb2RlbD8gUGVyc29uYWxseSwgSSBi ZWxpZXZlIHdlIGFyZS4NCklNTywgdGhlIGFkdmFudGFnZS9kcml2ZXIgZm9yIHRoaXMgd29yayBp cyBleHBsYWluZWQgaW4gdGhlIGNoYXJ0ZXIgcHJvcG9zYWw6DQoNClRoZSBkZWxpdmVyYWJsZSBm cm9tIHRoaXMgd29ya2luZyBncm91cCB3aWxsIHByb3ZpZGUgaW5mb3JtYXRpb24gdG8gZXZhbHVh dGUgdGhlDQoNCnNldCBvZiBZQU5HIG1vZGVscyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGRldmVs b3BlZCBvciBhcmUgdW5kZXIgZGV2ZWxvcG1lbnQsDQoNCmFuZCB3aWxsIGhlbHAgaWRlbnRpZnkg YW55IG1pc3NpbmcgbW9kZWxzIG9yIGRldGFpbHMuICBUaGUgZGVsaXZlcmFibGUgY2FuIGJlDQoN CnZpZXdlZCBhcyBkcml2aW5nIHJlcXVpcmVtZW50cyBmb3IgcHJvdG9jb2wgY29uZmlndXJhdGlv biBtb2RlbCBzbyB0aGF0IHRoZQ0KDQpzZXJ2aWNlIHBhcmFtZXRlcnMgY2FuIGJlIG1hcHBlZCBp bnRvIGlucHV0cyB1c2VkIGJ5IHRoZSBwcm90b2NvbCBtb2RlbHMuDQpEb24ndCBoZXNpdGF0ZSB0 byBmb3J3YXJkIHRoaXMgZW1haWwuDQogICAgTGlzdCBhZGRyZXNzOiBsM3NtQGlldGYub3JnPG1h aWx0bzpsM3NtQGlldGYub3JnPg0KICAgIEFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9sM3NtLw0KICAgIFRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoNClJlZ2FyZHMsIEJlbm9pdA0KDQoNCg0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK --_000_9E32478DFA9976438E7A22F69B08FF9215C38FD7OPEXCLILM34corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsInNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgU3VzYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ob3QgZGlyZWN0bHksIEwzVlBOIHNlcnZp Y2UgbW9kdWxlIGlzIHJlYWxseSBhbiBhYnN0cmFjdGlvbiAobm8gaW50ZXJhY3Rpb24gd2l0aCBu ZXR3b3JrIGVsZW1lbnRzKS4gQnV0IHdlIG1heSBleHBlY3QgdGhhdCBzeXN0ZW1zIGluc3RhbnRp YXRpbmcgdGhpcyBtb2R1bGUNCiB3aWxsIHRyYW5zbGF0ZSB0aGVzZSBhYnN0cmFjdGlvbnMgdG8g Y29uZmlndXJhdGlvbiBvZiBuZXR3b3JrIGVsZW1lbnRzIHRoYXQgY2FuIGJlIGRvbmUgYWxzbyB0 aHJvdWdoIE5ldENvbmYvWWFuZyBhbmQgaGVyZSBCR1AgbW9kdWxlIG1heSBiZSBjYWxsZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Ib3BlIGl0IGhlbHBzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U3RlcGhhbmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IE1hcmNoIDA0LCAyMDE1IDE1OjQ3PGJyPg0KPGI+VG86PC9iPiAnQmVub2l0IENsYWlzZSc7IGlk ckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gRndkOiBTb21lIGJhY2tn cm91bmQgb24gdGhlIEwzVlBOIFNlcnZpY2UgWUFORyBNb2RlbCB3b3JrPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlbm9pdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpbGwgdGhlcmUgYmUgaW50ZXJh Y3Rpb24gYmV0d2VlbiB0aGUgbGF5ZXJzIG9mIHRoZSBtb2R1bGVzIChMM1ZQTiBzZXJ2aWNlKSwg YW5kIEJHUCBtb2R1bGU/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IElkciBbPGEgaHJlZj0ibWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5CZW5vaXQgQ2xhaXNlPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg TWFyY2ggMDQsIDIwMTUgODo1NSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmlk ckBpZXRmLm9yZyI+aWRyQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSWRyXSBG d2Q6IFNvbWUgYmFja2dyb3VuZCBvbiB0aGUgTDNWUE4gU2VydmljZSBZQU5HIE1vZGVsIHdvcms8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GWUkuIFNvcnJ5 IGZvciB0aGUgcG90ZW50aWFsIGR1cGxpY2F0ZXMuPGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0 IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Ci0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIg c3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9v OnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgYmFja2dyb3VuZCBvbiB0aGUgTDNWUE4gU2Vydmlj ZSBZQU5HIE1vZGVsIHdvcms8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlZCwgMDQgTWFyIDIw MTUgMTQ6NDA6NTIgJiM0MzswMTAwPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu OnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZW5vaXQgQ2xh aXNlIDxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+Jmx0O2JjbGFpc2VAY2lzY28u Y29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxi PlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86bDNzbUBp ZXRmLm9yZyI+bDNzbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpEZWFy IGFsbCw8YnI+DQo8YnI+DQpMZXQgbWUgZ2l2ZSB5b3Ugc29tZSBiYWNrZ3JvdW5kIG9uIHRoaXMg bmV3IHBpZWNlIG9mIHdvcms6IFRoZSBMYXllciBUaHJlZSBWaXJ0dWFsIFByaXZhdGUgTmV0d29y ayBTZXJ2aWNlIE1vZGVsIChMM1NNKTxicj4NCjxicj4NClRocmVlIG1vbnRocyBhZ28sIEFkcmlh biBGYXJyZWwgYW5kIEkgc2V0IHVwIGEgZGVzaWduIHRlYW0gdG8gY3JlYXRlIGEgTDNWUE4gPHU+ c2VydmljZQ0KPC91PllBTkcgbW9kZWwuPGJyPg0KSXQgbmVlZHMgdG8gYmUgY2xlYXJseSB1bmRl cnN0b29kIHRoYXQgdGhpcyBMM1ZQTiA8dT5zZXJ2aWNlIDwvdT5tb2RlbCBpcyBub3QgYW4gTDNW UE4gY29uZmlndXJhdGlvbiBtb2RlbC4gVGhhdCBpcywgaXQgZG9lcyBub3QgcHJvdmlkZSBkZXRh aWxzIGZvciBjb25maWd1cmluZyBuZXR3b3JrIGVsZW1lbnRzIG9yIHByb3RvY29scy4gSW5zdGVh ZCBpdCBjb250YWlucyB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBzZXJ2aWNlLCBhcyBkaXNj dXNzZWQNCiBiZXR3ZWVuIHRoZSBvcGVyYXRvcnMgYW5kIHRoZWlyIGN1c3RvbWVycy4mbmJzcDsg VGhlcmVmb3JlLCB0aGF0IGRlc2lnbiB0ZWFtIHdhcyBjb21wb3NlZCBvZiBvcGVyYXRvcnMgb25s eS48YnI+DQo8YnI+DQpUaGF0IGRlc2lnbiB0ZWFtIGNyZWF0ZWQgYSBmaXJzdCBkcmFmdDogPGEg aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sM3Zwbi1zZXJ2aWNl LXlhbmcvIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbDN2cG4tc2Vy dmljZS15YW5nLzwvYT4gPGJyPg0KTm93IHRoYXQgdGhlIGRyYWZ0IGhhcyBiZWVuIHBvc3RlZCwg dGhlIHdvcmsgYW5kIGRpc2N1c3Npb24gc2hvdWxkIGNvbnRpbnVlIGluIGEgcHVibGljIGZvcnVt LCBpLmUuIHRoaXMNCjxhIGhyZWY9Im1haWx0bzpsM3NtQGlldGYub3JnIj5sM3NtQGlldGYub3Jn PC9hPiBtYWlsaW5nIGxpc3QuPGJyPg0KPGJyPg0KTmV4dCBzdGVwPyB3ZSdyZSBidXN5IHRyeWlu ZyB0byBjcmVhdGUgYSBuZXcgc2hvcnQtbGl2ZWQgV0csIGZvY3VzaW5nIHNvbGVseSBvbiB0aGlz IEwzVlBOIHNlcnZpY2UgWUFORyBtb2RlbC48YnI+DQpTZWUgdGhlIHByb3Bvc2FsIGF0IDxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1sM3NtLyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtbDNzbS88L2E+ PGJyPg0KSWYgdGhpcyBXRyBpcyBjcmVhdGVkIChUaGlzIHByb3Bvc2FsIGlzIG9uIHRoZSBJRVNH IHRlbGVjaGF0IHRoaXMgd2VlayBmb3IgZXh0ZXJuYWwgcmV2aWV3IGFwcHJvdmFsKSwgdGhpcyB3 b3VsZCBiZSBhIGdvb2QgdGVzdCBmb3IgdGhlIElFVEYgY29tbXVuaXR5OiBhcmUgd2UgcmVhZHkg dG8gc3RhbmRhcmRpemUgYSBmaXJzdCBzZXJ2aWNlIFlBTkcgbW9kZWw/IFBlcnNvbmFsbHksIEkg YmVsaWV2ZSB3ZSBhcmUuDQo8YnI+DQpJTU8sIHRoZSBhZHZhbnRhZ2UvZHJpdmVyIGZvciB0aGlz IHdvcmsgaXMgZXhwbGFpbmVkIGluIHRoZSBjaGFydGVyIHByb3Bvc2FsOjxvOnA+PC9vOnA+PC9w Pg0KPHByZT5UaGUgZGVsaXZlcmFibGUgZnJvbSB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm92 aWRlIGluZm9ybWF0aW9uIHRvIGV2YWx1YXRlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNl dCBvZiBZQU5HIG1vZGVscyB0aGF0IGhhdmUgYWxyZWFkeSBiZWVuIGRldmVsb3BlZCBvciBhcmUg dW5kZXIgZGV2ZWxvcG1lbnQsPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIHdpbGwgaGVscCBp ZGVudGlmeSBhbnkgbWlzc2luZyBtb2RlbHMgb3IgZGV0YWlscy4mbmJzcDsgVGhlIGRlbGl2ZXJh YmxlIGNhbiBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnZpZXdlZCBhcyBkcml2aW5nIHJlcXVp cmVtZW50cyBmb3IgcHJvdG9jb2wgY29uZmlndXJhdGlvbiBtb2RlbCBzbyB0aGF0IHRoZTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZpY2UgcGFyYW1ldGVycyBjYW4gYmUgbWFwcGVkIGludG8g aW5wdXRzIHVzZWQgYnkgdGhlIHByb3RvY29sIG1vZGVscy48bzpwPjwvbzpwPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Eb24ndCBoZXNp dGF0ZSB0byBmb3J3YXJkIHRoaXMgZW1haWwuDQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTGlz dCBhZGRyZXNzOiA8YSBocmVmPSJtYWlsdG86bDNzbUBpZXRmLm9yZyI+bDNzbUBpZXRmLm9yZzwv YT4gPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEFyY2hpdmU6IDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sM3NtLyI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL2wzc20vPC9hPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRvIHN1YnNj cmliZTogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3Nt Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc208L2E+PGJyPg0KPGJy Pg0KUmVnYXJkcywgQmVub2l0PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF9215C38FD7OPEXCLILM34corp_-- From nobody Fri Mar 6 04:17:50 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350ED1ACDC8 for ; Fri, 6 Mar 2015 04:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBwpSZ1dsDaI for ; Fri, 6 Mar 2015 04:17:46 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 44B151ACDC7 for ; Fri, 6 Mar 2015 04:17:46 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Fri, 6 Mar 2015 07:17:39 -0500 Message-ID: <0ec501d05807$8a4027a0$9ec076e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0EC6_01D057DD.A16A6DC0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBYB1X0oF786zTuSqOV89YTKkFlmg== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] WG Adoption call for draft-hao-idr-flowspec-evpn (1/19/2015 to 2/2/2015) - Intent to Adopt Call (3/2 - 3/6) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:17:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0EC6_01D057DD.A16A6DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The IDR WG has adopted draft-hao-idr-flowspec-evpn-00.txt. Will the authors please submit this as: draft-ietf-idr-flowspec-evpn-00.txt Thank-you, Idr chairs Sue Hares and John Scudder ------=_NextPart_000_0EC6_01D057DD.A16A6DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IDR WG = has adopted draft-hao-idr-flowspec-evpn-00.txt.  Will the authors = please submit this as:

 

draft-ietf-idr-flowspec-evpn-00.txt

 

Thank-you,

Idr = chairs

Sue Hares and John Scudder =

------=_NextPart_000_0EC6_01D057DD.A16A6DC0-- From nobody Fri Mar 6 12:40:45 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7371A8028; Fri, 6 Mar 2015 12:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dDpgBZV-P-m; Fri, 6 Mar 2015 12:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 285431A0060; Fri, 6 Mar 2015 12:40:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 12:40:43 -0800 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:40:44 -0000 Brian Haberman has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a clearly written document. The only point I will make is that I do not think the 2119 keywords in section 6 are necessary. From nobody Fri Mar 6 12:40:48 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 587A31A802A; Fri, 6 Mar 2015 12:40:44 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7371A8028; Fri, 6 Mar 2015 12:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dDpgBZV-P-m; Fri, 6 Mar 2015 12:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 285431A0060; Fri, 6 Mar 2015 12:40:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 12:40:43 -0800 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:40:44 -0000 Brian Haberman has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a clearly written document. The only point I will make is that I do not think the 2119 keywords in section 6 are necessary. From nobody Fri Mar 6 12:48:45 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9B01A702B; Fri, 6 Mar 2015 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv09zKgKY1Z6; Fri, 6 Mar 2015 12:48:43 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CB5B21A6F12; Fri, 6 Mar 2015 12:48:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Brian Haberman'" , "'The IESG'" References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> In-Reply-To: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> Date: Fri, 6 Mar 2015 15:48:31 -0500 Message-ID: <122301d0584e$e8395830$b8ac0890$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQLFY114IyfoqpYe9ZpDBLzAbdrk65sl1kYw X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:48:44 -0000 Brian: My recollection is that there was a lengthy outage caused by a bogus = route received by IBGP and then sent to the rest of the world. Rob = Shakir may have a better memory. After the draft deadline, I will look = for the incident's write-up in NANOG or in my BGP mail archive. = Therefore, the word RECOMMEND was considered appropriate.=20 Sue=20 -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Friday, March 06, 2015 3:41 PM To: The IESG Cc: idr@ietf.org; idr-chairs@ietf.org; rob.shakir@bt.com; = draft-ietf-idr-error-handling.all@ietf.org Subject: Brian Haberman's No Objection on = draft-ietf-idr-error-handling-18: (with COMMENT) Brian Haberman has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a clearly written document. The only point I will make is = that I do not think the 2119 keywords in section 6 are necessary. From nobody Fri Mar 6 12:48:54 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 45B8A1A8028; Fri, 6 Mar 2015 12:48:44 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9B01A702B; Fri, 6 Mar 2015 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv09zKgKY1Z6; Fri, 6 Mar 2015 12:48:43 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CB5B21A6F12; Fri, 6 Mar 2015 12:48:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Brian Haberman'" , "'The IESG'" References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> In-Reply-To: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> Date: Fri, 6 Mar 2015 15:48:31 -0500 Message-ID: <122301d0584e$e8395830$b8ac0890$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQLFY114IyfoqpYe9ZpDBLzAbdrk65sl1kYw X-Authenticated-User: skh@ndzh.com Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:48:44 -0000 Brian: My recollection is that there was a lengthy outage caused by a bogus = route received by IBGP and then sent to the rest of the world. Rob = Shakir may have a better memory. After the draft deadline, I will look = for the incident's write-up in NANOG or in my BGP mail archive. = Therefore, the word RECOMMEND was considered appropriate.=20 Sue=20 -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net]=20 Sent: Friday, March 06, 2015 3:41 PM To: The IESG Cc: idr@ietf.org; idr-chairs@ietf.org; rob.shakir@bt.com; = draft-ietf-idr-error-handling.all@ietf.org Subject: Brian Haberman's No Objection on = draft-ietf-idr-error-handling-18: (with COMMENT) Brian Haberman has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a clearly written document. The only point I will make is = that I do not think the 2119 keywords in section 6 are necessary. From nobody Fri Mar 6 13:01:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050651A86F2; Fri, 6 Mar 2015 12:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF3QB9_eoc8f; Fri, 6 Mar 2015 12:59:39 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADA01A86F1; Fri, 6 Mar 2015 12:59:38 -0800 (PST) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 6 Mar 2015 20:59:32 +0000 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.203]) by EVMHT01-UKBR.domain1.systemhost.net ([193.113.108.42]) with mapi; Fri, 6 Mar 2015 20:59:36 +0000 From: To: , , Date: Fri, 6 Mar 2015 20:59:34 +0000 Thread-Topic: Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) Thread-Index: AdBYUHQcDa7e5ZaGRUmsBAlkT536gA== Message-ID: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> In-Reply-To: <122301d0584e$e8395830$b8ac0890$@ndzh.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 13:01:33 -0800 Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:59:42 -0000 Hi Sue, You remember correct =8B there were a number of issues that occurred around the time that this document got started (I presented about them at NANOG 51 =8B http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), and I also edited the requirements document for this work (which is in GROW =8B https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling -07).=20 We also wrote up some recommendations based on the original AS4_PATH incident (which triggered draft-scudder-idr-optional-transitive) which were on NANOG and IDR - http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and http://www.ietf.org/mail-archive/web/idr/current/msg03546.html. The reason that I think the 2119 wording is in there (and is still appropriate) is that there are complexities that are introduced operationally with this mechanism that did not occur before. The previous behaviour of a failed session makes a bunch of noise, and hence the issue can be diagnosed and examined. With the treat-as-withdraw approach it=B9s critical for operators to be able to determine when malformed UPDATEs are being received, and that sufficient information is given to the operator to resolve the problem. If we do not have these mechanisms, prefixes are being withdrawn via an (otherwise working) session - with the operator having no clue this is happening. Needless to say, this would be undesirable, and hence to avoid it, these recommendations are made. r. [06/03/2015 20:48, "Susan Hares" ] >Brian: > >My recollection is that there was a lengthy outage caused by a bogus >route received by IBGP and then sent to the rest of the world. Rob >Shakir may have a better memory. After the draft deadline, I will look >for the incident's write-up in NANOG or in my BGP mail archive. >Therefore, the word RECOMMEND was considered appropriate. > > >Sue=20 > >-----Original Message----- >From: Brian Haberman [mailto:brian@innovationslab.net] >Sent: Friday, March 06, 2015 3:41 PM >To: The IESG >Cc: idr@ietf.org; idr-chairs@ietf.org; rob.shakir@bt.com; >draft-ietf-idr-error-handling.all@ietf.org >Subject: Brian Haberman's No Objection on >draft-ietf-idr-error-handling-18: (with COMMENT) > >Brian Haberman has entered the following ballot position for >draft-ietf-idr-error-handling-18: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thank you for a clearly written document. The only point I will make is >that I do not think the 2119 keywords in section 6 are necessary. > > > From nobody Fri Mar 6 13:01:36 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 255651A86F3; Fri, 6 Mar 2015 12:59:42 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050651A86F2; Fri, 6 Mar 2015 12:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF3QB9_eoc8f; Fri, 6 Mar 2015 12:59:39 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADA01A86F1; Fri, 6 Mar 2015 12:59:38 -0800 (PST) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 6 Mar 2015 20:59:32 +0000 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.203]) by EVMHT01-UKBR.domain1.systemhost.net ([193.113.108.42]) with mapi; Fri, 6 Mar 2015 20:59:36 +0000 From: To: , , Date: Fri, 6 Mar 2015 20:59:34 +0000 Thread-Topic: Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) Thread-Index: AdBYUHQcDa7e5ZaGRUmsBAlkT536gA== Message-ID: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> In-Reply-To: <122301d0584e$e8395830$b8ac0890$@ndzh.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 13:01:33 -0800 Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:59:42 -0000 Hi Sue, You remember correct =8B there were a number of issues that occurred around the time that this document got started (I presented about them at NANOG 51 =8B http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), and I also edited the requirements document for this work (which is in GROW =8B https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling -07).=20 We also wrote up some recommendations based on the original AS4_PATH incident (which triggered draft-scudder-idr-optional-transitive) which were on NANOG and IDR - http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and http://www.ietf.org/mail-archive/web/idr/current/msg03546.html. The reason that I think the 2119 wording is in there (and is still appropriate) is that there are complexities that are introduced operationally with this mechanism that did not occur before. The previous behaviour of a failed session makes a bunch of noise, and hence the issue can be diagnosed and examined. With the treat-as-withdraw approach it=B9s critical for operators to be able to determine when malformed UPDATEs are being received, and that sufficient information is given to the operator to resolve the problem. If we do not have these mechanisms, prefixes are being withdrawn via an (otherwise working) session - with the operator having no clue this is happening. Needless to say, this would be undesirable, and hence to avoid it, these recommendations are made. r. [06/03/2015 20:48, "Susan Hares" ] >Brian: > >My recollection is that there was a lengthy outage caused by a bogus >route received by IBGP and then sent to the rest of the world. Rob >Shakir may have a better memory. After the draft deadline, I will look >for the incident's write-up in NANOG or in my BGP mail archive. >Therefore, the word RECOMMEND was considered appropriate. > > >Sue=20 > >-----Original Message----- >From: Brian Haberman [mailto:brian@innovationslab.net] >Sent: Friday, March 06, 2015 3:41 PM >To: The IESG >Cc: idr@ietf.org; idr-chairs@ietf.org; rob.shakir@bt.com; >draft-ietf-idr-error-handling.all@ietf.org >Subject: Brian Haberman's No Objection on >draft-ietf-idr-error-handling-18: (with COMMENT) > >Brian Haberman has entered the following ballot position for >draft-ietf-idr-error-handling-18: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thank you for a clearly written document. The only point I will make is >that I do not think the 2119 keywords in section 6 are necessary. > > > From nobody Fri Mar 6 13:09:54 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D21A86F8; Fri, 6 Mar 2015 13:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEg92AVD_Owu; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A801A86F0; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 380F388112; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8CCC313682D7; Fri, 6 Mar 2015 13:09:48 -0800 (PST) Message-ID: <54FA1795.5000406@innovationslab.net> Date: Fri, 06 Mar 2015 16:09:41 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rob.shakir@bt.com, shares@ndzh.com, iesg@ietf.org References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 21:09:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rob, On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: > Hi Sue, >=20 > You remember correct =8B there were a number of issues that occurred ar= ound > the time that this document got started (I presented about them at NANO= G > 51 =8B http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), an= d I > also edited the requirements document for this work (which is in GROW =8B= > https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-hand= ling > -07).=20 >=20 > We also wrote up some recommendations based on the original AS4_PATH > incident (which triggered draft-scudder-idr-optional-transitive) which > were on NANOG and IDR - > http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and > http://www.ietf.org/mail-archive/web/idr/current/msg03546.html. >=20 > The reason that I think the 2119 wording is in there (and is still > appropriate) is that there are complexities that are introduced > operationally with this mechanism that did not occur before. The previo= us > behaviour of a failed session makes a bunch of noise, and hence the iss= ue > can be diagnosed and examined. With the treat-as-withdraw approach it=B9= s > critical for operators to be able to determine when malformed UPDATEs a= re > being received, and that sufficient information is given to the operato= r > to resolve the problem. If we do not have these mechanisms, prefixes ar= e > being withdrawn via an (otherwise working) session - with the operator > having no clue this is happening. Needless to say, this would be > undesirable, and hence to avoid it, these recommendations are made. >=20 The above is quite clear and shows me how I think I misread the second paragraph. I read it has saying the operator SHOULD identify the offending route and trace it back to its ingress into the network. The description above sounds like the text is saying the router SHOULD provide enough information so that the operator knows to trace the offending route. Am I interpreting that correctly? Regards, Brian --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+hebAAoJEBOZRqCi7goqzWIH/04sIkV57K108pFh/GjNgaa8 IQPXmN0Ro++xTnVfCNK25BVdJ55K+OIknUhH/R98sLPOaVkFKa/Cg4MjfeCGLhtv hxF208i61CxjBlHutkP+i2miGma2q2WJnPN25m6GDF13mTgb/vBhf1rtXSwXURVA ihnA+Gbx8xkQnRxbr0PXN4pHDtqTwbLwsS9tEd1qEEpmZ/P2vHHYYlWnj0cenT5x dxrNsSUQwf/z3se33snUjpLmhIdOQuhuKdMCGzJCbvv8zdKlzuvY5TuVucisfX/g i8la0Wf6iccyCvu3VUtKsP5Y0AE037vH7vBCZDs7vI89g2CAipKeeX5N/l+35Ho= =dLuI -----END PGP SIGNATURE----- --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L-- From nobody Fri Mar 6 13:09:55 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 12DBA1A8700; Fri, 6 Mar 2015 13:09:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D21A86F8; Fri, 6 Mar 2015 13:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEg92AVD_Owu; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A801A86F0; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 380F388112; Fri, 6 Mar 2015 13:09:49 -0800 (PST) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8CCC313682D7; Fri, 6 Mar 2015 13:09:48 -0800 (PST) Message-ID: <54FA1795.5000406@innovationslab.net> Date: Fri, 06 Mar 2015 16:09:41 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rob.shakir@bt.com, shares@ndzh.com, iesg@ietf.org References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 21:09:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rob, On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: > Hi Sue, >=20 > You remember correct =8B there were a number of issues that occurred ar= ound > the time that this document got started (I presented about them at NANO= G > 51 =8B http://www.slideshare.net/robjs/bgp-error-handling-nanog-51), an= d I > also edited the requirements document for this work (which is in GROW =8B= > https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-hand= ling > -07).=20 >=20 > We also wrote up some recommendations based on the original AS4_PATH > incident (which triggered draft-scudder-idr-optional-transitive) which > were on NANOG and IDR - > http://mailman.nanog.org/pipermail/nanog/2009-January/006816.html and > http://www.ietf.org/mail-archive/web/idr/current/msg03546.html. >=20 > The reason that I think the 2119 wording is in there (and is still > appropriate) is that there are complexities that are introduced > operationally with this mechanism that did not occur before. The previo= us > behaviour of a failed session makes a bunch of noise, and hence the iss= ue > can be diagnosed and examined. With the treat-as-withdraw approach it=B9= s > critical for operators to be able to determine when malformed UPDATEs a= re > being received, and that sufficient information is given to the operato= r > to resolve the problem. If we do not have these mechanisms, prefixes ar= e > being withdrawn via an (otherwise working) session - with the operator > having no clue this is happening. Needless to say, this would be > undesirable, and hence to avoid it, these recommendations are made. >=20 The above is quite clear and shows me how I think I misread the second paragraph. I read it has saying the operator SHOULD identify the offending route and trace it back to its ingress into the network. The description above sounds like the text is saying the router SHOULD provide enough information so that the operator knows to trace the offending route. Am I interpreting that correctly? Regards, Brian --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+hebAAoJEBOZRqCi7goqzWIH/04sIkV57K108pFh/GjNgaa8 IQPXmN0Ro++xTnVfCNK25BVdJ55K+OIknUhH/R98sLPOaVkFKa/Cg4MjfeCGLhtv hxF208i61CxjBlHutkP+i2miGma2q2WJnPN25m6GDF13mTgb/vBhf1rtXSwXURVA ihnA+Gbx8xkQnRxbr0PXN4pHDtqTwbLwsS9tEd1qEEpmZ/P2vHHYYlWnj0cenT5x dxrNsSUQwf/z3se33snUjpLmhIdOQuhuKdMCGzJCbvv8zdKlzuvY5TuVucisfX/g i8la0Wf6iccyCvu3VUtKsP5Y0AE037vH7vBCZDs7vI89g2CAipKeeX5N/l+35Ho= =dLuI -----END PGP SIGNATURE----- --QeWefDnCaIMM71PJMHkGhN1qaeWBGIg2L-- From nobody Sat Mar 7 01:19:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10081A8A63; Sat, 7 Mar 2015 01:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzKTzWVM5kFE; Sat, 7 Mar 2015 01:19:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2671A8A64; Sat, 7 Mar 2015 01:19:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307091935.6965.35733.idtracker@ietfa.amsl.com> Date: Sat, 07 Mar 2015 01:19:35 -0800 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-l2vpn-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 09:19:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Dissemination of Flow Specification Rules for L2 VPN Authors : Weiguo Hao Qiandeng Liang Stephane Litkowski Shunwan Zhuang Filename : draft-ietf-idr-flowspec-l2vpn-00.txt Pages : 10 Date : 2015-03-07 Abstract: This document defines BGP flow-spec extension for Ethernet traffic filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for dissemination traffic filtering information in an L2VPN environment. A new subset of component types and extended community also are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-l2vpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-l2vpn-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Mar 7 15:08:48 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF3B1A1A07 for ; Sat, 7 Mar 2015 15:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5G3E6lvGM8b for ; Sat, 7 Mar 2015 15:08:46 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27091A1A0B for ; Sat, 7 Mar 2015 15:08:45 -0800 (PST) Received: by iecvy18 with SMTP id vy18so30308972iec.1 for ; Sat, 07 Mar 2015 15:08:45 -0800 (PST) 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:content-type; bh=/Foq3VPd3c2tEuiL4Lb28X2PriCYhJpT1OFn8rjunZI=; b=h71ZW+6/xLJEi6kZIhYig5EMesuK4waeF0i5eQVTiyBDsPf2lwjFwQ5L5+30A2wI8v Y3iGWz6zj7TNN8CDFPlQLNSs89eZql2swP2MUXzC83ZVXlbslZAO6wSu44mhhk3C2Vbm /flhABgI/+/ifi/FfG6buSa2OkOfhd7TMqGngy5Grnq2WPPHW9aZR0R/uJAW48LlGjW3 lW0RfHd28ls2QYxRRlLskKdH9M3Qgbvj2/MScdkUJvLKj/yUgow4oxtduMGnwvj4Eysd Xo/A7Vray0htz304L5iz9m+wfsU02Ifl6BG6zo177/PyPXd8aqpp2XzPzGPic70vKeUx 1ROg== MIME-Version: 1.0 X-Received: by 10.42.123.135 with SMTP id s7mr18158556icr.55.1425769725251; Sat, 07 Mar 2015 15:08:45 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sat, 7 Mar 2015 15:08:45 -0800 (PST) In-Reply-To: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> Date: Sun, 8 Mar 2015 00:08:45 +0100 X-Google-Sender-Auth: iYHx9GX-CPrnHZgJpjykeBHKX6w Message-ID: From: Robert Raszuk To: idr wg Content-Type: multipart/alternative; boundary=20cf3010e7a90176d60510bae25c Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 23:08:47 -0000 --20cf3010e7a90176d60510bae25c Content-Type: text/plain; charset=UTF-8 A new version of I-D, draft-raszuk-wide-bgp-communities-05.txt has been successfully submitted by Robert Raszuk and posted to the IETF repository. Name: draft-raszuk-wide-bgp-communities Revision: 05 Title: Wide BGP Communities Attribute Document date: 2015-03-06 Group: Individual Submission Pages: 23 URL: http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.txt Status: https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/ Htmlized: http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-raszuk-wide-bgp-communities-05 Abstract: Route tagging plays an important role in external BGP [RFC4271] relations, in communicating various routing policies between peers. It is also a very common best practice among operators to propagate various additional information about routes intra-domain. The most common tool used today to attach various information about routes is through the use of BGP communities [RFC1997]. Such information is important to allow BGP speakers to perform some mutually agreed actions without the need to maintain a separate offline database for each tuple of prefix and associated set of action entries. This document defines a new encoding which will enhance and simplify what can be accomplished today with the use of BGP communities. The most important addition this specification makes over currently defined BGP communities is the ability to specify, carry as well as use for execution an operator's defined set of parameters. It also provides an extensible platform for any new community encoding needs in the future. The IETF Secretariat --20cf3010e7a90176d60510bae25c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-raszuk-wide-bgp-communities-05.txt
has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-raszuk-wide-bgp-communi= ties
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wide BGP Communities Attribute
Document date:=C2=A0 2015-03-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05= .txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.or= g/html/draft-raszuk-wide-bgp-communities-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-raszuk-wide-bgp-communities-05
Abstract:
=C2=A0 =C2=A0Route tagging plays an important role in external BGP [RFC4271= ]
=C2=A0 =C2=A0relations, in communicating various routing policies between p= eers.
=C2=A0 =C2=A0It is also a very common best practice among operators to prop= agate
=C2=A0 =C2=A0various additional information about routes intra-domain.=C2= =A0 The most
=C2=A0 =C2=A0common tool used today to attach various information about rou= tes is
=C2=A0 =C2=A0through the use of BGP communities [RFC1997].

=C2=A0 =C2=A0Such information is important to allow BGP speakers to perform= some
=C2=A0 =C2=A0mutually agreed actions without the need to maintain a separat= e
=C2=A0 =C2=A0offline database for each tuple of prefix and associated set o= f
=C2=A0 =C2=A0action entries.

=C2=A0 =C2=A0This document defines a new encoding which will enhance and si= mplify
=C2=A0 =C2=A0what can be accomplished today with the use of BGP communities= .=C2=A0 The
=C2=A0 =C2=A0most important addition this specification makes over currentl= y
=C2=A0 =C2=A0defined BGP communities is the ability to specify, carry as we= ll as
=C2=A0 =C2=A0use for execution an operator's defined set of parameters.= =C2=A0 It also
=C2=A0 =C2=A0provides an extensible platform for any new community encoding= needs
=C2=A0 =C2=A0in the future.

The IETF Secretariat


--20cf3010e7a90176d60510bae25c-- From nobody Sat Mar 7 15:09:18 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE461A1A24 for ; Sat, 7 Mar 2015 15:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_muHwL0NkUu for ; Sat, 7 Mar 2015 15:09:15 -0800 (PST) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57481A1A20 for ; Sat, 7 Mar 2015 15:09:15 -0800 (PST) Received: by iecrl12 with SMTP id rl12so11687536iec.8 for ; Sat, 07 Mar 2015 15:09:15 -0800 (PST) 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:content-type; bh=n9yBbwC/oMPSc6yXrjrBfzBiGV4o5lBE5lXa4P3TV1U=; b=NApRlxMezjftmFsB0RCQ69a4Ps5yc8uRvfzrp37lN9iiYD8T4USHzx0O/IkoIsEVWx +/1ENwvHV05KRfide/112sRCRfpjFN0PTx8cINBZxl7tJSBmycQL0DZDmVvtwkyTy8fc 1xNaiuPW/cvJWI1z7A608ChRyt0I7q0cyvHOauXM5VbQE+G1kGQea+44na0/MgdTDn89 9MEaOlh2ytKJQQoA1SrSXU4Ylim6wGJg3B/fCaYlL/dFitQpf6V8cY+/GaWwKgoLBIWz RtQirzKTMPlqcgxvSxEawuS5gj0BsJvD9EgqBiFITPNbv46PtjnJqbML70Dtl3+i4Kda LVwQ== MIME-Version: 1.0 X-Received: by 10.50.62.110 with SMTP id x14mr64341810igr.2.1425769755143; Sat, 07 Mar 2015 15:09:15 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sat, 7 Mar 2015 15:09:15 -0800 (PST) In-Reply-To: <20150307230707.26404.10020.idtracker@ietfa.amsl.com> References: <20150307230707.26404.10020.idtracker@ietfa.amsl.com> Date: Sun, 8 Mar 2015 00:09:15 +0100 X-Google-Sender-Auth: aV0ykwQifdeh4HlV3kLZ3Klih64 Message-ID: From: Robert Raszuk To: idr wg Content-Type: multipart/alternative; boundary=047d7bdc15b8c996ab0510bae34a Archived-At: Subject: [Idr] Fwd: New Version Notification for draft-raszuk-registered-wide-bgp-communities-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 23:09:17 -0000 --047d7bdc15b8c996ab0510bae34a Content-Type: text/plain; charset=UTF-8 A new version of I-D, draft-raszuk-registered-wide-bgp-communities-00.txt has been successfully submitted by Robert Raszuk and posted to the IETF repository. Name: draft-raszuk-registered-wide-bgp-communities Revision: 00 Title: Registered Wide BGP Community Values Document date: 2015-03-07 Group: Individual Submission Pages: 17 URL: http://www.ietf.org/internet-drafts/draft-raszuk-registered-wide-bgp-communities-00.txt Status: https://datatracker.ietf.org/doc/draft-raszuk-registered-wide-bgp-communities/ Htmlized: http://tools.ietf.org/html/draft-raszuk-registered-wide-bgp-communities-00 Abstract: Communicating various routing policies via route tagging plays an important role in external BGP peering relations. The most common tool used today to attach various information about routes is realized with the use of BGP communities. Such information is important for the peering AS to perform some mutually agreed actions without the need to maintain a separate offline database for each pair of prefix and an associated with it requested set of action entries. This document proposes to establish a new IANA maintained registry of most commonly used Wide BGP Communities by network operators. Such public registry will allow for easy refernece and clear interpretation of the actions associated with received community values. The IETF Secretariat --047d7bdc15b8c996ab0510bae34a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-raszuk-registered-wide-bgp-communities-00.txt has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-raszuk-registered-wide-= bgp-communities
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Registered Wide BGP Community Valu= es
Document date:=C2=A0 2015-03-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-raszuk-registered-w= ide-bgp-communities-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-raszuk-registered-wide-bgp-communiti= es/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://to= ols.ietf.org/html/draft-raszuk-registered-wide-bgp-communities-00


Abstract:
=C2=A0 =C2=A0Communicating various routing policies via route tagging plays= an
=C2=A0 =C2=A0important role in external BGP peering relations.=C2=A0 The mo= st common
=C2=A0 =C2=A0tool used today to attach various information about routes is<= br> =C2=A0 =C2=A0realized with the use of BGP communities.=C2=A0 Such informati= on is
=C2=A0 =C2=A0important for the peering AS to perform some mutually agreed a= ctions
=C2=A0 =C2=A0without the need to maintain a separate offline database for e= ach
=C2=A0 =C2=A0pair of prefix and an associated with it requested set of acti= on
=C2=A0 =C2=A0entries.

=C2=A0 =C2=A0This document proposes to establish a new IANA maintained regi= stry of
=C2=A0 =C2=A0most commonly used Wide BGP Communities by network operators.= =C2=A0 Such
=C2=A0 =C2=A0public registry will allow for easy refernece and clear
=C2=A0 =C2=A0interpretation of the actions associated with received communi= ty
=C2=A0 =C2=A0values.

The IETF Secretariat


--047d7bdc15b8c996ab0510bae34a-- From nobody Mon Mar 9 00:15:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAAE1A00CA; Sun, 8 Mar 2015 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_NfspfI0gM6; Sun, 8 Mar 2015 11:49:18 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD6D1A00E9; Sun, 8 Mar 2015 11:49:18 -0700 (PDT) Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 8 Mar 2015 18:49:16 +0000 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.203]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Sun, 8 Mar 2015 18:49:16 +0000 From: To: , , Date: Sun, 8 Mar 2015 18:49:14 +0000 Thread-Topic: Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) Thread-Index: AdBZ0JNk/G2bFU3ERD+8SipeiJ8QyA== Message-ID: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> In-Reply-To: <54FA1795.5000406@innovationslab.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 00:15:29 -0700 Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 18:49:20 -0000 Hi Brian, [06/03/2015 21:09, "Brian Haberman" ] >Hi Rob, > >On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: >> >>=20 > >The above is quite clear and shows me how I think I misread the second >paragraph. I read it has saying the operator SHOULD identify the >offending route and trace it back to its ingress into the network. The >description above sounds like the text is saying the router SHOULD >provide enough information so that the operator knows to trace the >offending route. In my view, it=B9s both. If we have erroneous UPDATEs that are being transmitted by a router, this means that something, somewhere is wrong. It=B9s not really desirable for there to be routing updates that are known to have issues present in the system, and as such an operator should really examine this and fix it. Today, they have to do so, as the router transmitting the error is likely to be disconnected from the network (or some other system downstream will be, due to it transmitting the erroneous message). The recommendation is maybe stating something obvious, but I see no harm in having it in the document - we should remind people that transmitting an erroneous UPDATE is still a BadThing (tm), and is likely to be causing log messages for all other operators that see it in the DFZ. The best practice is clearly to clean up the error. r.=20 From nobody Mon Mar 9 00:15:33 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6BAD21A00ED; Sun, 8 Mar 2015 11:49:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAAE1A00CA; Sun, 8 Mar 2015 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_NfspfI0gM6; Sun, 8 Mar 2015 11:49:18 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD6D1A00E9; Sun, 8 Mar 2015 11:49:18 -0700 (PDT) Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 8 Mar 2015 18:49:16 +0000 Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.2.203]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Sun, 8 Mar 2015 18:49:16 +0000 From: To: , , Date: Sun, 8 Mar 2015 18:49:14 +0000 Thread-Topic: Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) Thread-Index: AdBZ0JNk/G2bFU3ERD+8SipeiJ8QyA== Message-ID: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> In-Reply-To: <54FA1795.5000406@innovationslab.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 00:15:29 -0700 Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 18:49:20 -0000 Hi Brian, [06/03/2015 21:09, "Brian Haberman" ] >Hi Rob, > >On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: >> >>=20 > >The above is quite clear and shows me how I think I misread the second >paragraph. I read it has saying the operator SHOULD identify the >offending route and trace it back to its ingress into the network. The >description above sounds like the text is saying the router SHOULD >provide enough information so that the operator knows to trace the >offending route. In my view, it=B9s both. If we have erroneous UPDATEs that are being transmitted by a router, this means that something, somewhere is wrong. It=B9s not really desirable for there to be routing updates that are known to have issues present in the system, and as such an operator should really examine this and fix it. Today, they have to do so, as the router transmitting the error is likely to be disconnected from the network (or some other system downstream will be, due to it transmitting the erroneous message). The recommendation is maybe stating something obvious, but I see no harm in having it in the document - we should remind people that transmitting an erroneous UPDATE is still a BadThing (tm), and is likely to be causing log messages for all other operators that see it in the DFZ. The best practice is clearly to clean up the error. r.=20 From nobody Mon Mar 9 05:21:33 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3255E1A87EB; Mon, 9 Mar 2015 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXzBdEfzwAwy; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A7F1A87E4; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8B0178814A; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D111771B0001; Mon, 9 Mar 2015 05:21:28 -0700 (PDT) Message-ID: <54FD9043.7000702@innovationslab.net> Date: Mon, 09 Mar 2015 08:21:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rob.shakir@bt.com, shares@ndzh.com, iesg@ietf.org References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tbfParc86IqrfWe2RUG34dVP2SuPDeBgv" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:21:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rob, Thanks for continuing this conversation... On 3/8/15 2:49 PM, rob.shakir@bt.com wrote: >=20 > Hi Brian, >=20 >=20 > [06/03/2015 21:09, "Brian Haberman" ] >=20 >> Hi Rob, >> >> On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: >>> >>> >> >> The above is quite clear and shows me how I think I misread the second= >> paragraph. I read it has saying the operator SHOULD identify the >> offending route and trace it back to its ingress into the network. Th= e >> description above sounds like the text is saying the router SHOULD >> provide enough information so that the operator knows to trace the >> offending route. >=20 > In my view, it=B9s both. >=20 > If we have erroneous UPDATEs that are being transmitted by a router, th= is > means that something, somewhere is wrong. It=B9s not really desirable f= or > there to be routing updates that are known to have issues present in th= e > system, and as such an operator should really examine this and fix it. > Today, they have to do so, as the router transmitting the error is like= ly > to be disconnected from the network (or some other system downstream wi= ll > be, due to it transmitting the erroneous message). >=20 > The recommendation is maybe stating something obvious, but I see no har= m > in having it in the document - we should remind people that transmittin= g > an erroneous UPDATE is still a BadThing (tm), and is likely to be causi= ng > log messages for all other operators that see it in the DFZ. The best > practice is clearly to clean up the error. I agree that it belongs in the document, but it appears to me to be a little opaque. I read the text in the draft as strictly something the operator has to worry about. The description you provided indicated that there needs to be sufficient notification from the router so that the operator can act on it. Perhaps what is needed is just a little clarification. Given that I raised this as a Comment, making any changes is really up to the authors/WG/AD. My thought would be a slight re-wording of the 2nd paragraph to indicate that the router needs to provide a notification when a malformed attribute is detected. That then provides the input needed for the operator to act on the recommendation in the section. Regards, Brian --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/ZBJAAoJEBOZRqCi7goqGHsH/3XhsaXt9ve9egirj0Rol6iW SRxOjZ00hbmAFuABK1BjXPkEpFv5UdHXR1Uxzq/b+XHBbLEF0vfIlQUE/dssOIi8 W9jAjezwCtFtUjKkvS6EB99hlVZVbVwNRAmhfMqAlty+VaQA+h1ykNW7R5/O8yf+ OJde8KI73kFi5yp/Mv2LYgvzf/KmPUtheu3Kh7eUEUhfCQ7oiK01q9g7pve78k5G /U0QnMXXMc0VJ/zhVg/vpMoAYk8fLNNFybgME6LVy/b0ltzP4NRLZwv3H5aqBQdT 43Uy8sy/2KO4PeplJB6jJZcivLUD6Nthby/SSDPIzPqK8jVsOycFPYSBqAwp60s= =xP2R -----END PGP SIGNATURE----- --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv-- From nobody Mon Mar 9 05:21:37 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 511AF1A8863; Mon, 9 Mar 2015 05:21:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3255E1A87EB; Mon, 9 Mar 2015 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXzBdEfzwAwy; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A7F1A87E4; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8B0178814A; Mon, 9 Mar 2015 05:21:29 -0700 (PDT) Received: from Brians-MacBook-Pro.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D111771B0001; Mon, 9 Mar 2015 05:21:28 -0700 (PDT) Message-ID: <54FD9043.7000702@innovationslab.net> Date: Mon, 09 Mar 2015 08:21:23 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: rob.shakir@bt.com, shares@ndzh.com, iesg@ietf.org References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tbfParc86IqrfWe2RUG34dVP2SuPDeBgv" Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, idr-chairs@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:21:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rob, Thanks for continuing this conversation... On 3/8/15 2:49 PM, rob.shakir@bt.com wrote: >=20 > Hi Brian, >=20 >=20 > [06/03/2015 21:09, "Brian Haberman" ] >=20 >> Hi Rob, >> >> On 3/6/15 3:59 PM, rob.shakir@bt.com wrote: >>> >>> >> >> The above is quite clear and shows me how I think I misread the second= >> paragraph. I read it has saying the operator SHOULD identify the >> offending route and trace it back to its ingress into the network. Th= e >> description above sounds like the text is saying the router SHOULD >> provide enough information so that the operator knows to trace the >> offending route. >=20 > In my view, it=B9s both. >=20 > If we have erroneous UPDATEs that are being transmitted by a router, th= is > means that something, somewhere is wrong. It=B9s not really desirable f= or > there to be routing updates that are known to have issues present in th= e > system, and as such an operator should really examine this and fix it. > Today, they have to do so, as the router transmitting the error is like= ly > to be disconnected from the network (or some other system downstream wi= ll > be, due to it transmitting the erroneous message). >=20 > The recommendation is maybe stating something obvious, but I see no har= m > in having it in the document - we should remind people that transmittin= g > an erroneous UPDATE is still a BadThing (tm), and is likely to be causi= ng > log messages for all other operators that see it in the DFZ. The best > practice is clearly to clean up the error. I agree that it belongs in the document, but it appears to me to be a little opaque. I read the text in the draft as strictly something the operator has to worry about. The description you provided indicated that there needs to be sufficient notification from the router so that the operator can act on it. Perhaps what is needed is just a little clarification. Given that I raised this as a Comment, making any changes is really up to the authors/WG/AD. My thought would be a slight re-wording of the 2nd paragraph to indicate that the router needs to provide a notification when a malformed attribute is detected. That then provides the input needed for the operator to act on the recommendation in the section. Regards, Brian --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU/ZBJAAoJEBOZRqCi7goqGHsH/3XhsaXt9ve9egirj0Rol6iW SRxOjZ00hbmAFuABK1BjXPkEpFv5UdHXR1Uxzq/b+XHBbLEF0vfIlQUE/dssOIi8 W9jAjezwCtFtUjKkvS6EB99hlVZVbVwNRAmhfMqAlty+VaQA+h1ykNW7R5/O8yf+ OJde8KI73kFi5yp/Mv2LYgvzf/KmPUtheu3Kh7eUEUhfCQ7oiK01q9g7pve78k5G /U0QnMXXMc0VJ/zhVg/vpMoAYk8fLNNFybgME6LVy/b0ltzP4NRLZwv3H5aqBQdT 43Uy8sy/2KO4PeplJB6jJZcivLUD6Nthby/SSDPIzPqK8jVsOycFPYSBqAwp60s= =xP2R -----END PGP SIGNATURE----- --tbfParc86IqrfWe2RUG34dVP2SuPDeBgv-- From nobody Mon Mar 9 07:19:41 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9881A89A5 for ; Mon, 9 Mar 2015 07:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpH_ljX337JB for ; Mon, 9 Mar 2015 07:19:34 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47421A89A1 for ; Mon, 9 Mar 2015 07:18:39 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t29EIO1I062533 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2015 14:18:25 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54FDABAE.8080900@foobar.org> Date: Mon, 09 Mar 2015 14:18:22 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Robert Raszuk , idr wg References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 14:19:40 -0000 Hi Robert, On 07/03/2015 23:08, Robert Raszuk wrote: > Name: draft-raszuk-wide-bgp-communities > Revision: 05 > Title: Wide BGP Communities Attribute thanks for picking this up. The operational community desperately needs support for a minimum of 32b:32b communities as there is a dwindling supply of 16 bit ASNs and running a functional network using the current bgp community mechanisms (all of which have 48 bits of community space) is not feasible at this time. I've tried this on a production network; it doesn't work. The network I set up had to be renumbered to an ASN16. wide-bgp-communities is a great idea in theory, but it's far too complicated in practice. This means that it will be difficult to code, to debug and to get good quality vendor interoperability. It also presents the operator with a bewildering range of options, many of which are unlikely to ever be used. The complication in the specification also creates a secondary problem for router vendors in updating their policy languages so that they can interpret wide bgp communities. Overall, this is not compatible with the engineering principal of "keep things as simple as possible - but no simpler". Suggestions: 1. Would it be possible to ditch: > Type 5: IEEE Floating Point Number list > Type 6: Neighbor Class list > Type 7: User-defined Class list 2. Simplify, or at least explain why this needs needs to be so complicated: > 4. Container Type 1: Wide Community 3. provide some guidance about deletion or modification of parts of the community attribute entries, particularly in the context of: > The Wide BGP Community Attribute is an optional, transitive BGP > attribute, and may be present only once in the BGP UPDATE message. 4. discussion of how implementing this is going to shake out structural problems in vendors' routing policy grammars, with associated security implications if the grammars are incapable of handling the complication that this draft introduces. 5. I love the idea of UTF8 communities. On smaller network, these could be a real win. 6. I'm guessing that the structure of container type 1 is designed to accommodate the construction that's widely used on the internet. This requires a pretty serious grammar to allow for proper parameter checking. Nick From nobody Mon Mar 9 08:25:18 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B44D1A8991 for ; Mon, 9 Mar 2015 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8t9XcHKFfDa for ; Mon, 9 Mar 2015 08:25:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AC9531A901E for ; Mon, 9 Mar 2015 08:16:17 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 620ABC17B; Mon, 9 Mar 2015 11:16:17 -0400 (EDT) Date: Mon, 9 Mar 2015 11:16:17 -0400 From: Jeffrey Haas To: Nick Hilliard Message-ID: <20150309151617.GC14435@pfrc> References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> <54FDABAE.8080900@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54FDABAE.8080900@foobar.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:25:16 -0000 Nick, On Mon, Mar 09, 2015 at 02:18:22PM +0000, Nick Hilliard wrote: > The operational community desperately needs support for a minimum of > 32b:32b communities as there is a dwindling supply of 16 bit ASNs and > running a functional network using the current bgp community mechanisms > (all of which have 48 bits of community space) is not feasible at this time. Much as I'm obviously a fan of wide communities, there's a different draft covering this much more simple use case: http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-07 > wide-bgp-communities is a great idea in theory, but it's far too > complicated in practice. This means that it will be difficult to code, to > debug and to get good quality vendor interoperability. It also presents the > operator with a bewildering range of options, many of which are unlikely to > ever be used. Operators are already using this bewildering set of options: Complex Policy to implement common use cases. The goal for this proposal is to unroll some of that policy from the policy engine and put it more into the signaling. > 5. I love the idea of UTF8 communities. On smaller network, these could be > a real win. This is actually the piece I like the least. :-) > 6. I'm guessing that the structure of container type 1 is designed to > accommodate the construction that's > widely used on the internet. This requires a pretty serious grammar to > allow for proper parameter checking. That's actually the best and most common use case. If we get this simple policy algebra deployable and nothing else, it's still a win. -- Jeff From nobody Mon Mar 9 08:44:52 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FE21A700B for ; Mon, 9 Mar 2015 08:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egGVEP_JIrY6 for ; Mon, 9 Mar 2015 08:44:47 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CFA1A898F for ; Mon, 9 Mar 2015 08:41:17 -0700 (PDT) X-Envelope-To: idr@ietf.org Received: from crumpet.local (089-101-195154.ntlworld.ie [89.101.195.154] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.1/8.14.9) with ESMTPSA id t29Ff34v064330 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2015 15:41:04 GMT (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.netability.ie: Host 089-101-195154.ntlworld.ie [89.101.195.154] (may be forged) claimed to be crumpet.local Message-ID: <54FDBF0D.7010901@foobar.org> Date: Mon, 09 Mar 2015 15:41:01 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> <54FDABAE.8080900@foobar.org> <20150309151617.GC14435@pfrc> In-Reply-To: <20150309151617.GC14435@pfrc> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: idr wg , Robert Raszuk Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:44:50 -0000 On 09/03/2015 15:16, Jeffrey Haas wrote: > Much as I'm obviously a fan of wide communities, there's a different draft > covering this much more simple use case: > > http://tools.ietf.org/html/draft-ietf-idr-as4octet-extcomm-generic-subtype-07 yep, this has come up before on idr@. This is 32b:16b, which doesn't provide enough space in the local administrator field for production networks. > Operators are already using this bewildering set of options: Complex Policy to > implement common use cases. The goal for this proposal is to unroll some of > that policy from the policy engine and put it more into the signaling. Which is reasonable, but it's going to cause severe indigestion for some router vendor grammars which don't have the structural hooks necessary to be able to handle this sensibly. >> 5. I love the idea of UTF8 communities. On smaller network, these could be >> a real win. > > This is actually the piece I like the least. :-) Indeed. I configure routers for a living, whereas you design them. We all have our own angles on stuff. Nick From nobody Mon Mar 9 08:55:21 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE08A1A8734; Mon, 9 Mar 2015 08:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvFO_Eh1j4Be; Mon, 9 Mar 2015 08:55:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D041A8A74; Mon, 9 Mar 2015 08:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309155502.12191.6970.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:55:02 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-vandevelde-idr-remote-next-hop-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:55:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Remote-Next-Hop Authors : Gunter Van de Velde Keyur Patel Dhananjaya Rao Robert Raszuk Randy Bush Filename : draft-vandevelde-idr-remote-next-hop-09.txt Pages : 17 Date : 2015-03-09 Abstract: The BGP Remote-Next-Hop attribute is an optional transitive attribute intended to facilitate automatic tunnelling across an AS for an NLRI in a given address family. The attribute carries one or more tunnel end-points and associated tunnel encapsulation information for a NLRI. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-remote-next-hop-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 08:55:33 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636D1A8A4B; Mon, 9 Mar 2015 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC-G-gQ8sdVD; Mon, 9 Mar 2015 08:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98F1A8A78; Mon, 9 Mar 2015 08:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309155502.12191.79492.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:55:02 -0700 Archived-At: Subject: [Idr] New Version Notification - draft-vandevelde-idr-remote-next-hop-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:55:20 -0000 A new version (-09) has been submitted for draft-vandevelde-idr-remote-next-hop: http://www.ietf.org/internet-drafts/draft-vandevelde-idr-remote-next-hop-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-remote-next-hop-09 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. IETF Secretariat. From nobody Mon Mar 9 08:55:34 2015 Return-Path: X-Original-To: expand-draft-vandevelde-idr-remote-next-hop.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B24021A8A74; Mon, 9 Mar 2015 08:55:20 -0700 (PDT) X-Original-To: xfilter-draft-vandevelde-idr-remote-next-hop.all@ietfa.amsl.com Delivered-To: xfilter-draft-vandevelde-idr-remote-next-hop.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636D1A8A4B; Mon, 9 Mar 2015 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC-G-gQ8sdVD; Mon, 9 Mar 2015 08:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98F1A8A78; Mon, 9 Mar 2015 08:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309155502.12191.79492.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:55:02 -0700 Archived-At: Subject: [Idr] New Version Notification - draft-vandevelde-idr-remote-next-hop-09.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:55:20 -0000 A new version (-09) has been submitted for draft-vandevelde-idr-remote-next-hop: http://www.ietf.org/internet-drafts/draft-vandevelde-idr-remote-next-hop-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-vandevelde-idr-remote-next-hop-09 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. IETF Secretariat. From nobody Mon Mar 9 10:45:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFAC1A9092; Mon, 9 Mar 2015 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzW9YCQ6Yinf; Mon, 9 Mar 2015 10:45:15 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CC21A908C; Mon, 9 Mar 2015 10:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8745; q=dns/txt; s=iport; t=1425923116; x=1427132716; h=from:to:cc:subject:date:message-id:mime-version; bh=8RL8NjgF5S6iGl+QBQ0mnxs0k44pcLYBYObFJsjSUcg=; b=ZzX6cCev0vQniIhVGPSL5qMgB1fkbNy2y010lY3TdlAyrIIJngHt+HXZ PS3t+bwSGfe6ibdqXDRPrlZt0/6VZCAwHdKMBNnXRaK1JBChGMBTtEMzB AuPNEtBPYczYzNzGwLw+JDfLWbtCm3AyqSCRfN0+eA9M32A1CGIClfkDC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQC82/1U/4YNJK1bgkNDgTDIWYEsTQEBAQEBAXyEFnkSARZqJwQOIQOIEMEfAQEBAQEFAQEBAQEBARuLF4RuhDQFjg2CAolTgRqFfIV/hl8jg26BcQY8fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="130295896" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 09 Mar 2015 17:45:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t29HjEiS013917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 17:45:14 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.60]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 12:45:14 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas Thread-Topic: Review of draft-ietf-idr-error-handling-18 Thread-Index: AQHQWpDLKAsEqqfj4UCra5AsX2rR0w== Date: Mon, 9 Mar 2015 17:45:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.9] Content-Type: multipart/alternative; boundary="_000_D12354889A4A0aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "idr-chairs@ietf.org" , "rob.shakir@bt.com" , "draft-ietf-idr-error-handling.all@ietf.org" Subject: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:45:17 -0000 --_000_D12354889A4A0aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alia: Hi! As part of my AD training, I have done a review of this draft. I have some= comments, none of which should delay the publication. 1. This document is marked as updating many RFCs. It would be very nice= if there was a section that summarized the updates =97 pointing to the det= ails is ok. Section 3 does a good job in detailing the changes to rfc4271,= but there are other updates elsewhere (section 7.7, for example). What I= =92m suggesting is a section that basically says: "rfc4271 is updated by ch= anging the handling of path attribute errors (Section 3), the ORIGIN (Secti= on 7.1), etc.=94 Maybe it=92s just me, but I like to be able to find the u= pdates in one place (at least a summary). 2. Nit: s/revised/updated Related to the last point, when looking t= hrough a document for updates, searching for the work =93update=94 makes it= easier.. The authors chose the word =93revised=94, which is a perfectly g= ood word, but it is not the =93official=94 term used when an RFC is changed= . Yes, it=92s a nit.. 3. Section 3 talks about updates to rfc4271, and it includes this text i= n bullet h: "When multiple attribute errors exist in an UPDATE message, if = the same approach (either "session reset", "treat-as-withdraw=94 or "attrib= ute discard") is specified for the handling of these malformed attributes, = then the specified approach MUST be used. Otherwise the approach with the = strongest action MUST be used.=94 Given that multiple RFCs are updated, it= seems to me like this consideration is applicable not just to rfc4271 (eve= n though it is the base), so it might be a good idea to include the same (o= r at least similar) text in Section 2 (where the approaches are defined and= discussed). 4. Section 6 (Operational Considerations) includes several rfc2119 keywo= rds. I read the thread with Brian Haberman about clarifying what is expect= ed from the operator and what the implementation should do; I agree that th= is section should be clarified so that the operational recommendations are = clear and separate from the actions that an implementation can take. For e= xample: =93.. such facilities MUST include logging an error listing the NLR= I involved, and containing the entire malformed UPDATE message when such an= attribute is detected. The malformed UPDATE message SHOULD be analyzed, a= nd the root cause SHOULD be investigated.=94 Logging is definitely the job= of the implementation..while other actions such as investigating clearly w= ould fall on the operator.. 5. Security Considerations (Section 10). It is true that malformed opti= onal transitive attributes should not cause remote session resets. Are rem= ote withdrawals a new threat? Following the logic in the introduction, an = update with a malformed optional transitive attribute may not be properly c= hecked for several hops..but once the error is detected then the NLRI may u= se Treat-as-withdraw.. Assuming an AS-level granularity in checking, this = won=92t cause loops or major disruptions, but nonetheless it can result in = not everyone receiving the information it should.. Thanks! Alvaro. --_000_D12354889A4A0aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9545734E3A02BF46950EAC9808854D82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Alia:

Hi!

As part of my AD training, I have done a review of this draft.  I have= some comments, none of which should delay the publication.
  1. This document is marked as updating many RFCs.  It would be very nice = if there was a section that summarized the updates =97 pointing to the deta= ils is ok.  Section 3 does a good job in detailing the changes to rfc4= 271, but there are other updates elsewhere (section 7.7, for example).  What I=92m suggesting is a section that basically= says: "rfc4271 is updated by changing the handling of path attribute = errors (Section 3), the ORIGIN (Section 7.1), etc.=94  Maybe it=92s ju= st me, but I like to be able to find the updates in one place (at least a summary).
  2. Nit:  s/revised/updated     Related to the last point, when = looking through a document for updates, searching for the work =93update=94= makes it easier..  The authors chose the word =93revised=94, which is= a perfectly good word, but it is not the =93official=94 term used when an RFC is changed.   Yes, it=92s a nit..
  3. Section 3 talks about updates to rfc4271, and it include= s this text in bullet h: "When multiple attribute errors exist in an UPDATE message, if = the same approach (either "session reset", "treat-as-withdraw=94&nbs= p;or "at= tribute discard") is specified for the handling of these <= span style=3D"font-family: Calibri, sans-serif;">malformed attributes, then= the specified approach MUST be used.  Otherwise the approach with the strongest action MUST be used.=94 &nb= sp;Given that multiple RFCs are updated, it seems to me like this considera= tion is applicable not just to rfc4271 (even though it is the base), so it might be a good idea to include the same (or at lea= st similar) text in Section 2 (where the approaches are defined and discuss= ed).
  4. Section 6 (Operationa= l Considerations) includes several rfc2119 keywords.  I read the threa= d with Brian Haberman about clarifying what is expected from the operator a= nd what the implementation should do; I agree that this section should be clarified so that the operational recommendations a= re clear and separate from the actions that an implementation can take. &nb= sp;For example: =93.. such facilities MUST include logging an error listing the NLRI involved, and containing the entire malformed UPDATE message whe= n such an attribute is detected.  The malformed UPDATE message SHOULD be analyzed, and the root cause SHOULD be investigated.=94  Logging is definitely the job o= f the implementation..while other actions such as investigating clearly wou= ld fall on the operator..
  5. Security Considerations (Section 1= 0).  It is true that malformed optional transitive attributes should n= ot cause remote session resets.  Are remote withdrawals a new threat? =  Following the logic in the introduction, an update with a malformed o= ptional transitive attribute may not be properly checked for several hops..but once the error= is detected then the NLRI may use Treat-as-withdraw..  Assuming = an AS-level granularity in checking, this won=92t cause loops or major disr= uptions, but nonetheless it can result in not everyone receiving the information it should..
Thanks!

Alvaro.

--_000_D12354889A4A0aretanaciscocom_-- From nobody Mon Mar 9 10:45:21 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A6A9D1A9096; Mon, 9 Mar 2015 10:45:17 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFAC1A9092; Mon, 9 Mar 2015 10:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzW9YCQ6Yinf; Mon, 9 Mar 2015 10:45:15 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CC21A908C; Mon, 9 Mar 2015 10:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8745; q=dns/txt; s=iport; t=1425923116; x=1427132716; h=from:to:cc:subject:date:message-id:mime-version; bh=8RL8NjgF5S6iGl+QBQ0mnxs0k44pcLYBYObFJsjSUcg=; b=ZzX6cCev0vQniIhVGPSL5qMgB1fkbNy2y010lY3TdlAyrIIJngHt+HXZ PS3t+bwSGfe6ibdqXDRPrlZt0/6VZCAwHdKMBNnXRaK1JBChGMBTtEMzB AuPNEtBPYczYzNzGwLw+JDfLWbtCm3AyqSCRfN0+eA9M32A1CGIClfkDC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQC82/1U/4YNJK1bgkNDgTDIWYEsTQEBAQEBAXyEFnkSARZqJwQOIQOIEMEfAQEBAQEFAQEBAQEBARuLF4RuhDQFjg2CAolTgRqFfIV/hl8jg26BcQY8fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208,217";a="130295896" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 09 Mar 2015 17:45:15 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t29HjEiS013917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 17:45:14 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.60]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 12:45:14 -0500 From: "Alvaro Retana (aretana)" To: Alia Atlas Thread-Topic: Review of draft-ietf-idr-error-handling-18 Thread-Index: AQHQWpDLKAsEqqfj4UCra5AsX2rR0w== Date: Mon, 9 Mar 2015 17:45:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.9] Content-Type: multipart/alternative; boundary="_000_D12354889A4A0aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "idr-chairs@ietf.org" , "rob.shakir@bt.com" , "draft-ietf-idr-error-handling.all@ietf.org" Subject: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:45:17 -0000 --_000_D12354889A4A0aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alia: Hi! As part of my AD training, I have done a review of this draft. I have some= comments, none of which should delay the publication. 1. This document is marked as updating many RFCs. It would be very nice= if there was a section that summarized the updates =97 pointing to the det= ails is ok. Section 3 does a good job in detailing the changes to rfc4271,= but there are other updates elsewhere (section 7.7, for example). What I= =92m suggesting is a section that basically says: "rfc4271 is updated by ch= anging the handling of path attribute errors (Section 3), the ORIGIN (Secti= on 7.1), etc.=94 Maybe it=92s just me, but I like to be able to find the u= pdates in one place (at least a summary). 2. Nit: s/revised/updated Related to the last point, when looking t= hrough a document for updates, searching for the work =93update=94 makes it= easier.. The authors chose the word =93revised=94, which is a perfectly g= ood word, but it is not the =93official=94 term used when an RFC is changed= . Yes, it=92s a nit.. 3. Section 3 talks about updates to rfc4271, and it includes this text i= n bullet h: "When multiple attribute errors exist in an UPDATE message, if = the same approach (either "session reset", "treat-as-withdraw=94 or "attrib= ute discard") is specified for the handling of these malformed attributes, = then the specified approach MUST be used. Otherwise the approach with the = strongest action MUST be used.=94 Given that multiple RFCs are updated, it= seems to me like this consideration is applicable not just to rfc4271 (eve= n though it is the base), so it might be a good idea to include the same (o= r at least similar) text in Section 2 (where the approaches are defined and= discussed). 4. Section 6 (Operational Considerations) includes several rfc2119 keywo= rds. I read the thread with Brian Haberman about clarifying what is expect= ed from the operator and what the implementation should do; I agree that th= is section should be clarified so that the operational recommendations are = clear and separate from the actions that an implementation can take. For e= xample: =93.. such facilities MUST include logging an error listing the NLR= I involved, and containing the entire malformed UPDATE message when such an= attribute is detected. The malformed UPDATE message SHOULD be analyzed, a= nd the root cause SHOULD be investigated.=94 Logging is definitely the job= of the implementation..while other actions such as investigating clearly w= ould fall on the operator.. 5. Security Considerations (Section 10). It is true that malformed opti= onal transitive attributes should not cause remote session resets. Are rem= ote withdrawals a new threat? Following the logic in the introduction, an = update with a malformed optional transitive attribute may not be properly c= hecked for several hops..but once the error is detected then the NLRI may u= se Treat-as-withdraw.. Assuming an AS-level granularity in checking, this = won=92t cause loops or major disruptions, but nonetheless it can result in = not everyone receiving the information it should.. Thanks! Alvaro. --_000_D12354889A4A0aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9545734E3A02BF46950EAC9808854D82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Alia:

Hi!

As part of my AD training, I have done a review of this draft.  I have= some comments, none of which should delay the publication.
  1. This document is marked as updating many RFCs.  It would be very nice = if there was a section that summarized the updates =97 pointing to the deta= ils is ok.  Section 3 does a good job in detailing the changes to rfc4= 271, but there are other updates elsewhere (section 7.7, for example).  What I=92m suggesting is a section that basically= says: "rfc4271 is updated by changing the handling of path attribute = errors (Section 3), the ORIGIN (Section 7.1), etc.=94  Maybe it=92s ju= st me, but I like to be able to find the updates in one place (at least a summary).
  2. Nit:  s/revised/updated     Related to the last point, when = looking through a document for updates, searching for the work =93update=94= makes it easier..  The authors chose the word =93revised=94, which is= a perfectly good word, but it is not the =93official=94 term used when an RFC is changed.   Yes, it=92s a nit..
  3. Section 3 talks about updates to rfc4271, and it include= s this text in bullet h: "When multiple attribute errors exist in an UPDATE message, if = the same approach (either "session reset", "treat-as-withdraw=94&nbs= p;or "at= tribute discard") is specified for the handling of these <= span style=3D"font-family: Calibri, sans-serif;">malformed attributes, then= the specified approach MUST be used.  Otherwise the approach with the strongest action MUST be used.=94 &nb= sp;Given that multiple RFCs are updated, it seems to me like this considera= tion is applicable not just to rfc4271 (even though it is the base), so it might be a good idea to include the same (or at lea= st similar) text in Section 2 (where the approaches are defined and discuss= ed).
  4. Section 6 (Operationa= l Considerations) includes several rfc2119 keywords.  I read the threa= d with Brian Haberman about clarifying what is expected from the operator a= nd what the implementation should do; I agree that this section should be clarified so that the operational recommendations a= re clear and separate from the actions that an implementation can take. &nb= sp;For example: =93.. such facilities MUST include logging an error listing the NLRI involved, and containing the entire malformed UPDATE message whe= n such an attribute is detected.  The malformed UPDATE message SHOULD be analyzed, and the root cause SHOULD be investigated.=94  Logging is definitely the job o= f the implementation..while other actions such as investigating clearly wou= ld fall on the operator..
  5. Security Considerations (Section 1= 0).  It is true that malformed optional transitive attributes should n= ot cause remote session resets.  Are remote withdrawals a new threat? =  Following the logic in the introduction, an update with a malformed o= ptional transitive attribute may not be properly checked for several hops..but once the error= is detected then the NLRI may use Treat-as-withdraw..  Assuming = an AS-level granularity in checking, this won=92t cause loops or major disr= uptions, but nonetheless it can result in not everyone receiving the information it should..
Thanks!

Alvaro.

--_000_D12354889A4A0aretanaciscocom_-- From nistor@torix.ca Mon Mar 9 11:35:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2F1A9239 for ; Mon, 9 Mar 2015 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmDjKCVMGFke for ; Mon, 9 Mar 2015 11:35:09 -0700 (PDT) Received: from mail.snickers.org (snickers.org [204.11.50.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBF11A916D for ; Mon, 9 Mar 2015 11:35:09 -0700 (PDT) Received: by mail.snickers.org (Postfix, from userid 58) id 751D03AC842; Mon, 9 Mar 2015 14:35:08 -0400 (EDT) Received: from snickers.org (snickers.org [204.11.50.150]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.snickers.org (Postfix) with ESMTPS id 43DD93AC80F for ; Mon, 9 Mar 2015 14:35:08 -0400 (EDT) Date: Mon, 9 Mar 2015 14:35:07 -0400 (EDT) From: Jon Nistor X-X-Sender: nistor@spike.snickers.org To: idr@ietf.org Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:35:28 -0000 Hello team, I strongly support the adoption of draft-ymbk-idr-rs-bfd-00. As an operator of an IXP for more than a decade it's great to see these types of innovations. Cheers, Jon Nistor Toronto Internet Exchange From nobody Mon Mar 9 12:54:13 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095A1AC3DB for ; Mon, 9 Mar 2015 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sdlDWV_UdgV for ; Mon, 9 Mar 2015 12:54:06 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDF21A92EF for ; Mon, 9 Mar 2015 12:54:05 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id F0E2625EABAF8; Mon, 9 Mar 2015 19:54:01 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t29Js28v006298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 15:54:02 -0400 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.61]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 15:54:02 -0400 From: "Simpson, Adam (Adam)" To: Susan Hares , idr wg Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQWqLKjxO0fVRdzkCpDRp92JkCng== Date: Mon, 9 Mar 2015 19:54:02 +0000 Message-ID: References: <007601d05518$e031f1d0$a095d570$@ndzh.com> In-Reply-To: <007601d05518$e031f1d0$a095d570$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_D12372605ECE5adamsimpsonalcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:54:09 -0000 --_000_D12372605ECE5adamsimpsonalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support WG adoption. I think it=92s a legitimate problem for the WG to addr= ess. From: Susan Hares > Date: Monday, March 2, 2015 at 2:44 PM To: idr wg > Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/20= 15 to 3/16/2015) This begins a 2 week WG Adoption call for draft-ymbk-idr-rs-bfd-00.txt Please review and comment on this draft and indicate why this is useful to = add to the BGP mechanism. In your comments please include =93support=94 o= r =93no support=94 for the WG Adoption of this draft. Sue Hares and John Scudder --_000_D12372605ECE5adamsimpsonalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3D93441065145A4EAB0099519D285288@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Support WG adoption. I think it=92s a legitimate problem for the WG to= address.

From: Susan Hares <shares@ndzh.com>
Date: Monday, March 2, 2015 at 2:44= PM
To: idr wg <idr@ietf.org>
Subject: [Idr] 2 Week WG Adoption c= all for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)

This begins a 2 week WG Adoption call for draft-ymbk= -idr-rs-bfd-00.txt

 

Please review and comment on this draft and indicate= why this is useful to add to the BGP mechanism.   In your commen= ts please include =93support=94 or =93no support=94 for the WG Adoption of = this draft.

 

Sue Hares and John Scudder

--_000_D12372605ECE5adamsimpsonalcatellucentcom_-- From nobody Mon Mar 9 13:11:55 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74C01A92B3 for ; Mon, 9 Mar 2015 13:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRfJ3Qx9YlvR for ; Mon, 9 Mar 2015 13:11:51 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BDB1AC409 for ; Mon, 9 Mar 2015 13:11:44 -0700 (PDT) Received: by qcwr17 with SMTP id r17so5280355qcw.11 for ; Mon, 09 Mar 2015 13:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=goYGgOBn7MKtb6mN/WY3nD64+AKGUkDWQX94JtdH9ro=; b=d7xjMqfre2rjOE2ykFr26PEbv3tzwVBk28pchVU8ybrNis5VqiKhQcPcgiXfevjMsq hjtrBHOtkUcph0rxOBgc5V247LW751uT2PScqVJfq8Q9Ltvjg8nZZIPShi9bqtYFKRHD pXMjhE1Nzd+Ak38yXFGB67a0HTSue4sWcdkhS9ksBDOuYH8p0yK10/UaGxKaeYGP9Q+K c1mJjj6BDKNH1vaZWmfEcroKyr7pcaE7XRa+kOxxLCrBsXH8WY+092lZOGyN1d78fiqA jcSKpjTcI/maYPhU9sS6BhASY2vKTLdoBJ/9TCaG1vPHD8ftRUscIx3Bjd60znoeoAm8 BnZw== MIME-Version: 1.0 X-Received: by 10.140.28.36 with SMTP id 33mr36662256qgy.6.1425931903758; Mon, 09 Mar 2015 13:11:43 -0700 (PDT) Received: by 10.96.15.198 with HTTP; Mon, 9 Mar 2015 13:11:43 -0700 (PDT) In-Reply-To: References: <007601d05518$e031f1d0$a095d570$@ndzh.com> Date: Tue, 10 Mar 2015 01:41:43 +0530 Message-ID: From: suprita To: "Simpson, Adam (Adam)" Content-Type: multipart/alternative; boundary=001a113a9a6498f90b0510e0a4a2 Archived-At: Cc: idr wg , Susan Hares Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:11:54 -0000 --001a113a9a6498f90b0510e0a4a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Support adoption by WG. The draft is solving a genuine issue. Regards, Suprita On Tue, Mar 10, 2015 at 1:24 AM, Simpson, Adam (Adam) < adam.simpson@alcatel-lucent.com> wrote: > Support WG adoption. I think it=E2=80=99s a legitimate problem for the W= G to > address. > > From: Susan Hares > Date: Monday, March 2, 2015 at 2:44 PM > To: idr wg > Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 > (3/2/2015 to 3/16/2015) > > This begins a 2 week WG Adoption call for draft-ymbk-idr-rs-bfd-00.txt > > > > Please review and comment on this draft and indicate why this is useful t= o > add to the BGP mechanism. In your comments please include =E2=80=9Csupp= ort=E2=80=9D or > =E2=80=9Cno support=E2=80=9D for the WG Adoption of this draft. > > > > Sue Hares and John Scudder > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --001a113a9a6498f90b0510e0a4a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support adoption by WG. The draft is solving a genuine iss= ue.

Regards,
Suprita

On Tue, Mar 10, 2015 at 1:24 AM= , Simpson, Adam (Adam) <adam.simpson@alcatel-lucent.com&= gt; wrote:
Support WG adoption. I think it=E2=80=99s a legitimate problem for the= WG to address.

From: Susan Hares <shares@ndzh.com>
Date: Monday, March 2, 2015 at 2:44= PM
To: idr wg <idr@ietf.org>
Subject: [Idr] 2 Week WG Adoption c= all for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015)

This begins a 2 week WG Adoption call for draft-ymbk= -idr-rs-bfd-00.txt

=C2=A0

Please review and comment on this draft and indicate= why this is useful to add to the BGP mechanism.=C2=A0 =C2=A0In your commen= ts please include =E2=80=9Csupport=E2=80=9D or =E2=80=9Cno support=E2=80=9D= for the WG Adoption of this draft.

=C2=A0

Sue Hares and John Scudder


_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr


--001a113a9a6498f90b0510e0a4a2-- From nobody Mon Mar 9 14:42:37 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7031A90BE for ; Mon, 9 Mar 2015 14:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crf9Gdx2r1tm for ; Mon, 9 Mar 2015 14:42:31 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6391A901F for ; Mon, 9 Mar 2015 14:42:13 -0700 (PDT) Received: by igjz20 with SMTP id z20so25390213igj.4 for ; Mon, 09 Mar 2015 14:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n0DLaYO4+BH3MdbS18qq38AkH+uQAHEA+XaxCv/roGw=; b=Cvip7JkKp+UVbJPJFoovUDUSo4I5VO2hdxlRpbih4YybuhC+3OYKVQXtV/OFOh4Gdy 5uD1xFgkGVggnsrIdzHTRZ7QLZ7n0VhzFgMSdLAOqr+PCiS8hu+8rINTu27GMF4PCB15 mUG5cYVOuD7ETVt4abVGvLlctyCcjpSIlsixcnwclBam4U2n81EDmPhZjEY1TuZ+S0xY LrUFIEqTN1k9yurmmAOBTlzUC4iUPPRZUzWn+MCOBn9ysITnHAG0LDMMGCUBN8ElMVDD 6mPAaLefpQHf7OFzJ497luP2+SQaTb5fHErAf7rwFo3ZCve1r9Vou75RrRIZMG7LNaD9 jPUA== MIME-Version: 1.0 X-Received: by 10.50.137.99 with SMTP id qh3mr74091886igb.9.1425937332819; Mon, 09 Mar 2015 14:42:12 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.70 with HTTP; Mon, 9 Mar 2015 14:42:12 -0700 (PDT) In-Reply-To: <54FDABAE.8080900@foobar.org> References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> <54FDABAE.8080900@foobar.org> Date: Mon, 9 Mar 2015 22:42:12 +0100 X-Google-Sender-Auth: PH37CP0c9h9ppchzaRUr_IdwaOI Message-ID: From: Robert Raszuk To: Nick Hilliard Content-Type: multipart/alternative; boundary=001a11c3bcbc31de1a0510e1e859 Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:42:33 -0000 --001a11c3bcbc31de1a0510e1e859 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nick, wide-bgp-communities is a great idea in theory, but it's far too > complicated in practice. This means that it will be difficult to code, t= o > debug and to get good quality vendor interoperability. It also presents t= he > operator with a bewildering range of options, many of which are unlikely = to > ever be used. > =E2=80=8BWell we have tried to make it to include build in algebra for the = last few years .. finally we reverted to original basic encoding idea. I think at this stage the encoding proposed is pretty easy to code. However the policy of any implementation needs to be able to handle local actions as well as registered and private types/definitions. If this it too complicated in practice I do not know. Many people says BGP is complicated, but for me it is as simple or as complex as one makes it to be. But we are open for comments and contributions from everyone here. > The complication in the specification also creates a secondary problem fo= r > router vendors in updating their policy languages so that they can > interpret wide bgp communities. > =E2=80=8BIndeed .. just like I mentioned above. The use flexibility is in t= he policy language and parser. Good news is that current version seems to get thumbs up from many vendors. =E2=80=8B > Overall, this is not compatible with the engineering principal of "keep > things as simple as possible - but no simpler". > =E2=80=8BNot sure I get that one. Are you saying if we follow what you sugg= est below it will meet such criteria or regardless it will stay incompatible ? I do encourage to read the companion draft showing registered types for the use cases. I am not sure how much simplere those could be ...=E2=80=8B Suggestions: > > 1. Would it be possible to ditch: > > > Type 5: IEEE Floating Point Number list > > Type 6: Neighbor Class list > > Type 7: User-defined Class list > =E2=80=8BWell if you ask me I am all for it. No issue. =E2=80=8BThat is also the reason why we demux at the types below the attrib= ute. If tomorrow someone comes and says I must have floating atoms there is no need to define new Wide BGP Community attribute with those. > 2. Simplify, or at least explain why this needs needs to be so complicate= d: > > > 4. Container Type 1: Wide Community > =E2=80=8BJust explained above. =E2=80=8B > 3. provide some guidance about deletion or modification of parts of the > community attribute entries, particularly in the context of: > > > The Wide BGP Community Attribute is an optional, transitive BGP > > attribute, and may be present only once in the BGP UPDATE message. > =E2=80=8BNot sure what you mean by "parts". The deletion at least the way I= see it should be per type (registered or private) or per attribute. =E2=80=8B > 4. discussion of how implementing this is going to shake out structural > problems in vendors' routing policy grammars, with associated security > implications if the grammars are incapable of handling the complication > that this draft introduces. > =E2=80=8BIndeed this is vendor dependent. But should we stop propose anything in BGP if anyone would have a problem implementing it ? I was under impression that two implementations are enough for IDR to progress the doc to last call. =E2=80=8B > 5. I love the idea of UTF8 communities. On smaller network, these could = be > a real win. > =E2=80=8BYup.=E2=80=8B 6. I'm guessing that the structure of container type 1 is designed to > accommodate the construction that's > widely used on the internet. This requires a pretty serious grammar to > allow for proper parameter checking. > > =E2=80=8BI think you did not read the companion draft :) Please do. Yes this is one very fundamental use cases here. Many thx for your comments, r.=E2=80=8B > Nick > --001a11c3bcbc31de1a0510e1e859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Nick,

wide-bgp-communities is a great idea in theory, but it's far too complicated in practice.=C2=A0 This means that it will be difficult to code= , to
debug and to get good quality vendor interoperability. It also presents the=
operator with a bewildering range of options, many of which are unlikely to=
ever be used.

= =E2=80=8BWell we have tried to make it to include build in algebra for the = last few years .. finally we reverted to original basic encoding idea.=C2= =A0

I think = at this stage the encoding proposed is pretty easy to code.=C2=A0

However the policy of= any implementation needs to be able to handle local actions as well as reg= istered and private types/definitions.

If this it too complicated in practice I do not = know. Many people says BGP is complicated, but for me it is as simple or as= complex as one makes it to be.

But we are open for comments and contributions from eve= ryone here.
=C2=A0
The = complication in the specification also creates a secondary problem for
router vendors in updating their policy languages so that they can
interpret wide bgp communities.

=E2=80=8BIndeed .. just like I mentioned above. The use fl= exibility is in the policy language and parser. Good news is that current v= ersion seems to get thumbs up from many vendors. =E2=80=8B
= =C2=A0
Overall, this is not compati= ble with the engineering principal of "keep
things as simple as possible - but no simpler".
<= br>
=E2=80=8BNot sure I get that one. Are= you saying if we follow what you suggest below it will meet such criteria = or regardless it will stay incompatible ?=C2=A0
I do encourage to read the companion dr= aft showing registered types for the use cases. I am not sure how much simp= lere those could be ...=E2=80=8B

Suggestions:

1. Would it be possible to ditch:

>=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 5: IEEE Floating Point Number list
>=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 6: Neighbor Class list
>=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 7: User-defined Class list

=E2=80=8BWell if you ask me= I am all for it. No issue.=C2=A0

=
=E2=80=8BThat is also the reason why we demux at th= e types below the attribute. If tomorrow someone comes and says I must have= floating atoms there is no need to define new Wide BGP Community attribute= with those.=C2=A0
=C2=A0
2. Simplify, or at least explain why this needs needs to be so complicated:=

> 4. Container Type 1: Wide Community

=E2=80=8BJust explained above. =E2=80=8B
=C2=A0
3. provide some guidance= about deletion or modification of parts of the
community attribute entries, particularly in the context of:

>=C2=A0 =C2=A0 The Wide BGP Community Attribute is an optional, transiti= ve BGP
>=C2=A0 =C2=A0 attribute, and may be present only once in the BGP UPDATE= message.

=E2= =80=8BNot sure what you mean by "parts". The deletion at least th= e way I see it should be per type (registered or private) or per attribute.= =E2=80=8B=C2=A0
<= /div>
4. discussion of how implementing this = is going to shake out structural
problems in vendors' routing policy grammars, with associated security<= br> implications if the grammars are incapable of handling the complication
that this draft introduces.

=E2=80=8BIndeed this is vendor dependent.=C2=A0

But should we stop propos= e anything in BGP if anyone would have a problem implementing it ? I was un= der impression that two implementations are enough for IDR to progress the = doc to last call. =E2=80=8B
=C2=A0
5. I love the idea of UTF8 communities.=C2=A0 On smaller netw= ork, these could be
a real win.

=E2= =80=8BYup.=E2=80=8B

6. I'm guessing that the struct= ure of container type 1 is designed to
accommodate the <prepend X times Y ASN at location Z> construction th= at's
widely used on the internet.=C2=A0 This requires a pretty serious grammar t= o
allow for proper parameter checking.


=E2=80=8BI think you did not= read the companion draft :) Please do.=C2=A0
=
Yes this is one very fundamental use case= s here.

Many= thx for your comments,
r.=E2=80=8B

<= /div>




=C2= =A0
Nick

--001a11c3bcbc31de1a0510e1e859-- From nobody Mon Mar 9 15:17:26 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C41ACD7F; Mon, 9 Mar 2015 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YymuLBQHnKZL; Mon, 9 Mar 2015 15:17:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F691A8912; Mon, 9 Mar 2015 15:17:15 -0700 (PDT) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0303.namprd09.prod.outlook.com (25.160.96.148) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 22:16:55 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 22:16:54 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-00.txt Thread-Index: AQHQWq/g4I7A2nv0JUGX1gNoY7bApJ0Usafw Date: Mon, 9 Mar 2015 22:16:54 +0000 Message-ID: References: <20150309212724.28218.56595.idtracker@ietfa.amsl.com> In-Reply-To: <20150309212724.28218.56595.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0303; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(106116001)(450100001)(2900100001)(92566002)(77156002)(62966003)(1720100001)(33656002)(2656002)(46102003)(66066001)(54356999)(50986999)(74316001)(76176999)(86362001)(40100003)(102836002)(230783001)(122556002)(87936001)(2351001)(76576001)(2501003)(15975445007)(110136001)(19580395003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0303; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR09MB0303; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0303; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 22:16:54.6309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0303 Archived-At: Cc: "sidr wg list \(sidr@ietf.org\)" Subject: [Idr] FW: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:17:18 -0000 Um91dGUgbGVha3MgcHJvYmxlbSBkZWZpbml0aW9uIGlzIGFscmVhZHkgd29yayBpbiBwcm9ncmVz cyBpbiB0aGUgR1JPVyBXRy4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Z3Jvdy1yb3V0ZS1sZWFrLXByb2JsZW0tZGVmaW5pdGlvbi0wMSANCg0KVGhpcyByZWxhdGVkIG5l dyBkcmFmdCBhZGRyZXNzZXMgdGVjaG5pcXVlcyBmb3IgZGV0ZWN0aW9uIGFuZCBtaXRpZ2F0aW9u IG9mIHJvdXRlIGxlYWtzLg0KVGhlIElEUiBjaGFpcnMgaGF2ZSBhZ3JlZWQgdG8gaW5jbHVkZSB0 aGlzIGRyYWZ0IGluIHRoZSBhZ2VuZGEgZm9yIERhbGxhcy4NClNvIHdlICh0aGUgYXV0aG9ycykg bG9vayBmb3J3YXJkIHRvIHByZXNlbnRpbmcgdGhpcyB3b3JrIGFuZCByZWNlaXZpbmcgeW91ciBj b21tZW50cy4NCkNvbW1lbnRzIGFyZSB3ZWxjb21lIG9uIHRoZSBtYWlsaW5nIGxpc3QgYXMgd2Vs bC4NCg0KU3JpcmFtDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmlyYW0taWRyLXJvdXRlLWxlYWstZGV0ZWN0 aW9uLW1pdGlnYXRpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEtvdGlrYWxhcHVkaSBTcmlyYW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtc3JpcmFtLWlkci1yb3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9u DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJTWV0aG9kcyBmb3IgRGV0ZWN0aW9uIGFuZCBNaXRpZ2F0 aW9uIG9mIEJHUCBSb3V0ZSBMZWFrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOQ0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTQNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcmlyYW0taWRyLXJvdXRlLWxl YWstZGV0ZWN0aW9uLW1pdGlnYXRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3JpcmFtLWlkci1yb3V0ZS1sZWFrLWRldGVj dGlvbi1taXRpZ2F0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNyaXJhbS1pZHItcm91dGUtbGVhay1kZXRlY3Rpb24tbWl0aWdhdGlvbi0wMA0K DQpBYnN0cmFjdDoNCiAgIEluIFtJLUQuaWV0Zi1ncm93LXJvdXRlLWxlYWstcHJvYmxlbS1kZWZp bml0aW9uXSwgdGhlIGF1dGhvcnMgaGF2ZQ0KICAgcHJvdmlkZWQgYSBkZWZpbml0aW9uIG9mIHRo ZSByb3V0ZSBsZWFrIHByb2JsZW0sIGFuZCBhbHNvIGVudW1lcmF0ZWQNCiAgIHNldmVyYWwgdHlw ZXMgb2Ygcm91dGUgbGVha3MuICBJbiB0aGlzIGRvY3VtZW50LCB3ZSBmaXJzdCBleGFtaW5lDQog ICB3aGljaCBvZiB0aG9zZSByb3V0ZS1sZWFrIHR5cGVzIGFyZSBkZXRlY3RlZCBhbmQgbWl0aWdh dGVkIGJ5IHRoZQ0KICAgZXhpc3Rpbmcgb3JpZ2luIHZhbGlkYXRpb24gW1JGQyA2ODExXSBhbmQg QkdQU0VDIHBhdGggdmFsaWRhdGlvbiBbSS0NCiAgIEQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2Nv bF0uICBXaGVyZSB0aGUgY3VycmVudCBCR1BTRUMgcHJvdG9jb2wNCiAgIGRvZXNuJ3Qgb2ZmZXIg YSBzb2x1dGlvbiwgdGhpcyBkb2N1bWVudCBzdWdnZXN0cyBhbiBlbmhhbmNlbWVudCB0aGF0DQog ICB3b3VsZCBleHRlbmQgdGhlIHJvdXRlLWxlYWsgZGV0ZWN0aW9uIGFuZCBtaXRpZ2F0aW9uIGNh cGFiaWxpdHkgb2YNCiAgIEJHUFNFQy4gIFRoZSBzb2x1dGlvbiBjYW4gYmUgaW1wbGVtZW50ZWQg aW4gQkdQIHdpdGhvdXQgbmVjZXNzYXJpbHkNCiAgIHR5aW5nIGl0IHRvIEJHUFNFQy4gIEluY29y cG9yYXRpbmcgdGhlIHNvbHV0aW9uIGluIEJHUFNFQyBpcyBvbmUgd2F5DQogICBvZiBpbXBsZW1l bnRpbmcgaXQgaW4gYSBzZWN1cmUgd2F5LiAgV2UgZG8gbm90IGNsYWltIHRvIGhhdmUgcHJvdmlk ZWQNCiAgIGEgc29sdXRpb24gZm9yIGFsbCBwb3NzaWJsZSB0eXBlcyBvZiByb3V0ZSBsZWFrcywg YnV0IHRoZSBzb2x1dGlvbg0KICAgY292ZXJzIHNldmVyYWwsIGVzcGVjaWFsbHkgY29uc2lkZXJp bmcgc29tZSBzaWduaWZpY2FudCByb3V0ZS1sZWFrDQogICBhdHRhY2tzIG9yIG9jY3VycmVuY2Vz IHRoYXQgaGF2ZSBiZWVuIG9ic2VydmVkIGluIHJlY2VudCB5ZWFycy4gIFRoZQ0KICAgZG9jdW1l bnQgYWxzbyBpbmNsdWRlcyBhIHN0b3BnYXAgbWV0aG9kIGZvciBkZXRlY3Rpb24gYW5kIG1pdGln YXRpb24NCiAgIG9mIHJvdXRlIGxlYWtzIGZvciB0aGUgcGhhc2Ugd2hlbiBCR1BTRUMgKHBhdGgg dmFsaWRhdGlvbikgaXMgbm90IHlldA0KICAgZGVwbG95ZWQgYnV0IG9ubHkgb3JpZ2luIHZhbGlk YXRpb24gaXMgZGVwbG95ZWQuDQoNCg== From nobody Mon Mar 9 17:07:57 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09451A01F9; Mon, 9 Mar 2015 17:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVFTKOLIWKnZ; Mon, 9 Mar 2015 17:07:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7632D1A88E8; Mon, 9 Mar 2015 17:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310000753.14666.46982.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 17:07:53 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Kathleen Moriarty's Yes on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:07:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-idr-error-handling-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. My only comment would be to see if you could break the first paragraph of the security considerations into a few sentences. Maybe getting rid of the parens to help break out the additional sentences would help. From nobody Mon Mar 9 17:08:00 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 116A81ACD1F; Mon, 9 Mar 2015 17:07:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09451A01F9; Mon, 9 Mar 2015 17:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVFTKOLIWKnZ; Mon, 9 Mar 2015 17:07:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7632D1A88E8; Mon, 9 Mar 2015 17:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310000753.14666.46982.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 17:07:53 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Kathleen Moriarty's Yes on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:07:55 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-idr-error-handling-18: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft. My only comment would be to see if you could break the first paragraph of the security considerations into a few sentences. Maybe getting rid of the parens to help break out the additional sentences would help. From nobody Mon Mar 9 17:42:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741A31ACE4E for ; Mon, 9 Mar 2015 17:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kZf_wus2QAw for ; Mon, 9 Mar 2015 17:42:05 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AAC21ACD8C for ; Mon, 9 Mar 2015 17:42:04 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id DDC37850E2A1C; Tue, 10 Mar 2015 00:41:58 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2A0g2CX023455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Mar 2015 01:42:03 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 01:42:02 +0100 From: "Rabadan, Jorge (Jorge)" To: "shares@ndzh.com" , "idr@ietf.org" Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQWssFgmQy5JOXikaSnv6s0krW0A== Date: Tue, 10 Mar 2015 00:42:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <936246B77F4ADC40B5DBF20FD5B7BF73@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:42:08 -0000 SSBzdXBwb3J0IHRoaXMgZG9jdW1lbnQgZm9yIFdHIGFkb3B0aW9uLg0KSXQgYWRkcmVzc2VzIGEg cmVhbCBpc3N1ZS4NClRoeA0KSm9yZ2UNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb206IFN1c2FuIEhhcmVzIDxzaGFyZXMgYXQgbmR6 aC5jb20+DQpEYXRlOiBNb25kYXksIE1hcmNoIDIsIDIwMTUgYXQgMjo0NCBQTQ0KVG86IGlkciB3 ZyA8aWRyIGF0IGlldGYub3JnPg0KU3ViamVjdDogW0lkcl0gMiBXZWVrIFdHIEFkb3B0aW9uIGNh bGwgZm9yIGRyYWZ0LXltYmstaWRyLXJzLWJmZC0wMA0KKDMvMi8yMDE1IHRvIDMvMTYvMjAxNSkN Cg0KDQoNClRoaXMgYmVnaW5zIGEgMiB3ZWVrIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXlt YmstaWRyLXJzLWJmZC0wMC50eHQNCiANClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gdGhp cyBkcmFmdCBhbmQgaW5kaWNhdGUgd2h5IHRoaXMgaXMgdXNlZnVsIHRvDQphZGQgdG8gdGhlIEJH UCBtZWNoYW5pc20uICAgSW4geW91ciBjb21tZW50cyBwbGVhc2UgaW5jbHVkZSDigJxzdXBwb3J0 4oCdIG9yDQrigJxubyBzdXBwb3J04oCdIGZvciB0aGUgV0cgQWRvcHRpb24gb2YgdGhpcyBkcmFm dC4NCiANClN1ZSBIYXJlcyBhbmQgSm9obiBTY3VkZGVyDQoNCg0KDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZHIgbWFpbGluZyBsaXN0 DQpJZHIgYXQgaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aWRyDQoNCg0KDQo= From nobody Tue Mar 10 02:09:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB111A6FF7 for ; Tue, 10 Mar 2015 02:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.185 X-Spam-Level: X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EUvugWRQ488 for ; Tue, 10 Mar 2015 02:09:08 -0700 (PDT) Received: from mail.serv.os3.nl (mail.serv.os3.nl [145.100.96.25]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98A81A7018 for ; Tue, 10 Mar 2015 02:09:07 -0700 (PDT) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 61AEE17AFD2 for ; Tue, 10 Mar 2015 10:09:06 +0100 (CET) Received: from [IPv6:2a00:1328:e001:4:6480:f0e0:1efc:7ec2] (unknown [IPv6:2a00:1328:e001:4:6480:f0e0:1efc:7ec2]) by smtp.os3.nl (Postfix) with ESMTPSA id 2591517AD02 for ; Tue, 10 Mar 2015 10:09:06 +0100 (CET) Message-ID: <54FEB4B0.7070401@os3.nl> Date: Tue, 10 Mar 2015 10:09:04 +0100 From: splug User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: idr@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 09:09:09 -0000 Hello IDR mailing list, I work for a big IXP in Germany and strongly support the adoption of this Internet Draft. Best regards, Stefan Plug From nobody Tue Mar 10 07:13:01 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3720E1B2A4E; Tue, 10 Mar 2015 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcJFwlQsVVDV; Tue, 10 Mar 2015 07:12:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12A71A8831; Tue, 10 Mar 2015 07:12:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 07:12:26 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:12:58 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The writeup is so good it almost convinced me to just ballot no-obj and not bother reading the doc:-) Good job. - There is a perhaps missing security consideration. I think this kind of protocol behaviour argues that any kind of BGPSEC encryption needs to use an AEAD ciphersuite. (Which we'd likely do these days anyway, so that's not a biggie.) The reason is if say CBC or a stream cipher were used, then an attacker could play with ciphertext is various ways that might interact with this error handling behaviour so as to expose information that is intended to be protected by the BGPSEC mechanism. Such an attack would probably be pooh-poohed by all but tin foil hat folks, but it could still be worth noting (maybe in section 8?) and as we've seen recently, many of the tin foil hat fears turn out to be realistic, sadly. I noted a few nitty nits: - section 2: AFI/SAFI are used without expansion - 3.d: "well-known mandatory attributes" sort of yells for a reference, doesn't it. - 3.e: "cases that specify" - specify where? I think you mean in the updated RFCs but it might be nice to say that - 5: NRLI is expanded after 1st use From nobody Tue Mar 10 07:13:02 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 71DAA1B2A51; Tue, 10 Mar 2015 07:12:58 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3720E1B2A4E; Tue, 10 Mar 2015 07:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcJFwlQsVVDV; Tue, 10 Mar 2015 07:12:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12A71A8831; Tue, 10 Mar 2015 07:12:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310141226.24491.44397.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 07:12:26 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 14:12:58 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The writeup is so good it almost convinced me to just ballot no-obj and not bother reading the doc:-) Good job. - There is a perhaps missing security consideration. I think this kind of protocol behaviour argues that any kind of BGPSEC encryption needs to use an AEAD ciphersuite. (Which we'd likely do these days anyway, so that's not a biggie.) The reason is if say CBC or a stream cipher were used, then an attacker could play with ciphertext is various ways that might interact with this error handling behaviour so as to expose information that is intended to be protected by the BGPSEC mechanism. Such an attack would probably be pooh-poohed by all but tin foil hat folks, but it could still be worth noting (maybe in section 8?) and as we've seen recently, many of the tin foil hat fears turn out to be realistic, sadly. I noted a few nitty nits: - section 2: AFI/SAFI are used without expansion - 3.d: "well-known mandatory attributes" sort of yells for a reference, doesn't it. - 3.e: "cases that specify" - specify where? I think you mean in the updated RFCs but it might be nice to say that - 5: NRLI is expanded after 1st use From nobody Wed Mar 11 00:11:28 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD751A9073 for ; Wed, 11 Mar 2015 00:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfKM55A_-NLO for ; Wed, 11 Mar 2015 00:11:25 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AE11A9089 for ; Wed, 11 Mar 2015 00:11:25 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for Idr@ietf.org with esmtp (envelope-from ) id <1YVanb-001R5F-KS>; Wed, 11 Mar 2015 08:11:23 +0100 Received: from [89.15.238.199] (helo=mw-PC) by inpost2.zedat.fu-berlin.de (Exim 4.85) for Idr@ietf.org with esmtpsa (envelope-from ) id <1YVanb-003D7x-Cj>; Wed, 11 Mar 2015 08:11:23 +0100 Date: Wed, 11 Mar 2015 08:10:46 +0100 From: Matthias Waehlisch To: Idr@ietf.org In-Reply-To: <698485A3-0491-4D64-916E-8DB254421A07@de-cix.net> Message-ID: References: <007601d05518$e031f1d0$a095d570$@ndzh.com> <698485A3-0491-4D64-916E-8DB254421A07@de-cix.net> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="48836379-17421-1426055170=:4904" Content-ID: X-Originating-IP: 89.15.238.199 Archived-At: Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:11:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --48836379-17421-1426055170=:4904 Content-Type: TEXT/PLAIN; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Hi, I read the draft, support adoption, and will participate in future discussions. Cheers matthias > From: Susan Hares > To: idr wg > Date: 2 March 2015 19:44:11 CET > Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) > > This begins a 2 week WG Adoption call for draft-ymbk-idr-rs-bfd-00.txt  >   > Please review and comment on this draft and indicate why this is useful to add to the BGP > mechanism.   In your comments please include “support” or “no support” for the WG Adoption > of this draft.  >   > Sue Hares and John Scudder  > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > > --48836379-17421-1426055170=:4904-- From nobody Wed Mar 11 08:43:51 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD61A0064; Wed, 11 Mar 2015 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5oMSe0cWzVQ; Wed, 11 Mar 2015 08:43:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C42651A0070; Wed, 11 Mar 2015 08:43:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311154344.32154.77527.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 08:43:44 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Barry Leiba's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:43:48 -0000 Barry Leiba has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have to add my thanks to Stephen's for an exceptionally good shepherd writeup. Thanks for taking the time to do that. I agree with Brian's comment that the 2119 key words are inappropriate in Section 6, and that they should be changed to plain-English recommendations. From nobody Wed Mar 11 08:43:52 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 57B8C1A0077; Wed, 11 Mar 2015 08:43:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AD61A0064; Wed, 11 Mar 2015 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5oMSe0cWzVQ; Wed, 11 Mar 2015 08:43:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C42651A0070; Wed, 11 Mar 2015 08:43:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311154344.32154.77527.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 08:43:44 -0700 Archived-At: Cc: idr@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, rob.shakir@bt.com, idr-chairs@ietf.org Subject: [Idr] Barry Leiba's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:43:48 -0000 Barry Leiba has entered the following ballot position for draft-ietf-idr-error-handling-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have to add my thanks to Stephen's for an exceptionally good shepherd writeup. Thanks for taking the time to do that. I agree with Brian's comment that the 2119 key words are inappropriate in Section 6, and that they should be changed to plain-English recommendations. From nobody Wed Mar 11 12:44:02 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CB81A6F15 for ; Wed, 11 Mar 2015 12:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul5i37WKxQ5r for ; Wed, 11 Mar 2015 12:44:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823091A86E4 for ; Wed, 11 Mar 2015 12:43:58 -0700 (PDT) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0304.namprd09.prod.outlook.com (25.160.96.149) with Microsoft SMTP Server (TLS) id 15.1.106.15; Wed, 11 Mar 2015 19:43:57 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0106.007; Wed, 11 Mar 2015 19:43:57 +0000 From: "Sriram, Kotikalapudi" To: Susan Hares , 'John G.Scudder' Thread-Topic: [Idr] IETF-92 agenda topics Thread-Index: AQHQVPvvJ8veZNoaVEOPFqnBiJW/v50JiVsAgA4vWiA= Date: Wed, 11 Mar 2015 19:43:56 +0000 Message-ID: References: <1425311881323.66767@nist.gov> <008301d05519$aa21a760$fe64f620$@ndzh.com> In-Reply-To: <008301d05519$aa21a760$fe64f620$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] authentication-results: ndzh.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0304; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(86362001)(76176999)(1720100001)(46102003)(33656002)(99286002)(2656002)(66066001)(106116001)(2950100001)(77156002)(2900100001)(19580395003)(50986999)(40100003)(15975445007)(102836002)(54356999)(92566002)(62966003)(122556002)(74316001)(87936001)(76576001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0304; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR09MB0304; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0304; x-forefront-prvs: 0512CC5201 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2015 19:43:56.8006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0304 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] IETF-92 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:44:01 -0000 Sue: John: When you update the agenda, can you please include links to the=20 recent updated versions of the I-Ds for route leaks as follows? (I would feel bad about making people go through older versions of the draf= ts.) Please replace this - Route Leak Detection [Sriram Kotikalapudi] [10 minutes]=20 https://tools.ietf.org/html/draft-sriram-route-leak-detection-mitigation-00 [companion draft in grow https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-= 00] With this - Route Leak Detection [K. Sriram] [10 minutes]=20 http://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigation= -00 =20 [companion draft in grow http://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-0= 1 ] Thank you. Sriram=20 From nobody Thu Mar 12 00:09:05 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33C11A1A22; Thu, 12 Mar 2015 00:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5N1ZoM41Zff; Thu, 12 Mar 2015 00:08:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 177951A1A1D; Thu, 12 Mar 2015 00:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 00:08:49 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Idr] Last Call Expired: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:09:00 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 12 00:09:06 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 328FC1A1A1D; Thu, 12 Mar 2015 00:09:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33C11A1A22; Thu, 12 Mar 2015 00:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5N1ZoM41Zff; Thu, 12 Mar 2015 00:08:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 177951A1A1D; Thu, 12 Mar 2015 00:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 00:08:49 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [Idr] Last Call Expired: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 07:09:00 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Thu Mar 12 03:52:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205E61A9162; Thu, 12 Mar 2015 03:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-iI6Dp2LDd; Thu, 12 Mar 2015 03:52:06 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245771A9151; Thu, 12 Mar 2015 03:52:04 -0700 (PDT) Received: from [109.144.198.125] (helo=[10.210.203.117]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YW0ia-00012H-M4; Thu, 12 Mar 2015 10:51:56 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Rob Shakir In-Reply-To: <54FD9043.7000702@innovationslab.net> Date: Thu, 12 Mar 2015 10:51:55 +0000 Message-Id: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> <54FD9043.7000702@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, Rob Shakir , draft-ietf-idr-error-handling.all@ietf.org, shares@ndzh.com, iesg@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:52:08 -0000 --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Brian, Apologies for the delay in my reply. > On 9 Mar 2015, at 12:21, Brian Haberman = wrote: >=20 > I agree that it belongs in the document, but it appears to me to be a > little opaque. I read the text in the draft as strictly something the > operator has to worry about. The description you provided indicated > that there needs to be sufficient notification from the router so that > the operator can act on it. >=20 > Perhaps what is needed is just a little clarification. Given that I > raised this as a Comment, making any changes is really up to the > authors/WG/AD. My thought would be a slight re-wording of the 2nd > paragraph to indicate that the router needs to provide a notification > when a malformed attribute is detected. That then provides the input > needed for the operator to act on the recommendation in the section. I agree =97 let me work with the authors as part of the post-IESG review = comments to see whether we can clarify the wording here (perhaps based = around the summaries here). Since there are multiple comments around = this clarification, then making changes would seem advisable to me! Thanks again for the review. Cheers, r.= --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Brian,

Apologies for the delay in my reply.

On = 9 Mar 2015, at 12:21, Brian Haberman <brian@innovationslab.net> wrote:

I agree that it = belongs in the document, but it appears to me to be a
little opaque.  I read the text in the = draft as strictly something the
operator has to worry about.  The = description you provided indicated
that there needs to be sufficient notification = from the router so that
the operator can act on = it.

Perhaps what is needed is = just a little clarification.  Given that I
raised this as a Comment, making any changes is = really up to the
authors/WG/AD.  My = thought would be a slight re-wording of the 2nd
paragraph to indicate that the router needs to = provide a notification
when a malformed attribute = is detected.  That then provides the input
needed for the operator to act on the = recommendation in the section.

I agree =97 let me work with the authors as part of the = post-IESG review comments to see whether we can clarify the wording here = (perhaps based around the summaries here). Since there are multiple = comments around this clarification, then making changes would seem = advisable to me!

Thanks again for the review.

Cheers,
r.
= --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96-- From nobody Thu Mar 12 03:52:13 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3E7A81A9165; Thu, 12 Mar 2015 03:52:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205E61A9162; Thu, 12 Mar 2015 03:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI-iI6Dp2LDd; Thu, 12 Mar 2015 03:52:06 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245771A9151; Thu, 12 Mar 2015 03:52:04 -0700 (PDT) Received: from [109.144.198.125] (helo=[10.210.203.117]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YW0ia-00012H-M4; Thu, 12 Mar 2015 10:51:56 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Rob Shakir In-Reply-To: <54FD9043.7000702@innovationslab.net> Date: Thu, 12 Mar 2015 10:51:55 +0000 Message-Id: References: <20150306204043.28239.82980.idtracker@ietfa.amsl.com> <122301d0584e$e8395830$b8ac0890$@ndzh.com> <54FA1795.5000406@innovationslab.net> <54FD9043.7000702@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: idr@ietf.org, idr-chairs@ietf.org, Rob Shakir , draft-ietf-idr-error-handling.all@ietf.org, shares@ndzh.com, iesg@ietf.org Subject: Re: [Idr] Brian Haberman's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 10:52:08 -0000 --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Brian, Apologies for the delay in my reply. > On 9 Mar 2015, at 12:21, Brian Haberman = wrote: >=20 > I agree that it belongs in the document, but it appears to me to be a > little opaque. I read the text in the draft as strictly something the > operator has to worry about. The description you provided indicated > that there needs to be sufficient notification from the router so that > the operator can act on it. >=20 > Perhaps what is needed is just a little clarification. Given that I > raised this as a Comment, making any changes is really up to the > authors/WG/AD. My thought would be a slight re-wording of the 2nd > paragraph to indicate that the router needs to provide a notification > when a malformed attribute is detected. That then provides the input > needed for the operator to act on the recommendation in the section. I agree =97 let me work with the authors as part of the post-IESG review = comments to see whether we can clarify the wording here (perhaps based = around the summaries here). Since there are multiple comments around = this clarification, then making changes would seem advisable to me! Thanks again for the review. Cheers, r.= --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Brian,

Apologies for the delay in my reply.

On = 9 Mar 2015, at 12:21, Brian Haberman <brian@innovationslab.net> wrote:

I agree that it = belongs in the document, but it appears to me to be a
little opaque.  I read the text in the = draft as strictly something the
operator has to worry about.  The = description you provided indicated
that there needs to be sufficient notification = from the router so that
the operator can act on = it.

Perhaps what is needed is = just a little clarification.  Given that I
raised this as a Comment, making any changes is = really up to the
authors/WG/AD.  My = thought would be a slight re-wording of the 2nd
paragraph to indicate that the router needs to = provide a notification
when a malformed attribute = is detected.  That then provides the input
needed for the operator to act on the = recommendation in the section.

I agree =97 let me work with the authors as part of the = post-IESG review comments to see whether we can clarify the wording here = (perhaps based around the summaries here). Since there are multiple = comments around this clarification, then making changes would seem = advisable to me!

Thanks again for the review.

Cheers,
r.
= --Apple-Mail=_621171C8-5251-452A-9095-426D29E0EF96-- From nobody Thu Mar 12 04:26:56 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C71A9176; Thu, 12 Mar 2015 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peOy08iDTAuM; Thu, 12 Mar 2015 04:26:51 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF9B1A9170; Thu, 12 Mar 2015 04:26:49 -0700 (PDT) Received: from [109.144.198.125] (helo=[10.210.203.117]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YW1GL-0001P5-6u; Thu, 12 Mar 2015 11:26:49 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Rob Shakir In-Reply-To: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 11:26:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, iesg@ietf.org, Rob Shakir Subject: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 11:26:54 -0000 > On 12 Mar 2015, at 07:08, DraftTracker Mail System = wrote: >=20 > I-D: > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. Folks, Authors, Keeping track of the IESG comments on this draft, and some of the other = feedback that=E2=80=99s been received from directorate reviews: * gen-art provided some comments (you can find them at [0]) that it = would be good to address. * Stephen Farrell=E2=80=99s review raised a few nits (some of which are = duplicate from the gen-art review. * multiple comments about =C2=A76 of the document and particularly the = rfc2119 wording have been raised. Can I suggest that we restructure this = section slightly: Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an iBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and, more importantly, is seen as less problematic than the session-reset behavior it replaces. The treat-as-withdraw mechanism is different from discarding an = UPDATE message. The latter violates the basic BGP principle of incremental UPDATE, and causes invalid routes to be kept. Since treat-as-withdraw may result in such inconsistent routing = within an AS, complete un-reachability or sub-optimal routing for the destinations whose routes are carried in an affected UPDATE message, = a BGP speaker MUST provide debugging facilities to permit issues caused by a malformed UPDATE to be diagnosed. At a minimum, such facilities = MUST include logging an error listing the NLRI involved, and containing = the entire malformed UPDATE message. When such an error is logged, it is recommended that an operator SHOULD analyse the logged UPDATE message, and SHOULD investigate the = root cause. Where there source of the erroneous UPDATE message is external to the autonomous system, or administrative domain, of the operator - we RECOMMEND that an operator traces the erroneous UPDATE message to the ingress router which sourced the routes, or received the routes externally - and applies a filter to prevent the routes being = announced. This helps to maintain routing consistency in the network. Section 8 mentions that attribute discard should not be used in cases=20= where =E2=80=9Cthe attribute in question has or may have an effect on = route=20 selection.=E2=80=9D Although all cases that specify attribute discard = in this document do not affect route selection by default, in principle,=20 routing policies could be written that affect selection based on such an attribute. Operators SHOULD take care when writing such policies to consider the possible consequences of attribute discard. (In = general, as long as such policies are only applied to external BGP sessions, correctness issues are not expected to arise.) =20 Hopefully this makes reasonable use of RFC2119 wording too. I think = that if we are saying that the implementation MUST/SHOULD do something = to maintain correctness then we should say that the operator SHOULD do = something too! I think structuring the section into these two elements = (box-behaviours followed by people-behaviours) adds some clarity. * Stephen also raised a point about security considerations - this = seemed (to me) to relate more to security considerations of = treat-as-withdraw when used as a behaviour within BGPSEC. My (personal = opinion) is that this concern would be better covered in the BGPSEC = documents - since this document (at the moment) does not update any = document related to BGPSEC. * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The review = can be found at [1]. * 1 & 2 - there is a request to have a summary of what RFCs are = updated and how in the document. Potentially this could be added as an = appendix? * In the security considerations section, Alvaro observes that = remote withdrawal could be a new attack vector that is introduced. We = should mention this, but raise the consideration that rather than = causing session tear-down (which might result in isolation of an ASN). Thanks for all the work thus far on this document =E2=80=94 I look = forward to this doc progressing further! r. [0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html [1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html From nobody Thu Mar 12 04:26:57 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 354351A9177; Thu, 12 Mar 2015 04:26:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C71A9176; Thu, 12 Mar 2015 04:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peOy08iDTAuM; Thu, 12 Mar 2015 04:26:51 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF9B1A9170; Thu, 12 Mar 2015 04:26:49 -0700 (PDT) Received: from [109.144.198.125] (helo=[10.210.203.117]) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YW1GL-0001P5-6u; Thu, 12 Mar 2015 11:26:49 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Rob Shakir In-Reply-To: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 11:26:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> To: "idr@ietf. org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: idr-chairs@ietf.org, draft-ietf-idr-error-handling.all@ietf.org, iesg@ietf.org, Rob Shakir Subject: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 11:26:54 -0000 > On 12 Mar 2015, at 07:08, DraftTracker Mail System = wrote: >=20 > I-D: > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ >=20 > IETF Last Call has ended, and the state has been changed to > Waiting for AD Go-Ahead. Folks, Authors, Keeping track of the IESG comments on this draft, and some of the other = feedback that=E2=80=99s been received from directorate reviews: * gen-art provided some comments (you can find them at [0]) that it = would be good to address. * Stephen Farrell=E2=80=99s review raised a few nits (some of which are = duplicate from the gen-art review. * multiple comments about =C2=A76 of the document and particularly the = rfc2119 wording have been raised. Can I suggest that we restructure this = section slightly: Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an iBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and, more importantly, is seen as less problematic than the session-reset behavior it replaces. The treat-as-withdraw mechanism is different from discarding an = UPDATE message. The latter violates the basic BGP principle of incremental UPDATE, and causes invalid routes to be kept. Since treat-as-withdraw may result in such inconsistent routing = within an AS, complete un-reachability or sub-optimal routing for the destinations whose routes are carried in an affected UPDATE message, = a BGP speaker MUST provide debugging facilities to permit issues caused by a malformed UPDATE to be diagnosed. At a minimum, such facilities = MUST include logging an error listing the NLRI involved, and containing = the entire malformed UPDATE message. When such an error is logged, it is recommended that an operator SHOULD analyse the logged UPDATE message, and SHOULD investigate the = root cause. Where there source of the erroneous UPDATE message is external to the autonomous system, or administrative domain, of the operator - we RECOMMEND that an operator traces the erroneous UPDATE message to the ingress router which sourced the routes, or received the routes externally - and applies a filter to prevent the routes being = announced. This helps to maintain routing consistency in the network. Section 8 mentions that attribute discard should not be used in cases=20= where =E2=80=9Cthe attribute in question has or may have an effect on = route=20 selection.=E2=80=9D Although all cases that specify attribute discard = in this document do not affect route selection by default, in principle,=20 routing policies could be written that affect selection based on such an attribute. Operators SHOULD take care when writing such policies to consider the possible consequences of attribute discard. (In = general, as long as such policies are only applied to external BGP sessions, correctness issues are not expected to arise.) =20 Hopefully this makes reasonable use of RFC2119 wording too. I think = that if we are saying that the implementation MUST/SHOULD do something = to maintain correctness then we should say that the operator SHOULD do = something too! I think structuring the section into these two elements = (box-behaviours followed by people-behaviours) adds some clarity. * Stephen also raised a point about security considerations - this = seemed (to me) to relate more to security considerations of = treat-as-withdraw when used as a behaviour within BGPSEC. My (personal = opinion) is that this concern would be better covered in the BGPSEC = documents - since this document (at the moment) does not update any = document related to BGPSEC. * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The review = can be found at [1]. * 1 & 2 - there is a request to have a summary of what RFCs are = updated and how in the document. Potentially this could be added as an = appendix? * In the security considerations section, Alvaro observes that = remote withdrawal could be a new attack vector that is introduced. We = should mention this, but raise the consideration that rather than = causing session tear-down (which might result in isolation of an ASN). Thanks for all the work thus far on this document =E2=80=94 I look = forward to this doc progressing further! r. [0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html [1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html From nobody Thu Mar 12 09:01:59 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E61A872F; Thu, 12 Mar 2015 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74fPtOENJido; Thu, 12 Mar 2015 09:01:50 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DC61A1B20; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) Received: by oibg201 with SMTP id g201so15356490oib.10; Thu, 12 Mar 2015 09:01:49 -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=wDwErzk2Bu5ysN5FYVdvSfb1n94p+wBuX5IQB6bQLIk=; b=CLzBy/eKpGdumtj/WZ95Md+W0jEb7DH5krRemg+z9C4CK1YYJcD2t4MYHS1crFjC7f 5E6KF4Ae2DOOKQohqVKH/doWewoDPtRaul/CMjzWzWGBEGfENqjYkuDuafmaEy/4fxYU yaYyhEbcEg35Kmj4trl4sR4RLK558WwBc0V9U9ucmtTK3DJYGfhvvp0FO59bla6evVLK 0nAbxqKH4BA7BTQaitLtTTHWpOPQAyoNl0AwiSXvLLOqErGlGbCMzI9b4rvo/GRsbFNN q0QPE/q6FuXCk0SHbe0sdw9kjN1NwBYkFXbwe5JlNrOKbngVsbHMsCiUJMQ+mGE2kyL3 rPUw== MIME-Version: 1.0 X-Received: by 10.60.78.72 with SMTP id z8mr34609253oew.13.1426176109281; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) Received: by 10.60.139.164 with HTTP; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) In-Reply-To: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 12:01:49 -0400 Message-ID: From: Alia Atlas To: Rob Shakir Content-Type: multipart/alternative; boundary=089e0111d7ca618726051119807d Archived-At: Cc: "idr@ietf. org" , Rob Shakir , draft-ietf-idr-error-handling.all@ietf.org, "iesg@ietf.org" , idr-chairs@ietf.org Subject: Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:01:57 -0000 --089e0111d7ca618726051119807d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not convinced that we can use 2119 SHOULD language to put requirements on humans. I do agree about what the operators should do but without the SHOULD... Alia On Thu, Mar 12, 2015 at 7:26 AM, Rob Shakir wrote: > > > On 12 Mar 2015, at 07:08, DraftTracker Mail System < > iesg-secretary@ietf.org> wrote: > > > > I-D: > > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > > IETF Last Call has ended, and the state has been changed to > > Waiting for AD Go-Ahead. > > Folks, Authors, > > Keeping track of the IESG comments on this draft, and some of the other > feedback that=E2=80=99s been received from directorate reviews: > > * gen-art provided some comments (you can find them at [0]) that it would > be good to address. > > * Stephen Farrell=E2=80=99s review raised a few nits (some of which are d= uplicate > from the gen-art review. > > * multiple comments about =C2=A76 of the document and particularly the rf= c2119 > wording have been raised. Can I suggest that we restructure this section > slightly: > > Although the "treat-as-withdraw" error-handling behavior defined in > Section 2 makes every effort to preserve BGP's correctness, we note > that if an UPDATE received on an iBGP session is subjected to this > treatment, inconsistent routing within the affected Autonomous System > may result. The consequences of inconsistent routing can include > long-lived forwarding loops and black holes. While lamentable, this > issue is expected to be rare in practice, and, more importantly, is > seen as less problematic than the session-reset behavior it replaces. > The treat-as-withdraw mechanism is different from discarding an UPDATE > message. The latter violates the basic BGP principle of > incremental UPDATE, and causes invalid routes to be kept. > > Since treat-as-withdraw may result in such inconsistent routing within > an AS, complete un-reachability or sub-optimal routing for the > destinations whose routes are carried in an affected UPDATE message, a > BGP speaker MUST provide debugging facilities to permit issues caused > by a malformed UPDATE to be diagnosed. At a minimum, such facilities > MUST > include logging an error listing the NLRI involved, and containing the > entire malformed UPDATE message. > > When such an error is logged, it is recommended that an operator > SHOULD analyse the logged UPDATE message, and SHOULD investigate the > root cause. > Where there source of the erroneous UPDATE message is external to the > autonomous system, or administrative domain, of the operator - we > RECOMMEND that an operator traces the erroneous UPDATE message to the > ingress router which sourced the routes, or received the routes > externally - and applies a filter to prevent the routes being announce= d. > This helps to maintain routing consistency in the network. > > Section 8 mentions that attribute discard should not be used in cases > where =E2=80=9Cthe attribute in question has or may have an effect on = route > selection.=E2=80=9D Although all cases that specify attribute discard = in this > document do not affect route selection by default, in principle, > routing policies could be written that affect selection based on such > an attribute. Operators SHOULD take care when writing such policies > to consider the possible consequences of attribute discard. (In genera= l, > as long as such policies are only applied to external BGP sessions, > correctness issues are not expected to arise.) > > Hopefully this makes reasonable use of RFC2119 wording too. I think tha= t > if we are saying that the implementation MUST/SHOULD do something to > maintain correctness then we should say that the operator SHOULD do > something too! I think structuring the section into these two elements > (box-behaviours followed by people-behaviours) adds some clarity. > > * Stephen also raised a point about security considerations - this > seemed (to me) to relate more to security considerations of > treat-as-withdraw when used as a behaviour within BGPSEC. My (personal > opinion) is that this concern would be better covered in the BGPSEC > documents - since this document (at the moment) does not update any > document related to BGPSEC. > > * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The review = can be > found at [1]. > * 1 & 2 - there is a request to have a summary of what RFCs are > updated and how in the document. Potentially this could be added as an > appendix? > * In the security considerations section, Alvaro observes that > remote withdrawal could be a new attack vector that is introduced. We > should mention this, but raise the consideration that rather than causing > session tear-down (which might result in isolation of an ASN). > > Thanks for all the work thus far on this document =E2=80=94 I look forwar= d to this > doc progressing further! > > r. > > > [0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html > [1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html > > --089e0111d7ca618726051119807d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not convinced that we can use 2119 SHOULD language= to put requirements on humans.
I do agree about what the operators sho= uld do but without the SHOULD...

Alia
<= div class=3D"gmail_extra">
On Thu, Mar 12, 20= 15 at 7:26 AM, Rob Shakir <rjs@rob.sh> wrote:

> On 12 Mar 2015, at 07:08, DraftTracker Mail System <iesg-secretary@ietf.org> wrote:
>
> I-D: <draft-ietf-idr-error-handling-18.txt>
> ID Tracker URL: http://datatracker.ietf.org/doc/draf= t-ietf-idr-error-handling/
>
> IETF Last Call has ended, and the state has been changed to
> Waiting for AD Go-Ahead.

Folks, Authors,

Keeping track of the IESG comments on this draft, and some of the other fee= dback that=E2=80=99s been received from directorate reviews:

* gen-art provided some comments (you can find them at [0]) that it would b= e good to address.

* Stephen Farrell=E2=80=99s review raised a few nits (some of which are dup= licate from the gen-art review.

* multiple comments about =C2=A76 of the document and particularly the rfc2= 119 wording have been raised. Can I suggest that we restructure this sectio= n slightly:

=C2=A0 =C2=A0Although the "treat-as-withdraw" error-handling beha= vior defined in
=C2=A0 =C2=A0Section 2 makes every effort to preserve BGP's correctness= , we note
=C2=A0 =C2=A0that if an UPDATE received on an iBGP session is subjected to = this
=C2=A0 =C2=A0treatment, inconsistent routing within the affected Autonomous= System
=C2=A0 =C2=A0may result.=C2=A0 The consequences of inconsistent routing can= include
=C2=A0 =C2=A0long-lived forwarding loops and black holes.=C2=A0 While lamen= table, this
=C2=A0 =C2=A0issue is expected to be rare in practice, and, more importantl= y, is
=C2=A0 =C2=A0seen as less problematic than the session-reset behavior it re= places.
=C2=A0 =C2=A0The treat-as-withdraw mechanism is different from discarding a= n UPDATE
=C2=A0 =C2=A0message. The latter violates the basic BGP principle of
=C2=A0 =C2=A0incremental UPDATE, and causes invalid routes to be kept.

=C2=A0 =C2=A0Since treat-as-withdraw may result in such inconsistent routin= g within
=C2=A0 =C2=A0an AS, complete un-reachability or sub-optimal routing for the=
=C2=A0 =C2=A0destinations whose routes are carried in an affected UPDATE me= ssage, a
=C2=A0 =C2=A0BGP speaker MUST provide debugging facilities to permit issues= caused
=C2=A0 =C2=A0by a malformed UPDATE to be diagnosed. At a minimum, such faci= lities MUST
=C2=A0 =C2=A0include logging an error listing the NLRI involved, and contai= ning the
=C2=A0 =C2=A0entire malformed UPDATE message.

=C2=A0 =C2=A0When such an error is logged, it is recommended that an operat= or
=C2=A0 =C2=A0SHOULD analyse the logged UPDATE message, and SHOULD investiga= te the root cause.
=C2=A0 =C2=A0Where there source of the erroneous UPDATE message is external= to the
=C2=A0 =C2=A0autonomous system, or administrative domain, of the operator -= we
=C2=A0 =C2=A0RECOMMEND that an operator traces the erroneous UPDATE message= to the
=C2=A0 =C2=A0ingress router which sourced the routes, or received the route= s
=C2=A0 =C2=A0externally - and applies a filter to prevent the routes being = announced.
=C2=A0 =C2=A0This helps to maintain routing consistency in the network.

=C2=A0 =C2=A0Section 8 mentions that attribute discard should not be used i= n cases
=C2=A0 =C2=A0where =E2=80=9Cthe attribute in question has or may have an ef= fect on route
=C2=A0 =C2=A0selection.=E2=80=9D Although all cases that specify attribute = discard in this
=C2=A0 =C2=A0document do not affect route selection by default, in principl= e,
=C2=A0 =C2=A0routing policies could be written that affect selection based = on such
=C2=A0 =C2=A0an attribute. Operators SHOULD take care when writing such pol= icies
=C2=A0 =C2=A0to consider the possible consequences of attribute discard. (I= n general,
=C2=A0 =C2=A0as long as such policies are only applied to external BGP sess= ions,
=C2=A0 =C2=A0correctness issues are not expected to arise.)

=C2=A0 Hopefully this makes reasonable use of RFC2119 wording too. I think = that if we are saying that the implementation MUST/SHOULD do something to m= aintain correctness then we should say that the operator SHOULD do somethin= g too! I think structuring the section into these two elements (box-behavio= urs followed by people-behaviours) adds some clarity.

=C2=A0 * Stephen also raised a point about security considerations - this s= eemed (to me) to relate more to security considerations of treat-as-withdra= w when used as a behaviour within BGPSEC. My (personal opinion) is that thi= s concern would be better covered in the BGPSEC documents - since this docu= ment (at the moment) does not update any document related to BGPSEC.

=C2=A0 * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The revi= ew can be found at [1].
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * 1 & 2 - there is a request to have a summ= ary of what RFCs are updated and how in the document. Potentially this coul= d be added as an appendix?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * In the security considerations section, Alvar= o observes that remote withdrawal could be a new attack vector that is intr= oduced. We should mention this, but raise the consideration that rather tha= n causing session tear-down (which might result in isolation of an ASN).
Thanks for all the work thus far on this document =E2=80=94 I look forward = to this doc progressing further!

r.


[0]: https://www.ietf.org/mail-archive/web/ietf/current= /msg92265.html
[1]: https://www.ietf.org/mail-archive/web/idr/current/m= sg14113.html


--089e0111d7ca618726051119807d-- From nobody Thu Mar 12 09:02:03 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 74C831A8758; Thu, 12 Mar 2015 09:01:57 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E61A872F; Thu, 12 Mar 2015 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74fPtOENJido; Thu, 12 Mar 2015 09:01:50 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DC61A1B20; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) Received: by oibg201 with SMTP id g201so15356490oib.10; Thu, 12 Mar 2015 09:01:49 -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=wDwErzk2Bu5ysN5FYVdvSfb1n94p+wBuX5IQB6bQLIk=; b=CLzBy/eKpGdumtj/WZ95Md+W0jEb7DH5krRemg+z9C4CK1YYJcD2t4MYHS1crFjC7f 5E6KF4Ae2DOOKQohqVKH/doWewoDPtRaul/CMjzWzWGBEGfENqjYkuDuafmaEy/4fxYU yaYyhEbcEg35Kmj4trl4sR4RLK558WwBc0V9U9ucmtTK3DJYGfhvvp0FO59bla6evVLK 0nAbxqKH4BA7BTQaitLtTTHWpOPQAyoNl0AwiSXvLLOqErGlGbCMzI9b4rvo/GRsbFNN q0QPE/q6FuXCk0SHbe0sdw9kjN1NwBYkFXbwe5JlNrOKbngVsbHMsCiUJMQ+mGE2kyL3 rPUw== MIME-Version: 1.0 X-Received: by 10.60.78.72 with SMTP id z8mr34609253oew.13.1426176109281; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) Received: by 10.60.139.164 with HTTP; Thu, 12 Mar 2015 09:01:49 -0700 (PDT) In-Reply-To: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 12:01:49 -0400 Message-ID: From: Alia Atlas To: Rob Shakir Content-Type: multipart/alternative; boundary=089e0111d7ca618726051119807d Archived-At: Cc: "idr@ietf. org" , Rob Shakir , draft-ietf-idr-error-handling.all@ietf.org, "iesg@ietf.org" , idr-chairs@ietf.org Subject: Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:01:57 -0000 --089e0111d7ca618726051119807d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not convinced that we can use 2119 SHOULD language to put requirements on humans. I do agree about what the operators should do but without the SHOULD... Alia On Thu, Mar 12, 2015 at 7:26 AM, Rob Shakir wrote: > > > On 12 Mar 2015, at 07:08, DraftTracker Mail System < > iesg-secretary@ietf.org> wrote: > > > > I-D: > > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ > > > > IETF Last Call has ended, and the state has been changed to > > Waiting for AD Go-Ahead. > > Folks, Authors, > > Keeping track of the IESG comments on this draft, and some of the other > feedback that=E2=80=99s been received from directorate reviews: > > * gen-art provided some comments (you can find them at [0]) that it would > be good to address. > > * Stephen Farrell=E2=80=99s review raised a few nits (some of which are d= uplicate > from the gen-art review. > > * multiple comments about =C2=A76 of the document and particularly the rf= c2119 > wording have been raised. Can I suggest that we restructure this section > slightly: > > Although the "treat-as-withdraw" error-handling behavior defined in > Section 2 makes every effort to preserve BGP's correctness, we note > that if an UPDATE received on an iBGP session is subjected to this > treatment, inconsistent routing within the affected Autonomous System > may result. The consequences of inconsistent routing can include > long-lived forwarding loops and black holes. While lamentable, this > issue is expected to be rare in practice, and, more importantly, is > seen as less problematic than the session-reset behavior it replaces. > The treat-as-withdraw mechanism is different from discarding an UPDATE > message. The latter violates the basic BGP principle of > incremental UPDATE, and causes invalid routes to be kept. > > Since treat-as-withdraw may result in such inconsistent routing within > an AS, complete un-reachability or sub-optimal routing for the > destinations whose routes are carried in an affected UPDATE message, a > BGP speaker MUST provide debugging facilities to permit issues caused > by a malformed UPDATE to be diagnosed. At a minimum, such facilities > MUST > include logging an error listing the NLRI involved, and containing the > entire malformed UPDATE message. > > When such an error is logged, it is recommended that an operator > SHOULD analyse the logged UPDATE message, and SHOULD investigate the > root cause. > Where there source of the erroneous UPDATE message is external to the > autonomous system, or administrative domain, of the operator - we > RECOMMEND that an operator traces the erroneous UPDATE message to the > ingress router which sourced the routes, or received the routes > externally - and applies a filter to prevent the routes being announce= d. > This helps to maintain routing consistency in the network. > > Section 8 mentions that attribute discard should not be used in cases > where =E2=80=9Cthe attribute in question has or may have an effect on = route > selection.=E2=80=9D Although all cases that specify attribute discard = in this > document do not affect route selection by default, in principle, > routing policies could be written that affect selection based on such > an attribute. Operators SHOULD take care when writing such policies > to consider the possible consequences of attribute discard. (In genera= l, > as long as such policies are only applied to external BGP sessions, > correctness issues are not expected to arise.) > > Hopefully this makes reasonable use of RFC2119 wording too. I think tha= t > if we are saying that the implementation MUST/SHOULD do something to > maintain correctness then we should say that the operator SHOULD do > something too! I think structuring the section into these two elements > (box-behaviours followed by people-behaviours) adds some clarity. > > * Stephen also raised a point about security considerations - this > seemed (to me) to relate more to security considerations of > treat-as-withdraw when used as a behaviour within BGPSEC. My (personal > opinion) is that this concern would be better covered in the BGPSEC > documents - since this document (at the moment) does not update any > document related to BGPSEC. > > * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The review = can be > found at [1]. > * 1 & 2 - there is a request to have a summary of what RFCs are > updated and how in the document. Potentially this could be added as an > appendix? > * In the security considerations section, Alvaro observes that > remote withdrawal could be a new attack vector that is introduced. We > should mention this, but raise the consideration that rather than causing > session tear-down (which might result in isolation of an ASN). > > Thanks for all the work thus far on this document =E2=80=94 I look forwar= d to this > doc progressing further! > > r. > > > [0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html > [1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html > > --089e0111d7ca618726051119807d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not convinced that we can use 2119 SHOULD language= to put requirements on humans.
I do agree about what the operators sho= uld do but without the SHOULD...

Alia
<= div class=3D"gmail_extra">
On Thu, Mar 12, 20= 15 at 7:26 AM, Rob Shakir <rjs@rob.sh> wrote:

> On 12 Mar 2015, at 07:08, DraftTracker Mail System <iesg-secretary@ietf.org> wrote:
>
> I-D: <draft-ietf-idr-error-handling-18.txt>
> ID Tracker URL: http://datatracker.ietf.org/doc/draf= t-ietf-idr-error-handling/
>
> IETF Last Call has ended, and the state has been changed to
> Waiting for AD Go-Ahead.

Folks, Authors,

Keeping track of the IESG comments on this draft, and some of the other fee= dback that=E2=80=99s been received from directorate reviews:

* gen-art provided some comments (you can find them at [0]) that it would b= e good to address.

* Stephen Farrell=E2=80=99s review raised a few nits (some of which are dup= licate from the gen-art review.

* multiple comments about =C2=A76 of the document and particularly the rfc2= 119 wording have been raised. Can I suggest that we restructure this sectio= n slightly:

=C2=A0 =C2=A0Although the "treat-as-withdraw" error-handling beha= vior defined in
=C2=A0 =C2=A0Section 2 makes every effort to preserve BGP's correctness= , we note
=C2=A0 =C2=A0that if an UPDATE received on an iBGP session is subjected to = this
=C2=A0 =C2=A0treatment, inconsistent routing within the affected Autonomous= System
=C2=A0 =C2=A0may result.=C2=A0 The consequences of inconsistent routing can= include
=C2=A0 =C2=A0long-lived forwarding loops and black holes.=C2=A0 While lamen= table, this
=C2=A0 =C2=A0issue is expected to be rare in practice, and, more importantl= y, is
=C2=A0 =C2=A0seen as less problematic than the session-reset behavior it re= places.
=C2=A0 =C2=A0The treat-as-withdraw mechanism is different from discarding a= n UPDATE
=C2=A0 =C2=A0message. The latter violates the basic BGP principle of
=C2=A0 =C2=A0incremental UPDATE, and causes invalid routes to be kept.

=C2=A0 =C2=A0Since treat-as-withdraw may result in such inconsistent routin= g within
=C2=A0 =C2=A0an AS, complete un-reachability or sub-optimal routing for the=
=C2=A0 =C2=A0destinations whose routes are carried in an affected UPDATE me= ssage, a
=C2=A0 =C2=A0BGP speaker MUST provide debugging facilities to permit issues= caused
=C2=A0 =C2=A0by a malformed UPDATE to be diagnosed. At a minimum, such faci= lities MUST
=C2=A0 =C2=A0include logging an error listing the NLRI involved, and contai= ning the
=C2=A0 =C2=A0entire malformed UPDATE message.

=C2=A0 =C2=A0When such an error is logged, it is recommended that an operat= or
=C2=A0 =C2=A0SHOULD analyse the logged UPDATE message, and SHOULD investiga= te the root cause.
=C2=A0 =C2=A0Where there source of the erroneous UPDATE message is external= to the
=C2=A0 =C2=A0autonomous system, or administrative domain, of the operator -= we
=C2=A0 =C2=A0RECOMMEND that an operator traces the erroneous UPDATE message= to the
=C2=A0 =C2=A0ingress router which sourced the routes, or received the route= s
=C2=A0 =C2=A0externally - and applies a filter to prevent the routes being = announced.
=C2=A0 =C2=A0This helps to maintain routing consistency in the network.

=C2=A0 =C2=A0Section 8 mentions that attribute discard should not be used i= n cases
=C2=A0 =C2=A0where =E2=80=9Cthe attribute in question has or may have an ef= fect on route
=C2=A0 =C2=A0selection.=E2=80=9D Although all cases that specify attribute = discard in this
=C2=A0 =C2=A0document do not affect route selection by default, in principl= e,
=C2=A0 =C2=A0routing policies could be written that affect selection based = on such
=C2=A0 =C2=A0an attribute. Operators SHOULD take care when writing such pol= icies
=C2=A0 =C2=A0to consider the possible consequences of attribute discard. (I= n general,
=C2=A0 =C2=A0as long as such policies are only applied to external BGP sess= ions,
=C2=A0 =C2=A0correctness issues are not expected to arise.)

=C2=A0 Hopefully this makes reasonable use of RFC2119 wording too. I think = that if we are saying that the implementation MUST/SHOULD do something to m= aintain correctness then we should say that the operator SHOULD do somethin= g too! I think structuring the section into these two elements (box-behavio= urs followed by people-behaviours) adds some clarity.

=C2=A0 * Stephen also raised a point about security considerations - this s= eemed (to me) to relate more to security considerations of treat-as-withdra= w when used as a behaviour within BGPSEC. My (personal opinion) is that thi= s concern would be better covered in the BGPSEC documents - since this docu= ment (at the moment) does not update any document related to BGPSEC.

=C2=A0 * Our esteemed new AD reviewed too =E2=80=94 thanks Alvaro. The revi= ew can be found at [1].
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * 1 & 2 - there is a request to have a summ= ary of what RFCs are updated and how in the document. Potentially this coul= d be added as an appendix?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * In the security considerations section, Alvar= o observes that remote withdrawal could be a new attack vector that is intr= oduced. We should mention this, but raise the consideration that rather tha= n causing session tear-down (which might result in isolation of an ASN).
Thanks for all the work thus far on this document =E2=80=94 I look forward = to this doc progressing further!

r.


[0]: https://www.ietf.org/mail-archive/web/ietf/current= /msg92265.html
[1]: https://www.ietf.org/mail-archive/web/idr/current/m= sg14113.html


--089e0111d7ca618726051119807d-- From nobody Thu Mar 12 09:11:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2248F1A8878; Thu, 12 Mar 2015 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QuVveMEROxH; Thu, 12 Mar 2015 09:11:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F60F1A1EEA; Thu, 12 Mar 2015 09:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1132; q=dns/txt; s=iport; t=1426176664; x=1427386264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ioUibWJNLKmRNI4VrtJUjWE3wypc74fXYcjoHCKQ5E0=; b=HiYhAG9xncXHI9C1lSAQYI23OZuEM8phtLKhCaJi9lxFIhVZYErY0Evr fXnq1V4i6SPdgnsHfsZVO2VAVD995sVsBOSVoiFDd8ySiQdO8/OOmi9Nw ruJs1DTWV5bYCQLbZSkHdvZic4yj5X3ePtUiuIHn+1eni98Ifwa/GAHdC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBQCqaeJU/4MNJK1bgwZSWgTCPIVxAoEYQwEBAQEBAXyEDQEBBHkQAgEIDi0LMiUCBAENBYgtDc4oAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIQcAQEcMwIFhCoBBI1MgWyJN5MNIoIygTxvAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,389,1422921600"; d="scan'208";a="402892010" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2015 16:11:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2CGB3N8016685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Mar 2015 16:11:03 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.60]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 12 Mar 2015 11:11:03 -0500 From: "Alvaro Retana (aretana)" To: Rob Shakir , "idr@ietf. org" Thread-Topic: Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: [Idr] Last Call Expired: ) Thread-Index: AQHQXLdzZgfj8O3IQkC3duhQM0xISJ0Y40uA Date: Thu, 12 Mar 2015 16:11:03 +0000 Message-ID: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.13] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "iesg@ietf.org" , Rob Shakir Subject: Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:11:06 -0000 On 3/12/15, 4:26 AM, "Rob Shakir" wrote: Rob: Hi! > * Our esteemed new AD reviewed too =8B thanks Alvaro. The review can be >found at [1]. > * 1 & 2 - there is a request to have a summary of what RFCs are updated >and how in the document. Potentially this could be added as an appendix? A section would be nice, but I don=B9t have a problem with an appendix. > * In the security considerations section, Alvaro observes that remote >withdrawal could be a new attack vector that is introduced. We should >mention this, but raise the consideration that rather than causing >session tear-down (which might result in isolation of an ASN). Yes, the result is =B3better=B2 (at least there=B9s less disruption), but i= t might still result in isolation of an ASN at a route level. Not all routes are made the same. Alvaro. > >Thanks for all the work thus far on this document =8B I look forward to >this doc progressing further! > >r. > > >[0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html >[1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html > From nobody Thu Mar 12 09:11:11 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4F3E71A8883; Thu, 12 Mar 2015 09:11:06 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2248F1A8878; Thu, 12 Mar 2015 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QuVveMEROxH; Thu, 12 Mar 2015 09:11:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F60F1A1EEA; Thu, 12 Mar 2015 09:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1132; q=dns/txt; s=iport; t=1426176664; x=1427386264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ioUibWJNLKmRNI4VrtJUjWE3wypc74fXYcjoHCKQ5E0=; b=HiYhAG9xncXHI9C1lSAQYI23OZuEM8phtLKhCaJi9lxFIhVZYErY0Evr fXnq1V4i6SPdgnsHfsZVO2VAVD995sVsBOSVoiFDd8ySiQdO8/OOmi9Nw ruJs1DTWV5bYCQLbZSkHdvZic4yj5X3ePtUiuIHn+1eni98Ifwa/GAHdC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBQCqaeJU/4MNJK1bgwZSWgTCPIVxAoEYQwEBAQEBAXyEDQEBBHkQAgEIDi0LMiUCBAENBYgtDc4oAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIQcAQEcMwIFhCoBBI1MgWyJN5MNIoIygTxvAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,389,1422921600"; d="scan'208";a="402892010" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 12 Mar 2015 16:11:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2CGB3N8016685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Mar 2015 16:11:03 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.60]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 12 Mar 2015 11:11:03 -0500 From: "Alvaro Retana (aretana)" To: Rob Shakir , "idr@ietf. org" Thread-Topic: Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: [Idr] Last Call Expired: ) Thread-Index: AQHQXLdzZgfj8O3IQkC3duhQM0xISJ0Y40uA Date: Thu, 12 Mar 2015 16:11:03 +0000 Message-ID: References: <20150312070849.663.20811.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.13] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr-chairs@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "iesg@ietf.org" , Rob Shakir Subject: Re: [Idr] Post-Last Call Shepherd Comments for draft-ietf-idr-error-handling (was Re: Last Call Expired: ) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:11:06 -0000 On 3/12/15, 4:26 AM, "Rob Shakir" wrote: Rob: Hi! > * Our esteemed new AD reviewed too =8B thanks Alvaro. The review can be >found at [1]. > * 1 & 2 - there is a request to have a summary of what RFCs are updated >and how in the document. Potentially this could be added as an appendix? A section would be nice, but I don=B9t have a problem with an appendix. > * In the security considerations section, Alvaro observes that remote >withdrawal could be a new attack vector that is introduced. We should >mention this, but raise the consideration that rather than causing >session tear-down (which might result in isolation of an ASN). Yes, the result is =B3better=B2 (at least there=B9s less disruption), but i= t might still result in isolation of an ASN at a route level. Not all routes are made the same. Alvaro. > >Thanks for all the work thus far on this document =8B I look forward to >this doc progressing further! > >r. > > >[0]: https://www.ietf.org/mail-archive/web/ietf/current/msg92265.html >[1]: https://www.ietf.org/mail-archive/web/idr/current/msg14113.html > From nobody Thu Mar 12 10:40:19 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FC31A8AE0; Thu, 12 Mar 2015 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5PKTmdHAP0M; Thu, 12 Mar 2015 10:40:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 813081A8AD3; Thu, 12 Mar 2015 10:40:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312174015.16868.35611.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 10:40:15 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:40:18 -0000 IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ From nobody Thu Mar 12 10:40:21 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 56CCE1A8AE4; Thu, 12 Mar 2015 10:40:18 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FC31A8AE0; Thu, 12 Mar 2015 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5PKTmdHAP0M; Thu, 12 Mar 2015 10:40:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 813081A8AD3; Thu, 12 Mar 2015 10:40:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312174015.16868.35611.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 10:40:15 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:40:18 -0000 IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-error-handling/ From nobody Fri Mar 13 08:40:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC11A876C; Fri, 13 Mar 2015 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 621_A72AjgqE; Fri, 13 Mar 2015 08:40:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF01A8773; Fri, 13 Mar 2015 08:40:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E13CC22C; Fri, 13 Mar 2015 11:40:35 -0400 (EDT) Date: Fri, 13 Mar 2015 11:40:35 -0400 From: Jeffrey Haas To: "Alvaro Retana (aretana)" Message-ID: <20150313154035.GD6431@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "rob.shakir@bt.com" , "idr-chairs@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:40:38 -0000 Alvaro, On Mon, Mar 09, 2015 at 05:45:13PM +0000, Alvaro Retana (aretana) wrote: > 5. Security Considerations (Section 10). It is true that malformed optional transitive attributes should not cause remote session resets. Are remote withdrawals a new threat? Following the logic in the introduction, an update with a malformed optional transitive attribute may not be properly checked for several hops..but once the error is detected then the NLRI may use Treat-as-withdraw.. Assuming an AS-level granularity in checking, this won?t cause loops or major disruptions, but nonetheless it can result in not everyone receiving the information it should.. I'm not sure one can really stretch this point to be an attack vector. Normal BGP operational policy permits an operator to advertise or not a given prefix. If an upstream injects malformed information and some subset of routers are capable of announcing it and others are not the issue remains that the upstream reachability is invalid. -- Jeff From nobody Fri Mar 13 08:40:40 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4E73F1A87C0; Fri, 13 Mar 2015 08:40:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC11A876C; Fri, 13 Mar 2015 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 621_A72AjgqE; Fri, 13 Mar 2015 08:40:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B6AF01A8773; Fri, 13 Mar 2015 08:40:35 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E13CC22C; Fri, 13 Mar 2015 11:40:35 -0400 (EDT) Date: Fri, 13 Mar 2015 11:40:35 -0400 From: Jeffrey Haas To: "Alvaro Retana (aretana)" Message-ID: <20150313154035.GD6431@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "rob.shakir@bt.com" , "idr-chairs@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:40:38 -0000 Alvaro, On Mon, Mar 09, 2015 at 05:45:13PM +0000, Alvaro Retana (aretana) wrote: > 5. Security Considerations (Section 10). It is true that malformed optional transitive attributes should not cause remote session resets. Are remote withdrawals a new threat? Following the logic in the introduction, an update with a malformed optional transitive attribute may not be properly checked for several hops..but once the error is detected then the NLRI may use Treat-as-withdraw.. Assuming an AS-level granularity in checking, this won?t cause loops or major disruptions, but nonetheless it can result in not everyone receiving the information it should.. I'm not sure one can really stretch this point to be an attack vector. Normal BGP operational policy permits an operator to advertise or not a given prefix. If an upstream injects malformed information and some subset of routers are capable of announcing it and others are not the issue remains that the upstream reachability is invalid. -- Jeff From nobody Fri Mar 13 15:35:54 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9EE1A872A; Fri, 13 Mar 2015 15:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRBLj48A1ycE; Fri, 13 Mar 2015 15:35:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCE1A0217; Fri, 13 Mar 2015 15:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1426286151; x=1427495751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UX4kCY2Pn9szfnY4VPhFFvvlxccp+c9q9MUyPoMN5ws=; b=XGLbtmBFfJ1WlNJi2orYe8ZzSRI78oZq9IsT3LsMFt7SfIMJvqmumydT QWn+WGHD6zye9yrVIwJJZpZvL7ySdRYFy+yq2hRZnzHUqvvWRSNJKHdDB 4dwa5c8EupLQH7DsG0rlnRSsEIlAlOWe8yJ5M4/8JPJSziWZIGOeTfSjo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQBxZQNV/4gNJK1bgwaBLATJbwKBLkwBAQEBAQF9hBABAQR5EAIBCA4KLjIlAgQOBR+IEM5WAQEBAQEBAQMBAQEBAQEBG4sXhD4zB4QtAQSKUYNcggiJZYEajAmGbCODbm+BAgY8fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,397,1422921600"; d="scan'208";a="131896527" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 13 Mar 2015 22:35:50 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2DMZo6s016522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 22:35:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.38]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 13 Mar 2015 17:35:50 -0500 From: "Alvaro Retana (aretana)" To: Jeffrey Haas Thread-Topic: [Idr] Review of draft-ietf-idr-error-handling-18 Thread-Index: AQHQWpDLKAsEqqfj4UCra5AsX2rR050a5seA///+qAA= Date: Fri, 13 Mar 2015 22:35:49 +0000 Message-ID: References: <20150313154035.GD6431@pfrc> In-Reply-To: <20150313154035.GD6431@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.2.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7B3F807755921842BA6E5CEB76A44A8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "rob.shakir@bt.com" , "idr-chairs@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 22:35:53 -0000 On 3/13/15, 8:40 AM, "Jeffrey Haas" wrote: Jeff: Hi! >On Mon, Mar 09, 2015 at 05:45:13PM +0000, Alvaro Retana (aretana) wrote: >> 5. Security Considerations (Section 10). It is true that malformed >>optional transitive attributes should not cause remote session resets. >>Are remote withdrawals a new threat? Following the logic in the >>introduction, an update with a malformed optional transitive attribute >>may not be properly checked for several hops..but once the error is >>detected then the NLRI may use Treat-as-withdraw.. Assuming an AS-level >>granularity in checking, this won?t cause loops or major disruptions, >>but nonetheless it can result in not everyone receiving the information >>it should.. > >I'm not sure one can really stretch this point to be an attack vector. >Normal BGP operational policy permits an operator to advertise or not a >given prefix. If an upstream injects malformed information and some >subset >of routers are capable of announcing it and others are not the issue >remains >that the upstream reachability is invalid. The inability to advertise (or receive) a prefix because of malformed information is not normal BGP operational policy. That=B9s all I=B9m pointi= ng to: the local ability to advertise/receive is dictated by someone else (the upstream)..which may result in a different transit or just simply not having reachability what should be present. As I mentioned in another e-mail, not all prefixes are made the same. Yes, I realize that all this depends on that upstream (I would even call it an attacker) knowing what will happen potentially several hops downstream.. The odds are obviously reduced as sw is hardened, people implement this document, etc. Thanks! Alvaro. From nobody Fri Mar 13 15:35:55 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-error-handling.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F0EAE1A8735; Fri, 13 Mar 2015 15:35:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-error-handling.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9EE1A872A; Fri, 13 Mar 2015 15:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRBLj48A1ycE; Fri, 13 Mar 2015 15:35:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDCE1A0217; Fri, 13 Mar 2015 15:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1426286151; x=1427495751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UX4kCY2Pn9szfnY4VPhFFvvlxccp+c9q9MUyPoMN5ws=; b=XGLbtmBFfJ1WlNJi2orYe8ZzSRI78oZq9IsT3LsMFt7SfIMJvqmumydT QWn+WGHD6zye9yrVIwJJZpZvL7ySdRYFy+yq2hRZnzHUqvvWRSNJKHdDB 4dwa5c8EupLQH7DsG0rlnRSsEIlAlOWe8yJ5M4/8JPJSziWZIGOeTfSjo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQBxZQNV/4gNJK1bgwaBLATJbwKBLkwBAQEBAQF9hBABAQR5EAIBCA4KLjIlAgQOBR+IEM5WAQEBAQEBAQMBAQEBAQEBG4sXhD4zB4QtAQSKUYNcggiJZYEajAmGbCODbm+BAgY8fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,397,1422921600"; d="scan'208";a="131896527" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP; 13 Mar 2015 22:35:50 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2DMZo6s016522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Mar 2015 22:35:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.38]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 13 Mar 2015 17:35:50 -0500 From: "Alvaro Retana (aretana)" To: Jeffrey Haas Thread-Topic: [Idr] Review of draft-ietf-idr-error-handling-18 Thread-Index: AQHQWpDLKAsEqqfj4UCra5AsX2rR050a5seA///+qAA= Date: Fri, 13 Mar 2015 22:35:49 +0000 Message-ID: References: <20150313154035.GD6431@pfrc> In-Reply-To: <20150313154035.GD6431@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.2.197] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7B3F807755921842BA6E5CEB76A44A8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-error-handling.all@ietf.org" , "rob.shakir@bt.com" , "idr-chairs@ietf.org" Subject: Re: [Idr] Review of draft-ietf-idr-error-handling-18 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 22:35:53 -0000 On 3/13/15, 8:40 AM, "Jeffrey Haas" wrote: Jeff: Hi! >On Mon, Mar 09, 2015 at 05:45:13PM +0000, Alvaro Retana (aretana) wrote: >> 5. Security Considerations (Section 10). It is true that malformed >>optional transitive attributes should not cause remote session resets. >>Are remote withdrawals a new threat? Following the logic in the >>introduction, an update with a malformed optional transitive attribute >>may not be properly checked for several hops..but once the error is >>detected then the NLRI may use Treat-as-withdraw.. Assuming an AS-level >>granularity in checking, this won?t cause loops or major disruptions, >>but nonetheless it can result in not everyone receiving the information >>it should.. > >I'm not sure one can really stretch this point to be an attack vector. >Normal BGP operational policy permits an operator to advertise or not a >given prefix. If an upstream injects malformed information and some >subset >of routers are capable of announcing it and others are not the issue >remains >that the upstream reachability is invalid. The inability to advertise (or receive) a prefix because of malformed information is not normal BGP operational policy. That=B9s all I=B9m pointi= ng to: the local ability to advertise/receive is dictated by someone else (the upstream)..which may result in a different transit or just simply not having reachability what should be present. As I mentioned in another e-mail, not all prefixes are made the same. Yes, I realize that all this depends on that upstream (I would even call it an attacker) knowing what will happen potentially several hops downstream.. The odds are obviously reduced as sw is hardened, people implement this document, etc. Thanks! Alvaro. From nobody Sun Mar 15 13:56:56 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D352A1A1B80 for ; Sun, 15 Mar 2015 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F6IacM_b3X9 for ; Sun, 15 Mar 2015 13:56:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B301A1B74 for ; Sun, 15 Mar 2015 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1263; q=dns/txt; s=iport; t=1426453014; x=1427662614; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SAnNdjzWqz6EMuR7zt6XklS3aNP9hjPaBeLMAkTfAoU=; b=BOWWhbnykc5ulDCbq6pSb94C2OWSirIdg8ToJZYRCDUWB17tHzZrNoFQ 1R64GROQVvxoOnEWkKT6MDNz58jO7jYucFJY1f4XaKf6u8uuyA8hg+DiZ oaM8S69Tjj37HAyI2YCpUyr/rwVSWvlfr/B10ddXSjXCBAZ+Fn8nFqGEG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBQCqaeJU/5NdJa1bgwZSWgTCPIVxgRpDAQEBAQEBfIQTHVcFEgGBACcEDiCIEg3OKAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj3mDHYEUBY84g1eFYJMNIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,405,1422921600"; d="scan'208";a="403599161" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 15 Mar 2015 20:56:53 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t2FKurb1018853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Mar 2015 20:56:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 15 Mar 2015 15:56:53 -0500 From: "Jerome Durand (jerduran)" To: "idr@ietf.org" Thread-Topic: 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf0w== Date: Sun, 15 Mar 2015 20:56:52 +0000 Message-ID: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.86.135] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2697643AA39EEC4285C81B89DEDEBE8D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: David Freedman Subject: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 20:56:56 -0000 Dear all, I think draft-ymbk-idr-rs-bfd-00.txt addresses real issues that need to be = solved somehow and I=92m happy to see work conducted on the topic. However the approach chosen implies that IXP members rely on a mechanism to= be implemented on the route-server, while we believe a direct approach cou= ld be simpler and quicker to implement, and much more reliable. David Freed= man and I have worked on finding a solution for quite some time now and we = are proposing an approach based on BFD, which can be found here: https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt The Idea is simple and it only requires a basic BFD capability between IXP = members. Based on the BFD session state of the learnt BGP next-hop, routes = can be accepted and BFD backed by a member, the decision remains local. While we elaborated this document we discovered that there are real challen= ges in the BFD implementation, for example when there is asymmetric routing= . This is documented in our draft. I believe on the other hand that there i= s a lack of this information in draft-ymbk-idr-rs-bfd-00 at this stage. we = would like to see more information on that in future versions. Thank you, Jerome Durand and=20 David Freedman= From nobody Mon Mar 16 01:56:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315F11A8547; Mon, 16 Mar 2015 01:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuNIC64IePVs; Mon, 16 Mar 2015 01:56:21 -0700 (PDT) Received: from out-9.mail.exa.net.uk (out-9.mail.exa.net.uk [82.219.4.137]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50751A8032; Mon, 16 Mar 2015 01:56:20 -0700 (PDT) Received: from smtp-5.exa.net.uk (unknown [82.219.5.5]) by out-9.mail.exa.net.uk (ExaSMTPD) with ESMTP id EE9471C005C; Mon, 16 Mar 2015 08:56:18 +0000 (GMT) Received: from smtp-5.exa.net.uk (localhost [127.0.0.1]) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTP id DE3A7411F7; Mon, 16 Mar 2015 08:56:18 +0000 (GMT) Received: from mangin.local (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-5.exa.net.uk (ExaSMTPD) with ESMTPSA; Mon, 16 Mar 2015 08:56:18 +0000 (GMT) Message-ID: <55069AAF.2050801@exa-networks.co.uk> Date: Mon, 16 Mar 2015 08:56:15 +0000 From: Thomas Mangin User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: idr-bounces@ietf.org References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> In-Reply-To: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Cc: "idr@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 08:56:23 -0000 Hello Jerome, Hello David, Thank you for this work. Many networks will not use Route Servers due to this problem which did hit quite a few operators over the years on large internet exchanges. This is a reason why some large operators refuse to peer with smaller ones via RS. The first time I heard about the idea, I thought that this mechanism was an elegant solution to prevent traffic black-holing. This draft means that a network should be able to prevent loss on outgoing traffic. However should the peer not have the feature enabled, return traffic could still suffer: BFD notice the session is down, the routes are removed from the FIB, traffic goes via another path, but still tries to come back via the dead L2 as the peer does not implement the feature. Was it what you had in mind when speaking of asymmetric routing, or was it something else ? This case does not remove any of the merit of this draft, operators are still better with it than without, but seems to indicate that other mechanisms could be considered to complement it. Naively, I would thing that something which would for example allow the tagging of routes with no-export to the RS(or a removal) should a number of peers on a same L2 suddenly became unreachable due to BFD be acceptable in a RS scenario. Sincerely, Thomas > Dear all, > > I think draft-ymbk-idr-rs-bfd-00.txt addresses real issues that need to be solved somehow and Im happy to see work conducted on the topic. > > However the approach chosen implies that IXP members rely on a mechanism to be implemented on the route-server, while we believe a direct approach could be simpler and quicker to implement, and much more reliable. David Freedman and I have worked on finding a solution for quite some time now and we are proposing an approach based on BFD, which can be found here: > > https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt > > The Idea is simple and it only requires a basic BFD capability between IXP members. Based on the BFD session state of the learnt BGP next-hop, routes can be accepted and BFD backed by a member, the decision remains local. > > While we elaborated this document we discovered that there are real challenges in the BFD implementation, for example when there is asymmetric routing. This is documented in our draft. I believe on the other hand that there is a lack of this information in draft-ymbk-idr-rs-bfd-00 at this stage. we would like to see more information on that in future versions. > > Thank you, > > Jerome Durand > and > David Freedman > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- Thomas Mangin Director - Exa Networks http://exa.net.uk/about/contact-us From nobody Mon Mar 16 02:20:40 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C768A1A86EC for ; Mon, 16 Mar 2015 02:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjV5cyjiL2bo for ; Mon, 16 Mar 2015 02:20:30 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.116]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC721A86EB for ; Mon, 16 Mar 2015 02:20:29 -0700 (PDT) Received: from [193.109.255.99] by server-12.bemta-14.messagelabs.com id 9E/A1-09550-C50A6055; Mon, 16 Mar 2015 09:20:28 +0000 X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-11.tower-48.messagelabs.com!1426497627!9241462!1 X-Originating-IP: [80.168.41.245] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23021 invoked from network); 16 Mar 2015 09:20:28 -0000 Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-11.tower-48.messagelabs.com with SMTP; 16 Mar 2015 09:20:28 -0000 Received: from [80.168.41.252] (port=38599 helo=SRVGREXCAS05.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YXRCF-00063m-C3 (return-path ); Mon, 16 Mar 2015 09:20:27 +0000 Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS05.claranet.local ([fe80::3915:cdff:95ac:dcdb%11]) with mapi id 14.03.0224.002; Mon, 16 Mar 2015 09:20:16 +0000 From: David Freedman To: Thomas Mangin Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050ez1mAgAAC6kI= Date: Mon, 16 Mar 2015 09:20:15 +0000 Message-ID: References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com>, <55069AAF.2050801@exa-networks.co.uk> In-Reply-To: <55069AAF.2050801@exa-networks.co.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Original-Recipient: thomas.mangin@exa-networks.co.uk X-Original-Sender: david.freedman@uk.clara.net X-Original-Recipient: idr@ietf.org X-Clara-Helo: SRVGREXCAS05.claranet.local X-BorderScout: cm=0.00 ca=0.00 time=4270 size=2934 X-BorderScout-CM-Score: 0 X-BorderScout-CA-Score: 0 X-ClamAV: clean X-Cloudmark: 0.00 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 09:20:38 -0000 =0A= =0A= >Many networks will not use Route Servers due to this problem which did=0A= >hit quite a few operators over the years on large internet exchanges.=0A= >This is a reason why some large operators refuse to peer with smaller=0A= >ones via RS.=0A= =0A= Yes, I can speak as such an operator, our default policy is not to use RS a= fter=0A= suffering repeated L2 partitioning on a particular exchange many years ago.= =0A= =0A= >This draft means that a network should be able to prevent loss on=0A= >outgoing traffic. However should the peer not have the feature enabled,=0A= >return traffic could still suffer: BFD notice the session is down, the=0A= =0A= The idea in this draft requires both sides to support it, the BFD sessions= =0A= are set up from both sides, toward the other side (i.e really bi-directiona= l) =0A= we don't care about the RS other than for a BGP session to bind the next=0A= hop discovery to. =0A= =0A= >This case does not remove any of the merit of this draft, operators are=0A= >still better with it than without, but seems to indicate that other=0A= >mechanisms could be considered to complement it.=0A= >Naively, I would thing that something which would for example allow the=0A= >tagging of routes with no-export to the RS(or a removal) should a number= =0A= >of peers on a same L2 suddenly became unreachable due to BFD be=0A= >acceptable in a RS scenario.=0A= =0A= I know of an operator which has set up a number of static BFD sessions=0A= across an exchange, and has a script, which, if a number of these=0A= are seen to go down, shuts down the RS session.=0A= =0A= Dave. =0A= From nobody Mon Mar 16 03:59:58 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21581A8701 for ; Mon, 16 Mar 2015 03:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hi_IhHRKPH15 for ; Mon, 16 Mar 2015 03:59:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50AA1A86F7 for ; Mon, 16 Mar 2015 03:59:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YXSkS-0006iD-7y; Mon, 16 Mar 2015 10:59:52 +0000 Date: Mon, 16 Mar 2015 11:59:51 +0100 Message-ID: From: Randy Bush To: David Freedman In-Reply-To: References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 10:59:57 -0000 hi david, clue bat, please. how does your scheme tell the rs to give me next best paths instead of those over the failing link? how likely are we to get the bfd hacks from C, J, A, B, ...? in our draft, we are trying to minimize dependence on vendor hacks for a reason. their frelling bfds are not even fully compatible today. but i definitely appreciate this discussion as opposed to reading the completely engineering-free discussions on the ietf list etc. and i look forward to discussing this with you in dallas. randy From nobody Mon Mar 16 04:08:47 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94E41A00BE for ; Mon, 16 Mar 2015 04:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NwhW-FAE81W for ; Mon, 16 Mar 2015 04:08:43 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB681A007C for ; Mon, 16 Mar 2015 04:08:42 -0700 (PDT) Received: from [193.109.255.99] by server-13.bemta-14.messagelabs.com id C6/8E-13815-9B9B6055; Mon, 16 Mar 2015 11:08:41 +0000 X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-14.tower-48.messagelabs.com!1426504119!9283843!1 X-Originating-IP: [80.168.41.245] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17742 invoked from network); 16 Mar 2015 11:08:39 -0000 Received: from staff03.mail.eu.clara.net (HELO staff03.mail.eu.clara.net) (80.168.41.245) by server-14.tower-48.messagelabs.com with SMTP; 16 Mar 2015 11:08:39 -0000 Received: from [80.168.41.252] (port=54742 helo=SRVGREXCAS05.claranet.local) by staff03.mail.eu.clara.net (staff03.mail.eu.clara.net [80.168.41.245]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YXSsx-0003RZ-AL (return-path ); Mon, 16 Mar 2015 11:08:39 +0000 Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS05.claranet.local ([fe80::3915:cdff:95ac:dcdb%11]) with mapi id 14.03.0224.002; Mon, 16 Mar 2015 11:08:38 +0000 From: David Freedman To: Randy Bush Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050ez1mAgAAC6kKAAB+egIAAAlmA Date: Mon, 16 Mar 2015 11:08:38 +0000 Message-ID: References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <71BEB750BEFA5D4BBE86ADB07753386E@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Original-Recipient: randy@psg.com X-Original-Sender: david.freedman@uk.clara.net X-Original-Recipient: idr@ietf.org X-Clara-Helo: SRVGREXCAS05.claranet.local X-BorderScout: cm=0.00 ca=0.00 time=4406 size=2664 X-BorderScout-CM-Score: 0 X-BorderScout-CA-Score: 0 X-ClamAV: clean X-Cloudmark: 0.00 Archived-At: Cc: idr wg Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:08:46 -0000 On 16/03/2015 10:59, "Randy Bush" wrote: >hi david, > >clue bat, please. how does your scheme tell the rs to give me next best >paths instead of those over the failing link? It doesn't , but then, if the exchange is having issues, I won't be sending=20 any further traffic over it until it is repaired, so I would stop trusting the RS at this point. > >how likely are we to get the bfd hacks from C, J, A, B, ...? in our >draft, we are trying to minimize dependence on vendor hacks for a >reason. their frelling bfds are not even fully compatible today. Being that we are already in 'hack' territory (http://seclists.org/nanog/2015/Feb/259) This one IMHO requires the least protocol changes (we just register a new diagnostic flag from an existing IANA FCFS registry), no changes needed to BGP or the RS implementation. Saying this, it is useful for the RS operator to be aware that there is a problem (but then again, being that in almost all cases they run the exchange itself and , you would hope, have monitoring, I guess they would already be so) > >but i definitely appreciate this discussion as opposed to reading the >completely engineering-free discussions on the ietf list etc. As much as I would love to be there, I can't, but I believe Jerome is sending a Rep. Dave. From nobody Mon Mar 16 04:39:44 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E359D1A0110 for ; Mon, 16 Mar 2015 04:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4W9Mh3ituBy for ; Mon, 16 Mar 2015 04:39:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6ADA1A00E4 for ; Mon, 16 Mar 2015 04:39:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YXTMx-0006wd-If; Mon, 16 Mar 2015 11:39:39 +0000 Date: Mon, 16 Mar 2015 12:39:38 +0100 Message-ID: From: Randy Bush To: David Freedman In-Reply-To: References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: idr wg Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:39:43 -0000 as you know, i also have not trusted route servers. arnold asked what would allow me to extend a little trust. draft-ymbk-idr-rs-bfd is an attempt. >> clue bat, please. how does your scheme tell the rs to give me next >> best paths instead of those over the failing link? > It doesn't , but then, if the exchange is having issues, I won't be > sending any further traffic over it until it is repaired, so I would > stop trusting the RS at this point. we see many cases of small inter-peer failures where other links are just fine. it can be an interface, a router-to-switch cable, ... this is why we want to tell the rs to back off only the failing link. >> how likely are we to get the bfd hacks from C, J, A, B, ...? in our >> draft, we are trying to minimize dependence on vendor hacks for a >> reason. their frelling bfds are not even fully compatible today. > > This one IMHO requires the least protocol changes (we just register a > new diagnostic flag from an existing IANA FCFS registry), no changes > needed to BGP or the RS implementation. your draft requires changes to bfd. ymbk is trying to avoid that. a hack to bird is something we can do ourselves, does not rely on the vendors. but this is a call for adoption. imiho, the wg should adopt both drafts so we can sort it in the wg. randy From nobody Mon Mar 16 10:04:46 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76231A88E0 for ; Mon, 16 Mar 2015 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdKE75v9DKmu for ; Mon, 16 Mar 2015 10:04:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 46FBA1A88E6 for ; Mon, 16 Mar 2015 10:04:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0D213C0B9; Mon, 16 Mar 2015 13:04:42 -0400 (EDT) Date: Mon, 16 Mar 2015 13:04:41 -0400 From: Jeffrey Haas To: "Jerome Durand (jerduran)" Message-ID: <20150316170441.GB23077@pfrc> References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "idr@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:04:44 -0000 [Responding from the top of the thread intentionally.] On Sun, Mar 15, 2015 at 08:56:52PM +0000, Jerome Durand (jerduran) wrote: > Dear all, > > I think draft-ymbk-idr-rs-bfd-00.txt addresses real issues that need to be solved somehow and I?m happy to see work conducted on the topic. > > However the approach chosen implies that IXP members rely on a mechanism to be implemented on the route-server, while we believe a direct approach could be simpler and quicker to implement, and much more reliable. David Freedman and I have worked on finding a solution for quite some time now and we are proposing an approach based on BFD, which can be found here: > > https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt Things I like about your draft: - Autodiscovery of the endpoint for BFD just by gleaning the nexthops. Things that need a bit of clarification: - What procedures do you do if the remote side doesn't support BFD? - What about if you see the remote nexthop but the remote nexthop doesn't see you? Things I don't like: - You're trying to use BFD diag codes without state changes as state for the session. Wearing my BFD chair hat, I have some reservations about this. The point raised in the thread about draft-ymbk is something I think is worth addressing: Give the RS a chance to unhide paths if you can't use them. All of this said, I think the core behavior of getting nexthop validation via BFD is the key property that gets the best improvement. I think this gives us a basis to refine both proposals. -- Jeff From nobody Mon Mar 16 11:19:29 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF61A89FE for ; Mon, 16 Mar 2015 11:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qQ2DhutQ0BU for ; Mon, 16 Mar 2015 11:19:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEBE1A8A06 for ; Mon, 16 Mar 2015 11:19:08 -0700 (PDT) Received: from DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) by DM2PR05MB669.namprd05.prod.outlook.com (10.141.176.12) with Microsoft SMTP Server (TLS) id 15.1.112.19; Mon, 16 Mar 2015 18:18:47 +0000 Received: from mkozich-sslvpn-nc.jnpr.net (66.129.241.12) by DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 16 Mar 2015 18:18:45 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: Date: Mon, 16 Mar 2015 14:18:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <60B9A29D-903F-4441-9CAC-A83AFB7491A9@juniper.net> References: <1425311881323.66767@nist.gov> <008301d05519$aa21a760$fe64f620$@ndzh.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN3PR0301CA0024.namprd03.prod.outlook.com (25.160.180.162) To DM2PR05MB734.namprd05.prod.outlook.com (10.141.178.22) Authentication-Results: nist.gov; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB734; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB669; X-Forefront-Antispam-Report: BMV:0; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(377454003)(24454002)(77156002)(53416004)(50466002)(62966003)(33656002)(40100003)(86362001)(50986999)(19580405001)(46102003)(87976001)(122386002)(19580395003)(92566002)(97756001)(23726002)(66066001)(46406003)(1720100001)(47776003)(15975445007)(77096005)(50226001)(42186005)(57306001)(2950100001)(36756003)(110136001)(7059030)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB734; H:mkozich-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5001010)(5005006); SRVR:DM2PR05MB734; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB734; X-Forefront-PRVS: 05177D47DC X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2015 18:18:45.6962 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB734 X-OriginatorOrg: juniper.net Archived-At: Cc: "idr@ietf.org" , Hares Susan Subject: Re: [Idr] IETF-92 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:19:27 -0000 Done. Thanks, --John On Mar 11, 2015, at 3:43 PM, Sriram, Kotikalapudi = wrote: > Sue: > John: >=20 > When you update the agenda, can you please include links to the=20 > recent updated versions of the I-Ds for route leaks as follows? > (I would feel bad about making people go through older versions of the = drafts.) >=20 > Please replace this - >=20 > Route Leak Detection [Sriram Kotikalapudi] [10 minutes]=20 > = https://tools.ietf.org/html/draft-sriram-route-leak-detection-mitigation-0= 0 > [companion draft in grow > = https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-= 00] >=20 > With this - >=20 > Route Leak Detection [K. Sriram] [10 minutes]=20 > = http://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigatio= n-00 =20 > [companion draft in grow > = http://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-0= 1 ] >=20 > Thank you. > Sriram=20 >=20 From nobody Mon Mar 16 11:23:58 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD251A8A0F for ; Mon, 16 Mar 2015 11:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBJ6FoTwBkQf for ; Mon, 16 Mar 2015 11:23:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7581A89EB for ; Mon, 16 Mar 2015 11:23:53 -0700 (PDT) Received: from mkozich-sslvpn-nc.jnpr.net (66.129.241.12) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 16 Mar 2015 18:23:50 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <64793C0C-484F-4281-ACA4-0B6124FA4D7D@juniper.net> Date: Mon, 16 Mar 2015 14:23:50 -0400 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: BN3PR0401CA0009.namprd04.prod.outlook.com (25.162.159.147) To CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB731; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(50986999)(122386002)(50466002)(23726002)(47776003)(66066001)(110136001)(36756003)(33656002)(229853001)(107886001)(40100003)(53416004)(50226001)(450100001)(62966003)(77156002)(46406003)(87976001)(77096005)(19580395003)(15975445007)(97756001)(57306001)(86362001)(46102003)(42186005)(92566002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB731; H:mkozich-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR05MB731; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB731; X-Forefront-PRVS: 05177D47DC X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2015 18:23:50.5992 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB731 Archived-At: Subject: [Idr] Slides and other meeting-related things X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:23:57 -0000 First, thanks to Robert for being the first person to submit his slides. = I've posted them, you can find them at = https://datatracker.ietf.org/meeting/92/materials.html Second, this is a reminder to other presenters that you, too, can submit = your slides now. No need to wait for the 24-hour deadline. Getting your = slides in early may help since people can review them ahead of time and = be more prepared for productive discussion. Third, as usual we would appreciate early volunteers to take notes and = monitor the Jabber room. Thanks, --John= From nobody Tue Mar 17 03:36:05 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C391A01FA for ; Tue, 17 Mar 2015 03:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqeL38SxdIUK for ; Tue, 17 Mar 2015 03:36:00 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFC91A01F9 for ; Tue, 17 Mar 2015 03:36:00 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YXoqq-0007GJ-M3; Tue, 17 Mar 2015 10:35:57 +0000 Date: Tue, 17 Mar 2015 11:35:55 +0100 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20150316170441.GB23077@pfrc> References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> <20150316170441.GB23077@pfrc> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "idr@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:36:02 -0000 > - Autodiscovery of the endpoint for BFD just by gleaning the nexthops. in reality, often A receives some paths from B but B does not send any paths to A. so you will need a bit more for A to 'discover' the next hop. randy From nobody Tue Mar 17 06:53:21 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3685E1A19E3 for ; Tue, 17 Mar 2015 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n39AG_Rfdzxx for ; Tue, 17 Mar 2015 06:53:17 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) by ietfa.amsl.com (Postfix) with ESMTP id 363551A1A2E for ; Tue, 17 Mar 2015 06:53:15 -0700 (PDT) Received: from [195.245.230.51] by server-8.bemta-3.messagelabs.com id E0/14-07208-BC138055; Tue, 17 Mar 2015 13:53:15 +0000 X-Env-Sender: david.freedman@uk.clara.net X-Msg-Ref: server-4.tower-33.messagelabs.com!1426600394!9864111!1 X-Originating-IP: [80.168.41.244] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24333 invoked from network); 17 Mar 2015 13:53:14 -0000 Received: from staff02.mail.eu.clara.net (HELO staff02.mail.eu.clara.net) (80.168.41.244) by server-4.tower-33.messagelabs.com with SMTP; 17 Mar 2015 13:53:14 -0000 Received: from [80.168.41.252] (port=52827 helo=SRVGREXCAS05.claranet.local) by staff02.mail.eu.clara.net (staff02.mail.eu.clara.net [80.168.41.244]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1YXrvm-00089M-8V (return-path ); Tue, 17 Mar 2015 13:53:14 +0000 Received: from SRVGREXMB06.claranet.local ([fe80::70d4:3322:86e0:c10c]) by SRVGREXCAS05.claranet.local ([fe80::3915:cdff:95ac:dcdb%11]) with mapi id 14.03.0224.002; Tue, 17 Mar 2015 13:51:28 +0000 From: David Freedman To: Randy Bush , Jeffrey Haas Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050fV9CAgAEltoCAADaQAA== Date: Tue, 17 Mar 2015 13:51:26 +0000 Message-ID: References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> <20150316170441.GB23077@pfrc> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.26.6.254] Content-Type: text/plain; charset="us-ascii" Content-ID: <027D2F6BF95FDE4CA4A8CBE3F138C1A0@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Original-Recipient: randy@psg.com X-Original-Sender: david.freedman@uk.clara.net X-Original-Recipient: jhaas@pfrc.org X-Original-Recipient: jerduran@cisco.com X-Original-Recipient: idr@ietf.org X-Clara-Helo: SRVGREXCAS05.claranet.local X-BorderScout: cm=0.00 ca=0.00 time=3535 size=2311 X-BorderScout-CM-Score: 0 X-BorderScout-CA-Score: 0 X-ClamAV: clean X-Cloudmark: 0.00 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 13:53:19 -0000 On 17/03/2015 10:35, "Randy Bush" wrote: >> - Autodiscovery of the endpoint for BFD just by gleaning the nexthops. > >in reality, often A receives some paths from B but B does not send any >paths to A. so you will need a bit more for A to 'discover' the next >hop. That's actually covered in the draft, when the BFD session transitions to up (nod to Jeff here) we set a diagnostic flag explaining that we did this because we saw some routes (from the RS) with next hop of the remote system. The session is established between systems A and B when either A has routes for B, or B has routes for A. The session stays until both sides agree they are not receiving routes destined for either party, at which point it is pruned.=20 Dave. > >randy From nobody Tue Mar 17 15:11:33 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0C1A8930 for ; Tue, 17 Mar 2015 15:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvjVd-qOKj9M for ; Tue, 17 Mar 2015 15:11:31 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557991A892C for ; Tue, 17 Mar 2015 15:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1756; q=dns/txt; s=iport; t=1426630291; x=1427839891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FFicgrOYgmgdDLUUgJRY/nVlK/EmO8X318rmhrna4Ik=; b=RQqSHOd8MmLf7GquI3HIp6TQDHmI8bKgsb+GFyD64e50ixeoDF8LJV8r YtwXV6sUwuKVS/Epd8t6+0tFU1mbekZuL+sWweodxNaHgPT24z82pUG32 b2N2Ci3I57S5NFc14Bl3+hVUOVLZpDxJ1ZnGpwMkYOhogCY85flypT8/m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CCBQCXpQhV/5ldJa1bgwaBMMt4AoE8TAEBAQEBAX2EEAEBAwEdXAULAgEIDjgyJQIEDiCIDAjLIwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLF4Q+MweDF4EWAQSQQIlqgRuGBYx9I4IygTyCM38BAQE X-IronPort-AV: E=Sophos;i="5.11,418,1422921600"; d="scan'208";a="401348673" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 17 Mar 2015 22:11:30 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2HMBU2P005491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 22:11:30 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.225]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 17:11:30 -0500 From: "Jerome Durand (jerduran)" To: Jeffrey Haas Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050fq6KAgAHoCoA= Date: Tue, 17 Mar 2015 22:11:30 +0000 Message-ID: <8D790461-FE07-4B02-922B-22561CA6C926@cisco.com> References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> <20150316170441.GB23077@pfrc> In-Reply-To: <20150316170441.GB23077@pfrc> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.223.148] Content-Type: text/plain; charset="Windows-1252" Content-ID: <789BBE5BC4896844BA1973BFFA16CF6C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 22:11:32 -0000 Hi Jeffrey, Thank you for taking the time to read the document and providing comments. > Things that need a bit of clarification: > - What procedures do you do if the remote side doesn't support BFD?=20 Idea is that it is up to admin to decide what we wants to do with routes fo= r any next-hop depending on its corresponding BFD session state. As an exam= ple one could decide to keep accepting routes if BFD never reaches an up st= ate, but with a lower local-pref if desired. This point could be let to imp= lementation. This is a good point we can try to document this in next versi= ons. > - What about if you see the remote nexthop but the remote nexthop doesn't > see you? Remote next-hop would signal BFD session state in next control messages and= everyone would agree that session state is now down. At this point policy = can be applied on corresponding routes. We could detail how solution solves= various types of problems that can be met on IXPs if this can help global = understanding. > Things I don't like: > - You're trying to use BFD diag codes without state changes as state for = the > session. Wearing my BFD chair hat, I have some reservations about this. Well we do this for session ageing which we believe is crucial for scalabil= ity and manageability. We are trying to signal that BFD session is needed o= r not needed locally. This is different from BFD session state and that=92s= why we kept that at another level. In other words we say: =AB Session is U= P but personnaly I don=92t need a session with you anymore. Do you need to = keep the session with me? =BB Idea of using diag codes is to do this signal= ling without changing BFD protocol definition. Thanks, Jerome From nobody Wed Mar 18 09:43:22 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B139A1A6FF1 for ; Wed, 18 Mar 2015 09:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.69 X-Spam-Level: X-Spam-Status: No, score=-98.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73vTd5J5KnDr for ; Wed, 18 Mar 2015 09:43:18 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F8A1A1BF5 for ; Wed, 18 Mar 2015 09:43:18 -0700 (PDT) Received: by oifl3 with SMTP id l3so11296354oif.0 for ; Wed, 18 Mar 2015 09:43:17 -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=9Kv4SQGOdn5QKIqZWz4obQdEthvBOcvkUxCsXAvbpdo=; b=JZjAgISVvrScdHPEzY9MUpUGlQMQZjKIKluNT3prcOZQzq+4wLMR9hqfS3Guuo8bC6 w2bD36VSjFFwqjFH0RtSS9CAgmk4EZL6R8If3hBvbedvg4nRuVLhkt0vh6zPl+mJjeXj ANdeIBuoVLqIOFZrx67KdzuZd8So0ALqxHX3PezIVUqET+l4LJFfM1LvincvrOluTwy9 UlQ3EMsWnYcChTS/A5gulsL6OGmDs5WhnoSIB8UAHBmUm1Gtamja1+AD2PN8Ua3BkRNL P8saPlWJEZRJw3dGFFOM+k2qnQJmXfmvPGeZcTIMi+iOjbmB+Db/mMpE7vS0tMduwF6s mbBw== MIME-Version: 1.0 X-Received: by 10.182.126.40 with SMTP id mv8mr12854478obb.54.1426696997573; Wed, 18 Mar 2015 09:43:17 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Wed, 18 Mar 2015 09:43:17 -0700 (PDT) Date: Wed, 18 Mar 2015 12:43:17 -0400 Message-ID: From: Alia Atlas To: "draft-ietf-idr-ls-distribution@tools.ietf.org" , "idr@ietf. org" Content-Type: multipart/alternative; boundary=e89a8fb1f764be1971051192c71f Archived-At: Subject: [Idr] AD Review: draft-ietf-idr-ls-distribution X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:43:20 -0000 --e89a8fb1f764be1971051192c71f Content-Type: text/plain; charset=UTF-8 As is customary upon receiving a publication request, I have done my AD review of draft-ietf-idr-ls-distribution. First, thanks for the hard work on this very useful and non-trivial specification. Second, I have found a number of clarifications and issues that I would like to see resolved in the draft. I will start an IETF Last Call so that you can get additional comments in parallel. Because of the upcoming IETF, I expect this to run longer - ending April 8. 1) In Sec 3.2, 3rd paragraph last sentence, it says: "This is done as specified in [RFC4760], by using capability code 1 (multi-protocol BGP), with an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN flavor." Could you please turn this into non-colloquial language with clear requirements language? Can one support "the VPN flavor" but not the regular? 2) On p. 9, the Route Distinguisher is introduced and its length is included - but no reference is given nor length specified. Could you please provide both? 3) In Sec 3.2.1, second paragraph, it says "We use Autonomous System (AS) Number and BGP-LS Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as described in Section 3.2.1.1." I suspect that "Paragraph 2" is intended to refer to the last paragraph on p. 11 - but that isn't a clear way to reference it; also the Identifier is not referred to as a "BGP-LS Identifier" but merely an Identifier. Also, instead of "we" perhaps "BGP-LS". 4) In Sec 3.2.2, I see that link descriptors are actually only a unidirectional representation. Could you please mention this when the link NLRI is introduced? 5) In the NLRI format, I see a 64 bit identifier. From the discussion (last paragraph in p. 11), it looks like this 64-bit identifier is intended to be the 5-bit "Routing Universe Identifier" which is supposed to indicate the protocol plus routing instance??? 5) In Sec 3.2.1.4: I see the OSPF Area-ID listed. How are IS-IS levels handled? I see the Node Attribute TLV (1027) but this seems to require that a link would have to have its remote and local nodes looked up to find the associated IS-IS Area Identifier. What would be actually really useful is to describe, in the introduction, the different handling for IS-IS and OSPF in the encapsulations and why they differ. 6) In Sec 3.2.2 3rd from last paragraph: Can both IPv4 AND IPv6 addresses both be included in the link descriptor? Presumably the same logic that prevents the link local/remote identifiers from being included would apply? Also, why are the neighbor addresses included for the Link Descriptor when the remote node's descriptor should already be in the Remote Node Descriptor? 7) In Sec 3.2.3.1: It says "The OSPF Route Type field values are defined in the OSPF protocol, and can be one of the following". Could you please add a reference to which version of OSPF and what field you are describing? I suspect it is the LSA types and they are different values between OSPFv2 and OSPFv3. This section could benefit from some clarity. 8) In Sec 3.3.1.2: Please add a reference and describe what an "Area Identifier (variable)" is. 9) Sec 3.3.1.5: I like the idea of this - but an example or two in terms of encoding/parsing would be useful. You have a couple pointers - but it could use another level of explanation. 10) Sec 3.3.2.2: I am not clear what the rationale for deciding what protocols to include here is. For instance, is mLDP considered a different protocol or a subset of LDP? I would like to see a short paragraph discussing how this information might be used or what criteria would be applied to decide if another protocol should be added. 8 bits is a pretty small space... 11) Sec 3.3.2.3: " If a source protocol (e.g. IS-IS) does not support a Metric width of 32 bits then the high order octet MUST be set to zero." Surely you mean that if the source protocol supports a metric width shorter than 32 bits, then the metric is placed in the bottom of the word and the high order bits from the supported metric width to 32 MUST be set to 0. As written, it assumes that any source protocol that doesn't support 32 bits of metric must support exactly 24 bits. 12) Sec 3.3.2.5: Please correct the sentence that claims "Note that there is no SRLG TLV in OSPF-TE". A simple browsing in the IANA registry ( http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#subtlv2 ) clearly shows it defined: 16Shared Risk Link Group (variable)[RFC4203 ] 13) Sec 3.3.3.1: How large are the bit fields that are mashed together from IS-IS and OSPF to form the IGP Flags TLV? Can you please add some guidance on when new flags should be allocated? 14) Sec 3.3.3.2 and Sec 3.3.3.3: Please add a reference for OSPF TAGs. draft-acee-ospf-admin-tags-01 seems to be the corresponding one. I think that the reference can be Informational. 15) Sec 3.3.3.4: The reference to RFC5305 is, I presume to Section 4. That would be useful to clarify since it isn't easy to find. Similarly, where does the information come from in OSPF? Could you please add a reference? 16) Sec 3.5: Can you please provide more guidance here around what Protocol-ID to use for inter-AS links - particularly if they are not in the IGP? Are there any issues around the Protocol-ID implying the format for data that an inter-AS link might have? 17) Sec 5 IANA Considerations: There are several fields (i.e. MPLS protocols, IGP Flags, etc) that are not included in the IANA Considerations. The authors and document shepherd should go through and describe how each field that is not managed by IANA would have additional values added - or whether that isn't expected and why. 18) Sec 6.2.1: I assume that by "does not mandate", the authors mean "we're not doing it now"? It's clearly absurd and ludicrous to think that BGP-LS wouldn't need some type of extensions - whether that is topology-related YANG models or something else. Please figure out what you want to say other than "someone else's problem" and put it in here. Thanks again for the hard work so far, Alia --e89a8fb1f764be1971051192c71f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As is customary upon receiving a publication request,= I have done my AD review of draft-ietf-idr-ls-distribution.=C2=A0 First, t= hanks for the hard work on this very useful and non-trivial specification.= =C2=A0 Second, I have found a number of clarifications and issues that I wo= uld like to see resolved in the draft.

I will star= t an IETF Last Call so that you can get additional comments in parallel.=C2= =A0 Because of the upcoming IETF, I expect this to run longer - ending Apri= l 8. =C2=A0


1) In Sec 3.2, 3rd paragraph last = sentence, it says:
"This is done as specified=C2=A0in [RFC4760], by usi= ng capability code 1 (multi-protocol BGP), with=C2=A0an AFI 16388 / SAFI 71 a= nd AFI 16388 / SAFI TBD for the VPN flavor." =C2=A0 Could you please t= urn this into non-colloquial language with clear requirements language?=C2= =A0 Can one support "the VPN flavor" but not the regular? =C2=A0<= /span>

2) On p. 9, the Route Distinguisher is introduced and = its length is included - but no reference is given nor length specified.=C2= =A0 Could you please provide both?

3) In Sec 3.2.1, se= cond paragraph, it says "We use Autonomous System (AS) Number and BGP-LS= =C2=A0Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as=C2= =A0described in Section 3.2.1.1."
I suspect that "= Paragraph 2" is intended to refer to the last paragraph on p. 11 - but= that isn't a clear way to reference it; also the Identifier is not ref= erred to as a "BGP-LS Identifier" but merely an Identifier.=C2=A0= Also, instead of "we" perhaps "BGP-LS".

=
4) In Sec 3.2.2, I see that link descriptors are actually only a= unidirectional representation.=C2=A0 Could you please mention this when th= e link NLRI is introduced?

5) In the NLRI format, = I see a 64 bit identifier. From the discussion (last paragraph in p. 11), i= t looks like this 64-bit identifier is intended to be the 5-bit "Routi= ng Universe Identifier" which is supposed to indicate the protocol plu= s routing instance???

5) In Sec 3.2.1.4: I see the OSPF Area-ID listed.=C2=A0 How are IS-IS le= vels handled?=C2=A0 I see the Node Attribute TLV (1027) but this seems to r= equire that a link would have to have its remote and local nodes looked up = to find the associated IS-IS Area Identifier.=C2=A0 What would be actually = really useful is to describe, in the introduction, the different handling f= or IS-IS and OSPF in the encapsulations and why they differ. =C2=A0

6) In Sec 3.2.2 =C2=A03rd from last paragraph: =C2=A0Can = both IPv4 AND IPv6 addresses both be included in the link descriptor?=C2=A0= Presumably the same logic that prevents the link local/remote identifiers = from being included would apply?=C2=A0 Also, why are the neighbor addresses= included for the Link Descriptor when the remote node's descriptor sho= uld already be in the Remote Node Descriptor? =C2=A0

7) In Sec 3.2.3.1: =C2=A0It says "The OSPF Ro= ute Type field values are defined in the OSPF protocol,=C2=A0and can be one o= f the following".=C2=A0 Could you please add a reference to which vers= ion of OSPF and what field you are describing?=C2=A0 I suspect it is the LS= A types and they are different values between OSPFv2 and OSPFv3.=C2=A0 This= section could benefit from some clarity.

8) In Sec 3.3.1.2: =C2=A0Please add a reference and desc= ribe what an "Area Identifier (variable)" is. =C2=A0

9) Sec 3.3.1.5: =C2=A0I like th= e idea of this - but an example or two in terms of encoding/parsing would b= e useful.=C2=A0 You have a couple pointers - but it could use another level= of explanation.

10) Sec 3.3.2.2: =C2=A0I am not clear what the rationale for deciding what pr= otocols to include here is.=C2=A0 For instance, is mLDP considered a differ= ent protocol or a subset of LDP?=C2=A0 I would like to see a short paragrap= h discussing how this information might be used or what criteria would be a= pplied to decide if another protocol should be added. =C2=A08 bits is a pre= tty small space...

11) Sec 3.3.2.3: =C2=A0"=C2=A0If a source protocol (e.g.=C2=A0IS-IS) does not sup= port a Metric width of 32 bits then the high order=C2=A0octet MUST be set to= zero." =C2=A0 Surely you mean that if the source protocol supports a = metric width shorter than 32 bits, then the metric is placed in the bottom = of the word and the high order bits from the supported metric width to 32 M= UST be set to 0.=C2=A0 As written, it assumes that any source protocol that= doesn't support 32 bits of metric must support exactly 24 bits.=

12) Sec 3.3.2.5: =C2=A0Please= correct the sentence that claims "Note that there is no SRLG TLV in O= SPF-TE".=C2=A0 A simple browsing in the IANA registry =C2=A0(http://www.iana.org/assignments/ospf-traffic-eng-tlvs/= ospf-traffic-eng-tlvs.xhtml#subtlv2 )=C2=A0clearly shows it define= d:

Subject:

Some background = on the L3VPN Service YANG Model work

Date: =

Wed, 04 Mar 2015 14:40:52 = +0100

From:

Benoit Claise <bclaise@cisco.com>

To:

l3sm@ietf.org

16Shared Risk = Link Group (variable)[RFC4203<= /a>]

14) Sec 3.3.3.= 2 and Sec 3.3.3.3: =C2=A0Please add a refere= nce for OSPF TAGs. =C2=A0draft-acee-ospf-admin-tags-01 seems to be the corres= ponding one.=C2=A0 I think that the reference can be Informational.<= /div>

15) Sec 3.3.3.4: =C2=A0The ref= erence to RFC5305 is, I presume to Section 4.=C2=A0 That would be useful to= clarify since it isn't easy to find.=C2=A0 Similarly, where does the i= nformation come from in OSPF?=C2=A0 Could you please add a reference?

16) Sec 3.5: =C2=A0Can you please provide more guidance her= e around what Protocol-ID to use for inter-AS links - particularly if they = are not in the IGP?=C2=A0 Are there any issues around the Protocol-ID imply= ing the format for data that an inter-AS link might have?=C2=A0
17) Sec 5 IANA Considerations: =C2=A0There are several fields (i.= e. MPLS protocols, IGP Flags, etc) that are not included in the IANA Consid= erations.=C2=A0 The authors and document shepherd should go through and des= cribe how each field that is not managed by IANA would have additional valu= es added - or whether that isn't expected and why.

<= /div>
18) Sec 6.2.1: =C2=A0I assume that by "does not mandate", the au= thors mean "we're not doing it now"?=C2=A0 It's clearly a= bsurd and ludicrous to think that BGP-LS wouldn't need some type of ext= ensions - whether that is topology-related YANG models or something else.= =C2=A0 Please figure out what you want to say other than "someone else= 's problem" and put it in here.

Thanks a= gain for the hard work so far,
Alia
=

--e89a8fb1f764be1971051192c71f-- From nobody Wed Mar 18 09:44:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667361A854B; Wed, 18 Mar 2015 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N2CK4ouOofY; Wed, 18 Mar 2015 09:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 137541A86E3; Wed, 18 Mar 2015 09:44:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318164424.18853.83314.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 09:44:24 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:44:30 -0000 IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation Please have the Last Call continue until April 8 - so there's extra time to account for running during IETF. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 09:44:33 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8029D1A86E3; Wed, 18 Mar 2015 09:44:30 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667361A854B; Wed, 18 Mar 2015 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N2CK4ouOofY; Wed, 18 Mar 2015 09:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 137541A86E3; Wed, 18 Mar 2015 09:44:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318164424.18853.83314.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 09:44:24 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:44:30 -0000 IESG state changed to Last Call Requested::Revised I-D Needed from AD Evaluation Please have the Last Call continue until April 8 - so there's extra time to account for running during IETF. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 09:50:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B0E1A8876; Wed, 18 Mar 2015 09:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZD1LddTlIF8; Wed, 18 Mar 2015 09:50:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEB91A8702; Wed, 18 Mar 2015 09:50:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150318165008.444.68590.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 09:50:08 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:50:10 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'North-Bound Distribution of Link-State and TE Information using BGP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1864/ From nobody Wed Mar 18 09:50:27 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBF1A88C9; Wed, 18 Mar 2015 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7imm58Nsbpr; Wed, 18 Mar 2015 09:50:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F351A8840; Wed, 18 Mar 2015 09:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318165009.444.8919.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 09:50:09 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:50:21 -0000 Last call has been made for draft-ietf-idr-ls-distribution and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 09:50:29 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C37101A88D1; Wed, 18 Mar 2015 09:50:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FBF1A88C9; Wed, 18 Mar 2015 09:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7imm58Nsbpr; Wed, 18 Mar 2015 09:50:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F351A8840; Wed, 18 Mar 2015 09:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318165009.444.8919.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 09:50:09 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:50:21 -0000 Last call has been made for draft-ietf-idr-ls-distribution and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 11:40:58 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED81A900A; Wed, 18 Mar 2015 11:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrsW4aPdDBNr; Wed, 18 Mar 2015 11:40:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868CB1A8842; Wed, 18 Mar 2015 11:40:54 -0700 (PDT) Received: from [172.29.32.126] (66.129.241.14) by BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139) with Microsoft SMTP Server (TLS) id 15.1.112.19; Wed, 18 Mar 2015 18:40:34 +0000 Message-ID: <5509C69D.3040409@juniper.net> Date: Wed, 18 Mar 2015 14:40:29 -0400 From: Eric C Rosen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Xuxiaohu , idr wg , "bier@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830FD5F@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830FD5F@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BN3PR09CA0038.namprd09.prod.outlook.com (25.160.111.176) To BY1PR0501MB1093.namprd05.prod.outlook.com (25.160.103.139) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1093; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(86362001)(46102003)(33656002)(42186005)(23746002)(230783001)(59896002)(122386002)(92566002)(80316001)(83506001)(77096005)(2950100001)(77156002)(62966003)(87976001)(65806001)(40100003)(50986999)(66066001)(65956001)(36756003)(2501003)(50466002)(65816999)(76176999)(47776003)(54356999)(64126003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1093; H:[172.29.32.126]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0501MB1093; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1093; X-Forefront-PRVS: 051900244E X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2015 18:40:34.3980 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1093 Archived-At: Subject: Re: [Idr] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:40:56 -0000 Just a couple of comments. Consider carefully whether you really want the TLVs and sub-TLVs to have single-octet type fields. A two-octet type field could have a FCFS allocation policy for at least part of its range, which makes it a lot easier to avoid codepoint clash (and a lot easier to deploy stuff without getting involved in IETF politics). The draft never quite says that if the BIER path attribute is present, the NLRI is treated by BIER as a "BFR-prefix". Unless I'm misunderstanding something, I think this needs to be said explicitly. It might be worth mentioning that, when creating a BIER attribute, a BFR needs to include one BIER TLV for every pair that it supports. I find the following text from section 4 to be somewhat confusing: Furthermore, the routable address contained in the NLRI is RECOMMENDED to be the one used for establishing BGP sessions. In other words, the routable address is usually used as the BGP nexthop address of BGP updates advertised by that BGP speaker. The text following "in other words" doesn't really seem to be a paraphrase of the previous sentence; I'm not sure what you're really trying to say here. I suspect that what you're trying to say is something like: "When BGP distributes a route whose NLRI is a BFR-prefix, the next hop SHOULD also be a BFR-prefix." Of course, that leads to the question of what to do when the next hop is not a BFR-prefix. I don't think there's a clear answer in the draft. There is some text in section 6 suggesting that one could tunnel downstream to the next BIER-capable router on the path, but there's no text saying how you would figure out who that is. I wonder (warning, half-baked idea approaching) if the BIER TLV needs something like a "BIER next hop" sub-TLV. This could be changed to 'self' by every BFR that redistributes the route, but would be left unchanged by non-BFRs. Then you'd always know the next BFR in the path to a given BFER. We'd also have to take into account the case where a BFR redistributing a route supports some but not all of the sub-domains mentioned in the BIER attribute. Probably the BIER next hop sub-TLV would only get changed by a given BFR if that BFR is in the sub-domain identified by the BIER TLV that contains said sub-TLV. From nobody Wed Mar 18 11:54:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8461A878E; Wed, 18 Mar 2015 11:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc0LGMawD6MD; Wed, 18 Mar 2015 11:54:27 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D6C1A8822; Wed, 18 Mar 2015 11:54:26 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,423,1422918000"; d="p7s'?scan'208"; a="1627510" Received: from ms-exchange.de-cix.net ([192.168.67.12]) by mailgw011.de-cix.net with ESMTP/TLS/AES128-SHA; 18 Mar 2015 19:54:24 +0100 Received: from MS-Exchange.de-cix.net ([fe80::250:56ff:fe9e:3eea]) by MS-Exchange.de-cix.net ([fe80::250:56ff:fe9e:3eea%10]) with mapi id 14.03.0224.002; Wed, 18 Mar 2015 19:54:24 +0100 From: Thomas King To: Thomas Mangin Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050evpWAgAPLxgA= Date: Wed, 18 Mar 2015 18:54:22 +0000 Message-ID: <6BBC5C04-0D9A-4B6C-ADC3-AC4D6A37E193@de-cix.net> References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> <55069AAF.2050801@exa-networks.co.uk> In-Reply-To: <55069AAF.2050801@exa-networks.co.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.140.93] Content-Type: multipart/signed; boundary="Apple-Mail=_0EDA3047-529E-4305-9F7F-2C716697CEB9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "idr-bounces@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 18:54:29 -0000 --Apple-Mail=_0EDA3047-529E-4305-9F7F-2C716697CEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Thomas > On 16 Mar 2015, at 09:56, Thomas Mangin = wrote: >=20 > Many networks will not use Route Servers due to this problem which did > hit quite a few operators over the years on large internet exchanges. > This is a reason why some large operators refuse to peer with smaller > ones via RS. I think this is not correct anymore: http://net.t-labs.tu-berlin.de/~prichter/imc238-richterA.pdf Nearly all customers at DE-CIX Frankfurt use the route servers. I think many things happened in the past to make sure route servers run = stable and reliable. With our proposal we are pushing hard in this = direction. Especially, for large IXPs such as DE-CIX, AMS-IX, Linx or = Netnod setting up bilateral peerings does not scale anymore (who wants = to maintain 500+ BGP sessions?). Route servers are the only solution to = keep the setup process manageable (from my point of view). Best regards, Thomas= --Apple-Mail=_0EDA3047-529E-4305-9F7F-2C716697CEB9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCCBBcw ggL/oAMCAQICCwQAAAAAATGJxjDEMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNp Z24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWdu MB4XDTExMDgwMjEwMDAwMFoXDTE5MDgwMjEwMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoT EEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0Eg LSBTSEEyNTYgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKYBOgY+TD0lJ71l 7FcN0/Nzj61Z4eB/NxJMsSxhevgtUUcwxyWYkoHDl+FoQMXe8JSYraOIN7UpZvvDa9fVVpouxlnk 1upfRTHJRpU636SlHTEE5ZnXTYWQ3pTL51oEoPL4fL4OIHHO8Xe0H7X/9nw+N8tNxCCiGKRBMCcH HXuJLeW3pFUISGaVwfc2mye8mjIw+bjIJ6gtjK66WaUW6fWY323qkkS8W9uzdCXKVpGPkZUhsmqW fGlg2msfbx3O8to8LaCk0RqlVvV+g7ZrY7xBwdWGfZKCRd5R1kt2QBYOBtZfRBV7dfPMsjI4XcQU uKyTYpccj7VTvLdaf+B+TZkCAwEAAaOB6DCB5TAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAdBgNVHQ4EFgQUP2xXRJ5Xn339aDnLufEa5Ll2UDgwRwYDVR0gBEAwPjA8BgRVHSAA MDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC1yMy5jcmwwHwYD VR0jBBgwFoAUj/BLf6guRSSuTVD6Y5qL3uLdG7wwDQYJKoZIhvcNAQELBQADggEBAEWk43dt8+mP vv8ou8ZzoNxtjS0WuP0v/qiu9VX/JBjb+7X1tiWtGc2UqaUO+Y4irbiawHdgYnAXDNW1h8pCog+u z7kVIYegYhBWyQhlrn3c2sjXK+aRVFe44Ygfdmgcrj1Y7E6g9YvaGOhwZsr1IyQYkgejewpRDb+O B+3Cr5JtwJYuar3TNXrzOZnDnZSqOkvSASOlk1m5fPCYam4MdSTCJQRtz9Apcz3zcaJmlBkQsSix LzUqfPpTjheBjLoMJzhnRpZnOZiwe6J4LDrXyZqNSB5MCUIdCxWQlrt6ed8y07KPueYXPlZh0iUt vUEdL6Et8YULkFMQqQ7aAZtxBYMwggUgMIIECKADAgECAhEA2O44+rO7W3RMNf2nPhVNvTANBgkq hkiG9w0BAQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEG A1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyMB4XDTE0MTIx NzE0MDMwNVoXDTE3MTIxNzE0MDMwNVowgaExCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxEDAO BgNVBAcTB0NvbG9nbmUxHzAdBgNVBAoTFkRFLUNJWCBNYW5hZ2VtZW50IEdtYkgxFDASBgNVBAsT C0VuZ2luZWVyaW5nMRQwEgYDVQQDEwtUaG9tYXMgS2luZzElMCMGCSqGSIb3DQEJARYWdGhvbWFz LmtpbmdAZGUtY2l4Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOP1el+NQvS5 4TU/sO77bxd2pGMFw15OZIPm4ggIanvFGMo/UqUEpq4eOSQp7qhyYr4ROr1bbTGkPNEnsXn1Ogoa 0/xt2mQhpWlO4IykBN9eo09ZSuiQEWGHnKWNUevDRQpbkugZuvla8MVCWhIuDyc3JlzA8SaCVooj aKltl5qqLYf4yln61tvu44ByaKMniTzHrUvSPeEntr9ZkN477MCL3h4tp38vyvGvzEJTPv2x/i5v S2kFxNl7oSdd3TcBsevz5ui3XxXy1isO05KrVD6JTkXbZejsPRPEa6VsgeR6Q0FP833K/+7/EiYO tHfwiIAydO9wK6/u5mUX6n9MGJsCAwEAAaOCAZQwggGQMA4GA1UdDwEB/wQEAwIFoDBNBgNVHSAE RjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j b20vcmVwb3NpdG9yeS8wIQYDVR0RBBowGIEWdGhvbWFzLmtpbmdAZGUtY2l4Lm5ldDAJBgNVHRME AjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBHBgNVHR8EQDA+MDygOqA4hjZodHRw Oi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMnNoYTJnMi5jcmwwWQYIKwYB BQUHAQEETTBLMEkGCCsGAQUFBzAChj1odHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2Vy dC9nc3BlcnNvbmFsc2lnbjJzaGEyZzIuY3J0MB0GA1UdDgQWBBRWuQrVK+3zTtZn1ORSIsFcQJX+ 2jAfBgNVHSMEGDAWgBQ/bFdEnlefff1oOcu58RrkuXZQODANBgkqhkiG9w0BAQsFAAOCAQEAoMDH FHReZqkQtBmjceWw09VArN6a8h4GXRRJ+Tmv3ia2u66bgBRBtmE1vEeIPoS4OtoJSbAG0WUIVucW N9HgTJS7Cq1BvjHOaW5H0qxIViY67Re0coWnWhFdlQlCcZHTHDhgejZUhOdON3wLxzAkzctT/ACp 3SYBBGyqGo+XEPITbeqN33kf29qAjd+4kNuyLrF71I60wPwnNOCZxgKqxl0mLlcYU1XSz49rqk1N xko/OnrEY5w6brxIBABdOWe4b/He596QBdum0xq9CdHIRabYRzsKvChrT+TVkEI9pRRl2zsoNg+h JKWTGgLZHpnnq/3Ktc0z3xUiJtUvyz67nDGCAwQwggMAAgEBMHIwXTELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWdu IDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wCQYFKw4DAhoFAKCCAWcwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMzE4MTg1NDIzWjAjBgkq hkiG9w0BCQQxFgQUBrKIzl/v92mzCXFeXLj7s/SyNr4wgYEGCSsGAQQBgjcQBDF0MHIwXTELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wgYMGCyqG SIb3DQEJEAILMXSgcjBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEz MDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyAhEA2O44 +rO7W3RMNf2nPhVNvTANBgkqhkiG9w0BAQEFAASCAQASqusyt4yzcLWAhFkMWrqBuHZXMkQmloZM ZezReQ9UvXyaGZDpx/8Rp68zzvDjsryDWJAphyHYaQ+hoYrZjEvxw2hP0TdBsK3sWJhgCN3hVcR6 2pRd74wyin478ONszvkiDX1syVobrzIhTsBnM2CFLQBkYNnBvMH5JYABj1B8GK39BZnGAFaUOsgH BwYr8LP/ZqRR8cCaYChuSeMGxaSGKeyCZA6p7ABdqTbq27F9w7INKWE4IPUzmSzaLQgvwlf4xYsD qkKSdKdFALSleLAYJSZ4m0B94z/YMAOmGFygiDfjXCA2rI1Xmwcr2Hhyaiib4Zwy//roeefZCLzs E9+MAAAAAAAA --Apple-Mail=_0EDA3047-529E-4305-9F7F-2C716697CEB9-- From nobody Wed Mar 18 12:23:08 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2631A908E; Wed, 18 Mar 2015 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50aw0TQB8cGR; Wed, 18 Mar 2015 12:23:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F63B1A888A; Wed, 18 Mar 2015 12:23:04 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-83-55097b25ce88 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E1.96.12456.52B79055; Wed, 18 Mar 2015 14:18:29 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Wed, 18 Mar 2015 15:22:59 -0400 From: Antoni Przygienda To: Eric C Rosen , Xuxiaohu , idr wg , "bier@ietf.org" Thread-Topic: [Bier] [Idr] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt Thread-Index: AQHQYascGhi2SsoSHUGB0TYElr3ql50inYKw Date: Wed, 18 Mar 2015 19:22:59 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F1827E479@eusaamb103.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830FD5F@NKGEML512-MBS.china.huawei.com> <5509C69D.3040409@juniper.net> In-Reply-To: <5509C69D.3040409@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPlK5qNWeowZmLphZLZ+xhsli34QOz xavbz5gstp5fxejA4tFy5C2rx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DKWPD0F3PBXq6K Y6dOsTcwzuboYuTkkBAwkZjTdJkNwhaTuHBvPZDNxSEkcIRRYsbGjSwQznJGiQU9R5lAqtgE LCQuf3vKDGKLCNRL/Os+xgpiCwskSLy8NoMdIp4o0bfqFZRtJLHq1nKwDSwCqhLHpy4B6+UV 8JZYN7MJzBYSKJNofwSyjJODU0BbYu+ZXWAzGYEu+n5qDdheZgFxiVtP5jNBXCogsWTPeWYI W1Ti5eN/rBC2osS+/unsEPU6Egt2f2KDsLUlli18DbVXUOLkzCcsExhFZyEZOwtJyywkLbOQ tCxgZFnFyFFanFqWm25ksIkRGC3HJNh0dzDueWl5iFGAg1GJh/fDRo5QIdbEsuLK3EOM0hws SuK8ix4cDBESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuHvblbAruaeq9gq/Vnm0/4P4fy7D Ve8WH3p33bPYaXITq8+fC2uPbVArWb7f4VRP7WTuqOyzuzr27S32z3RbOkeDoaN01r+IhVL9 vmV3jnKUOPS+7igxv90eeeS/yUzZKzd6dn6WX5of7VCQOuHa1+PXdItCvL+YfQmbN/kWY9z2 063Ge69q1iuxFGckGmoxFxUnAgDqjF0RdwIAAA== Archived-At: Subject: Re: [Idr] [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:23:06 -0000 >=20 > The draft never quite says that if the BIER path attribute is present, th= e NLRI is > treated by BIER as a "BFR-prefix". Unless I'm misunderstanding something= , I > think this needs to be said explicitly. [Tony saiz:] I made the same comment and a larger discussion is whether o= nly a single NLRI (BFR-prefix) is allowed in such an update (i.e. update ca= rrying BIER attributes).=20 >=20 > It might be worth mentioning that, when creating a BIER attribute, a BFR = needs > to include one BIER TLV for every pair that it supports= . [Tony saiz:] I made the same comment. Alternative is to have a single BIER= attribute per sub-domain in an update to allow e.g. a loopback per sub-dom= ain (which does not sound right to me since the architecture seems to imply= a 1-1 assocation between a BFR prefix and a BIER domain). =20 > I wonder (warning, half-baked idea approaching) if the BIER TLV needs > something like a "BIER next hop" sub-TLV. This could be changed to 'self= ' by > every BFR that redistributes the route, but would be left unchanged by no= n- > BFRs. Then you'd always know the next BFR in the path to a given BFER. [Tony saiz:] hmm, yes, given the tunneling in the architecture this is so= mething I have to think through as well.=20 --- tony=20 From nobody Wed Mar 18 12:36:31 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D178C1A90C9; Wed, 18 Mar 2015 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gol7TKi3vCLJ; Wed, 18 Mar 2015 12:36:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C24A61A90C5; Wed, 18 Mar 2015 12:36:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318193626.17354.24097.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 12:36:26 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:36:29 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation Awaiting the additional implementation report to be added. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ From nobody Wed Mar 18 12:36:32 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution-impl.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EDD2F1A90CB; Wed, 18 Mar 2015 12:36:28 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution-impl.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution-impl.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D178C1A90C9; Wed, 18 Mar 2015 12:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gol7TKi3vCLJ; Wed, 18 Mar 2015 12:36:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C24A61A90C5; Wed, 18 Mar 2015 12:36:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318193626.17354.24097.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 12:36:26 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:36:29 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation Awaiting the additional implementation report to be added. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution-impl/ From nobody Wed Mar 18 12:39:49 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51151A90C5; Wed, 18 Mar 2015 12:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utzq14-k3u1T; Wed, 18 Mar 2015 12:39:46 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41ED1A90CD; Wed, 18 Mar 2015 12:39:45 -0700 (PDT) Received: from DBXPR03MB589.eurprd03.prod.outlook.com (10.141.233.11) by DBXPR03MB462.eurprd03.prod.outlook.com (10.141.11.145) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 18 Mar 2015 19:37:52 +0000 Received: from DBXPR03MB589.eurprd03.prod.outlook.com (10.141.233.11) by DBXPR03MB589.eurprd03.prod.outlook.com (10.141.233.11) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 18 Mar 2015 19:37:51 +0000 Received: from DBXPR03MB589.eurprd03.prod.outlook.com ([10.141.233.11]) by DBXPR03MB589.eurprd03.prod.outlook.com ([10.141.233.11]) with mapi id 15.01.0118.021; Wed, 18 Mar 2015 19:37:51 +0000 From: "Neil J. McRae" To: Thomas King Thread-Topic: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) Thread-Index: AQHQX2KQloKaLrJPrEOg21NQaaXf050ez1mAgAPLxgCAAAwmDQ== Date: Wed, 18 Mar 2015 19:37:51 +0000 Message-ID: <6932E9FA-3658-4198-8614-DD952B0FC7FB@domino.org> References: <7BDA4F61-AF6C-4B56-AFC8-D5CC2B9E7A96@cisco.com> <55069AAF.2050801@exa-networks.co.uk>, <6BBC5C04-0D9A-4B6C-ADC3-AC4D6A37E193@de-cix.net> In-Reply-To: <6BBC5C04-0D9A-4B6C-ADC3-AC4D6A37E193@de-cix.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.174.153.79] authentication-results: de-cix.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB589; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB462; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(243025005)(5423002)(51704005)(24454002)(36756003)(106116001)(110136001)(15975445007)(62966003)(77156002)(102836002)(40100003)(2656002)(77096005)(86362001)(87936001)(83716003)(82746002)(54356999)(50986999)(76176999)(561944003)(230783001)(122556002)(2950100001)(46102003)(33656002)(92566002)(19580405001)(66066001)(19580395003)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR03MB589; H:DBXPR03MB589.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DBXPR03MB589; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB589; x-forefront-prvs: 051900244E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2015 19:37:51.4154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 398f3eb4-3394-48e7-885c-de1ab2a9cf2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB589 X-OriginatorOrg: domino.org Archived-At: Cc: "idr@ietf.org" , "idr-bounces@ietf.org" , David Freedman Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:39:48 -0000 > On 18 Mar 2015, at 18:54, Thomas King wrote: >=20 > Hi Thomas >=20 >> On 16 Mar 2015, at 09:56, Thomas Mangin wrote: >>=20 >> Many networks will not use Route Servers due to this problem which did >> hit quite a few operators over the years on large internet exchanges. >> This is a reason why some large operators refuse to peer with smaller >> ones via RS. >=20 > I think this is not correct anymore: > http://net.t-labs.tu-berlin.de/~prichter/imc238-richterA.pdf >=20 > Nearly all customers at DE-CIX Frankfurt use the route servers. >=20 > I think many things happened in the past to make sure route servers run s= table and reliable. With our proposal we are pushing hard in this direction= . Especially, for large IXPs such as DE-CIX, AMS-IX, Linx or Netnod setting= up bilateral peerings does not scale anymore (who wants to maintain 500+ B= GP sessions?). Route servers are the only solution to keep the setup proces= s manageable (from my point of view). >=20 Thomas K - sorry but it is simple to manage, scales perfectly well and much= more preferable. (And probably off topic here)=20 Regards, Neil=20 > Best regards, > Thomas > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 18 12:40:52 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B071A90C6; Wed, 18 Mar 2015 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGUOLneNdnCx; Wed, 18 Mar 2015 12:40:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F241A90CB; Wed, 18 Mar 2015 12:40:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150318194048.32558.12168.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 12:40:48 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] REVISED Last Call: (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:40:50 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'North-Bound Distribution of Link-State and TE Information using BGP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1864/ From nobody Wed Mar 18 12:41:02 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89111A90CB; Wed, 18 Mar 2015 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhYqygkDe-tL; Wed, 18 Mar 2015 12:40:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8491A90D9; Wed, 18 Mar 2015 12:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318194049.32558.56246.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 12:40:49 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:40:53 -0000 Last call has been made for draft-ietf-idr-ls-distribution and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 12:41:03 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-ls-distribution.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0FE461A90D5; Wed, 18 Mar 2015 12:40:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-ls-distribution.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89111A90CB; Wed, 18 Mar 2015 12:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhYqygkDe-tL; Wed, 18 Mar 2015 12:40:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8491A90D9; Wed, 18 Mar 2015 12:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318194049.32558.56246.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 12:40:49 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 19:40:53 -0000 Last call has been made for draft-ietf-idr-ls-distribution and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ From nobody Wed Mar 18 13:15:01 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322241A00FA; Wed, 18 Mar 2015 13:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUyVLBR3IP5Z; Wed, 18 Mar 2015 13:14:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B73C1A889B; Wed, 18 Mar 2015 13:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318201458.9810.2262.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:14:58 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:15:00 -0000 IESG state changed to Last Call Requested from AD Evaluation To end April 8 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ From nobody Wed Mar 18 13:15:02 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4F36B1A889B; Wed, 18 Mar 2015 13:15:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322241A00FA; Wed, 18 Mar 2015 13:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUyVLBR3IP5Z; Wed, 18 Mar 2015 13:14:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B73C1A889B; Wed, 18 Mar 2015 13:14:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318201458.9810.2262.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:14:58 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:15:00 -0000 IESG state changed to Last Call Requested from AD Evaluation To end April 8 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ From nobody Wed Mar 18 13:17:55 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444B51A1B67 for ; Wed, 18 Mar 2015 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VAaBLMISX0B for ; Wed, 18 Mar 2015 13:17:49 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A50E1A00FA for ; Wed, 18 Mar 2015 13:17:49 -0700 (PDT) Received: by oiag65 with SMTP id g65so46730149oia.2 for ; Wed, 18 Mar 2015 13:17:47 -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=p6Rkhavo9aAmDyoUK5ZwOh03KVlh3wt2K6PXjk3uV+E=; b=EsSkFbI6DdOg3jYG1YJ8nE6S+Bf20rLngm+r2wgeo7TYRIm0PDoXjRos+14/Pvv5lP 3gcPbItyrOS7t6eb8XgiPb9NNniudxPtUbwcJSlTU2S6xdpBOCeuTFIeH1j5KI5+JBI6 qWdTAbwWyR7PsD/p6NKQrbve0k3rc9IIaLfL5K8XR6eJJog8T5TM4yZYMYfv2qPUT/V2 tG2++fkDDpitwhHXF+xJso7ODpT2GbRyT51VDRbFiI02GHIEx6IOyXwVEy8m6TP5ScD8 emnYrkzP2QmCnOdARiKNyrxWuLMsY6i7iUNjX545nrXBRinCGH5syVbA3h8wpdDEqUpt G7PA== MIME-Version: 1.0 X-Received: by 10.202.97.130 with SMTP id v124mr56088453oib.34.1426709867559; Wed, 18 Mar 2015 13:17:47 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Wed, 18 Mar 2015 13:17:47 -0700 (PDT) Date: Wed, 18 Mar 2015 16:17:47 -0400 Message-ID: From: Alia Atlas To: "idr@ietf. org" , draft-ietf-idr-flowspec-redirect-rt-bis@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113d5966da7fe8051195c69d Archived-At: Subject: [Idr] AD review of draft-ietf-idr-flowspec-redirect-rt-bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:17:53 -0000 --001a113d5966da7fe8051195c69d Content-Type: text/plain; charset=UTF-8 I have done my customary review of draft-ietf-idr-flowspec-redirect-rt-bis-03 on receiving a publication request. I do not have any specific concerns and am requesting an IETF Last Call. Thanks for the good work, Alia --001a113d5966da7fe8051195c69d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have done my customary review of=C2=A0draft-ietf-idr-flo= wspec-redirect-rt-bis-03
on receiving a publication request.=C2=A0 I do= not have any specific concerns and
am requesting an IETF Last Ca= ll.

Thanks for the good work,
Alia
=
--001a113d5966da7fe8051195c69d-- From nobody Wed Mar 18 13:33:34 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7281A88B8; Wed, 18 Mar 2015 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEM98H6JG26W; Wed, 18 Mar 2015 13:33:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CC1A1DE1; Wed, 18 Mar 2015 13:33:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150318203322.17138.91427.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:33:22 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] Last Call: (Clarification of the Flowspec Redirect Extended Community) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:33:26 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Clarification of the Flowspec Redirect Extended Community' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-04-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document clarifies the formatting of the the BGP Flowspec Redirect Extended Community, originally documented in RFC 5575 (Dissemination of Flow Specification Rules). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Mar 18 13:33:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8A1A88C6; Wed, 18 Mar 2015 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYIKEJdeKFfd; Wed, 18 Mar 2015 13:33:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9130B1A88AB; Wed, 18 Mar 2015 13:33:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318203322.17138.22111.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:33:22 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:33:29 -0000 Last call has been made for draft-ietf-idr-flowspec-redirect-rt-bis and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ From nobody Wed Mar 18 13:33:37 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0BC901A88D0; Wed, 18 Mar 2015 13:33:28 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8A1A88C6; Wed, 18 Mar 2015 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYIKEJdeKFfd; Wed, 18 Mar 2015 13:33:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9130B1A88AB; Wed, 18 Mar 2015 13:33:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150318203322.17138.22111.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:33:22 -0700 From: IETF Secretariat Archived-At: Subject: [Idr] ID Tracker State Update Notice: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:33:29 -0000 Last call has been made for draft-ietf-idr-flowspec-redirect-rt-bis and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-rt-bis/ From nobody Thu Mar 19 23:57:34 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D51B2C52; Thu, 19 Mar 2015 23:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf3u4KEcMcui; Thu, 19 Mar 2015 23:57:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAF81B2C53; Thu, 19 Mar 2015 23:57:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQM11258; Fri, 20 Mar 2015 06:57:27 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Mar 2015 06:57:26 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 20 Mar 2015 14:56:05 +0800 From: Xuxiaohu To: Antoni Przygienda , Eric C Rosen , idr wg , "bier@ietf.org" Thread-Topic: [Bier] [Idr] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt Thread-Index: AQHQYasKItkY8wf3SEK3xghRwHT+hp0iGHCAgALZbFA= Date: Fri, 20 Mar 2015 06:56:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0831D70A@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830FD5F@NKGEML512-MBS.china.huawei.com> <5509C69D.3040409@juniper.net> <2E4BB27CAB87BF43B4207C0E55860F1827E479@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1827E479@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.142] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] [Bier] FW: New Version Notification for draft-xu-idr-bier-extensions-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 06:57:31 -0000 SGkgRXJpYyBhbmQgVG9ueSwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBQbGVh c2Ugc2VlIG15IHJlc3BvbnNlIGlubGluZS4NCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8 /sjLOiBBbnRvbmkgUHJ6eWdpZW5kYSBbbWFpbHRvOmFudG9uaS5wcnp5Z2llbmRhQGVyaWNzc29u LmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTXE6jPUwjE5yNUgMzoyMw0KPiDK1bz+yMs6IEVyaWMgQyBS b3NlbjsgWHV4aWFvaHU7IGlkciB3ZzsgYmllckBpZXRmLm9yZw0KPiDW98ziOiBSRTogW0JpZXJd IFtJZHJdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRyYWZ0LXh1LWlkci1i aWVyLWV4dGVuc2lvbnMtMDEudHh0DQo+IA0KPiA+DQo+ID4gVGhlIGRyYWZ0IG5ldmVyIHF1aXRl IHNheXMgdGhhdCBpZiB0aGUgQklFUiBwYXRoIGF0dHJpYnV0ZSBpcyBwcmVzZW50LA0KPiA+IHRo ZSBOTFJJIGlzIHRyZWF0ZWQgYnkgQklFUiBhcyBhICJCRlItcHJlZml4Ii4gIFVubGVzcyBJJ20N Cj4gPiBtaXN1bmRlcnN0YW5kaW5nIHNvbWV0aGluZywgSSB0aGluayB0aGlzIG5lZWRzIHRvIGJl IHNhaWQgZXhwbGljaXRseS4NCj4gDQo+ICBbVG9ueSBzYWl6Ol0gIEkgbWFkZSB0aGUgc2FtZSBj b21tZW50IGFuZCBhIGxhcmdlciBkaXNjdXNzaW9uIGlzIHdoZXRoZXINCj4gb25seSBhIHNpbmds ZSBOTFJJIChCRlItcHJlZml4KSBpcyBhbGxvd2VkIGluIHN1Y2ggYW4gdXBkYXRlIChpLmUuIHVw ZGF0ZSBjYXJyeWluZw0KPiBCSUVSIGF0dHJpYnV0ZXMpLg0KDQpXaWxsIG1ha2UgaXQgY2xlYXIg aW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KPiA+IEl0IG1pZ2h0IGJlIHdvcnRoIG1lbnRpb25pbmcg dGhhdCwgd2hlbiBjcmVhdGluZyBhIEJJRVIgYXR0cmlidXRlLCBhDQo+ID4gQkZSIG5lZWRzIHRv IGluY2x1ZGUgb25lIEJJRVIgVExWIGZvciBldmVyeSA8c3ViLWRvbWFpbiwgYnNsPiBwYWlyIHRo YXQgaXQNCj4gc3VwcG9ydHMuDQo+IA0KPiAgW1Rvbnkgc2FpejpdIEkgbWFkZSB0aGUgc2FtZSBj b21tZW50LiBBbHRlcm5hdGl2ZSBpcyB0byBoYXZlIGEgc2luZ2xlIEJJRVINCj4gYXR0cmlidXRl IHBlciBzdWItZG9tYWluIGluIGFuIHVwZGF0ZSB0byBhbGxvdyBlLmcuIGEgbG9vcGJhY2sgcGVy IHN1Yi1kb21haW4NCj4gKHdoaWNoIGRvZXMgbm90IHNvdW5kIHJpZ2h0IHRvIG1lIHNpbmNlIHRo ZSBhcmNoaXRlY3R1cmUgc2VlbXMgdG8gaW1wbHkgIGEgMS0xDQo+IGFzc29jYXRpb24gYmV0d2Vl biBhIEJGUiBwcmVmaXggYW5kIGEgQklFUiBkb21haW4pLg0KDQpXaWxsIG1ha2UgaXQgY2xlYXIg aW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KPiA+IEkgd29uZGVyICh3YXJuaW5nLCBoYWxmLWJha2Vk IGlkZWEgYXBwcm9hY2hpbmcpIGlmIHRoZSBCSUVSIFRMViBuZWVkcw0KPiA+IHNvbWV0aGluZyBs aWtlIGEgIkJJRVIgbmV4dCBob3AiIHN1Yi1UTFYuICBUaGlzIGNvdWxkIGJlIGNoYW5nZWQgdG8N Cj4gPiAnc2VsZicgYnkgZXZlcnkgQkZSIHRoYXQgcmVkaXN0cmlidXRlcyB0aGUgcm91dGUsIGJ1 dCB3b3VsZCBiZSBsZWZ0DQo+ID4gdW5jaGFuZ2VkIGJ5IG5vbi0gQkZScy4gVGhlbiB5b3UnZCBh bHdheXMga25vdyB0aGUgbmV4dCBCRlIgaW4gdGhlIHBhdGggdG8NCj4gYSBnaXZlbiBCRkVSLg0K PiANCj4gIFtUb255IHNhaXo6XSAgaG1tLCB5ZXMsIGdpdmVuIHRoZSB0dW5uZWxpbmcgaW4gdGhl IGFyY2hpdGVjdHVyZSB0aGlzIGlzDQo+IHNvbWV0aGluZyBJIGhhdmUgdG8gdGhpbmsgdGhyb3Vn aCBhcyB3ZWxsLg0KDQoNCldpbGwgY29uc2lkZXIgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi4gQW5v dGhlciB3YXkgaXMgdG8gZGlyZWN0bHkgdHVubmVsIHRoZSBCSUVSIHBhY2tldCB0byB0aGUgQkZF Ui4gVGhpcyB3YXkgaGFzIGJlZW4gbWVudGlvbmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb246DQoN CiAgIFNpbmNlIHRoZSBCSUVSIGF0dHJpYnV0ZSBpcyBhbiBvcHRpb25hbCwgdHJhbnNpdGl2ZSBC R1AgcGF0aA0KICAgYXR0cmlidXRlLCBhIG5vbi1CRlIgQkdQIHNwZWFrZXJzIGNvdWxkIHN0aWxs IGFkdmVydGlzZSB0aGUgcmVjZWl2ZWQNCiAgIHJvdXRlIHdpdGggYSBCSUVSIGF0dHJpYnV0ZS4g IFRoaXMgaXMgZGVzaXJhYmxlIGluIHRoZSBpbmNyZW1lbnRhbA0KICAgZGVwbG95bWVudCBzY2Vu YXJpbyB3aGVyZSBhIEJHUCBzcGVha2VyIGNvdWxkIHR1bm5lbCBhIEJJRVIgcGFja2V0IG9yDQog ICB0aGUgcGF5bG9hZCBvZiBhIEJJRVIgcGFja2V0IHRvIGEgQkZFUiBkaXJlY3RseSBpZiB0aGUg QkdQIG5leHQtaG9wDQogICBvZiB0aGUgcm91dGUgZm9yIHRoYXQgQkZFUiBpcyBhIG5vbi1CRlIu DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KIA0KPiAtLS0gdG9ueQ0KDQo= From nobody Sun Mar 22 12:09:19 2015 Return-Path: X-Original-To: expand-draft-ietf-idr-flowspec-redirect-rt-bis.all@virtual.ietf.org Delivered-To: idr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2741A1A8A68; Fri, 20 Mar 2015 21:44:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-idr-flowspec-redirect-rt-bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092C01A8A67 for ; Fri, 20 Mar 2015 21:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJDob8fXlYC3 for ; Fri, 20 Mar 2015 21:44:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1166A1A8A66 for ; Fri, 20 Mar 2015 21:44:27 -0700 (PDT) Received: from mail-pd0-x229.google.com ([2607:f8b0:400e:c02::229]:32819) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YZBGr-0000eb-VC for draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org; Fri, 20 Mar 2015 21:44:26 -0700 Received: by pdnc3 with SMTP id c3so127742413pdn.0 for ; Fri, 20 Mar 2015 21:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=gsRaIFNK4Ffcsr0owHZZh00iqQ70/Fxk6O4nmqF/PJI=; b=JkZRgRO95p+Y5hG8LIlsWhcU6ED0EVqXgdzhsn2WZ2Ihk8EQFQgV52jCOXJ8HxuSF0 CumBS3uDHrtpoPiALajPIKFWTAjZOzzAyQ9FVocbGftCk9UCNQ6Q4lv6+UifAd1mOH2D v5BWW4vGhxln4buJUyprh4d86W5ycNN1dP0x8Uzyc2IZia+DC9U0BsMLN1PVTKEQbgcR rv9+XovX+Q2AJKN6sor2Gkokr8UuQkK7T53aCDP8ByYfZKoOANKPDdspjvJcoB5pewJN +0xDCBQhvQhUbDqDG/4he9x7+nXvq7STSllo+mx044iUZ1IMga3iYqLxcce8eT/5COBh a9JA== X-Received: by 10.68.251.226 with SMTP id zn2mr2211359pbc.100.1426913060230; Fri, 20 Mar 2015 21:44:20 -0700 (PDT) Received: from [172.19.59.4] ([131.203.112.133]) by mx.google.com with ESMTPSA id s17sm10186554pdn.87.2015.03.20.21.44.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 21:44:19 -0700 (PDT) Message-ID: <550CF725.1060501@gmail.com> Date: Sat, 21 Mar 2015 17:44:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org, General Area Review Team Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2607:f8b0:400e:c02::229 X-SA-Exim-Rcpt-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@tools.ietf.org X-SA-Exim-Mail-From: brian.e.carpenter@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-idr-flowspec-redirect-rt-bis.all@ietf.org Resent-Message-Id: <20150321044430.1166A1A8A66@ietfa.amsl.com> Resent-Date: Fri, 20 Mar 2015 21:44:27 -0700 (PDT) Resent-From: brian.e.carpenter@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 12:09:18 -0700 Subject: [Idr] Gen-ART Last Call review of draft-ietf-idr-flowspec-redirect-rt-bis-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 04:44:31 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-idr-flowspec-redirect-rt-bis-03.txt Reviewer: Brian Carpenter Review Date: 2015-03-21 IETF LC End Date: 2015-04-08 IESG Telechat date: Summary: Almost Ready -------- Minor Issue: ------------ In the IANA Considerations, two new registries are created (below). For these two registries, the Registration Procedures need to be defined, presumably on the same model as RFC 7153. IANA is requested to create the "Generic Transitive Experimental Use Extended Community Part 2 Sub-Types" registry. It should be seeded with the following Sub-Type: 0x08 - Flow spec redirect IPv4 format. IANA is requested to create the "Generic Transitive Experimental Use Extended Community Part 3 Sub-Types" registry. It should be seeded with the following Sub-Type: 0x08 - Flow spec redirect AS-4byte format. From nobody Mon Mar 23 09:17:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4381D1AC42D for ; Mon, 23 Mar 2015 09:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAkMmdvk4b74 for ; Mon, 23 Mar 2015 09:17:33 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B6F1AC430 for ; Mon, 23 Mar 2015 09:17:22 -0700 (PDT) Received: from lingersoll-sslvpn-nc.jnpr.net (66.129.241.11) by CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Mon, 23 Mar 2015 16:17:19 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <64793C0C-484F-4281-ACA4-0B6124FA4D7D@juniper.net> Date: Mon, 23 Mar 2015 11:17:09 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <64793C0C-484F-4281-ACA4-0B6124FA4D7D@juniper.net> To: "idr@ietf. org" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.11] X-ClientProxiedBy: BN3PR09CA0033.namprd09.prod.outlook.com (25.160.111.171) To CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB732; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(164054003)(51704005)(41574002)(62966003)(450100001)(2950100001)(40100003)(76176999)(50986999)(82746002)(87976001)(122386002)(46406003)(77156002)(19580395003)(19580405001)(77096005)(86362001)(92566002)(97756001)(83716003)(46102003)(53416004)(15975445007)(107886001)(229853001)(110136001)(42186005)(57306001)(50466002)(50226001)(33656002)(36756003)(23726002)(47776003)(66066001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB732; H:lingersoll-sslvpn-nc.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR05MB732; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB732; X-Forefront-PRVS: 05245CA661 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2015 16:17:19.0576 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB732 Archived-At: Subject: [Idr] Second call: Slides and other meeting-related things X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:17:35 -0000 Folks, We have gotten slides from several presenters. Those have been uploaded = and can be found at = https://datatracker.ietf.org/meeting/92/materials.html If you've sent your slides, please check the materials site. If you = don't see them there, please send Sue and me a reminder and accept my = apology.=20 If you haven't sent your slides, you have about four more hours until = the 24 hour deadline. Because our agenda is so full, you may really lose = your slot if you are late, although we will do our best to accommodate = everyone. I will also be sending out individual nags. Finally, we haven't had any volunteers for Jabber or notes yet. Please = consider volunteering to help. Thanks! --John =20 On Mar 16, 2015, at 1:23 PM, John G. Scudder wrote: > First, thanks to Robert for being the first person to submit his = slides. I've posted them, you can find them at = https://datatracker.ietf.org/meeting/92/materials.html >=20 > Second, this is a reminder to other presenters that you, too, can = submit your slides now. No need to wait for the 24-hour deadline. = Getting your slides in early may help since people can review them ahead = of time and be more prepared for productive discussion. >=20 > Third, as usual we would appreciate early volunteers to take notes and = monitor the Jabber room. >=20 > Thanks, >=20 > --John > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Tue Mar 24 04:29:53 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD81A1F02; Tue, 24 Mar 2015 04:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUEFAWnrAiME; Tue, 24 Mar 2015 04:29:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE51A898C; Tue, 24 Mar 2015 04:29:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324112947.8601.67824.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 04:29:47 -0700 Archived-At: Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ymbk-idr-rs-bfd-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:29:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Making Route Servers Aware of Data Link Failures at IXPs Authors : Randy Bush Jeffrey Haas John G. Scudder Arnold Nipper Thomas King Filename : draft-ymbk-idr-rs-bfd-01.txt Pages : 8 Date : 2015-03-24 Abstract: When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes the use of BFD between the two peering routers to detect a data plane failure, and then uses BGP next hop cost to signal the state of the data link to the route server(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ymbk-idr-rs-bfd/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ymbk-idr-rs-bfd-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ymbk-idr-rs-bfd-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 nobody Tue Mar 24 04:29:55 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E944C1A1F02; Tue, 24 Mar 2015 04:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TguP9V3BL7P; Tue, 24 Mar 2015 04:29:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E97311B2CBF; Tue, 24 Mar 2015 04:29:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324112947.8601.51582.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 04:29:47 -0700 Archived-At: Subject: [Idr] New Version Notification - draft-ymbk-idr-rs-bfd-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:29:51 -0000 A new version (-01) has been submitted for draft-ymbk-idr-rs-bfd: http://www.ietf.org/internet-drafts/draft-ymbk-idr-rs-bfd-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ymbk-idr-rs-bfd/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ymbk-idr-rs-bfd-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. IETF Secretariat. From nobody Tue Mar 24 04:56:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5017A1B2CCA for ; Tue, 24 Mar 2015 04:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUhFVmZ5xJGQ for ; Tue, 24 Mar 2015 04:56:05 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DF8B81A6FDB for ; Tue, 24 Mar 2015 04:56:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.141.130; From: "Susan Hares" To: "idr wg" Date: Tue, 24 Mar 2015 07:55:54 -0400 Message-ID: <00f401d06629$7b966310$72c32930$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01D06607.F4858660" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBmIsW0VoQgMva5ROO2Mw+mWTGGYw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jerduran@ciisco.com Subject: Re: [Idr] 2 Week WG Adoption call for draft-ymbk-idr-rs-bfd-00 (3/2/2015 to 3/16/2015) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:56:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F5_01D06607.F4858660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR WG: The draft-ymbk-idr-rs-bfd-00 is adopted, and the authors should submit the draft as: draft-ietf-idr-rs-bfd-00. There seems to be interest in the topic with alternate solutions. If the authors of https://tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt wish to request adoption of the draft, please send the WG chairs a request. With this type of interest, we will schedule a virtual interim (tentative 4/27/15) for a longer discussion of each draft. Sue Hares and John Scudder ------=_NextPart_000_00F5_01D06607.F4858660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR WG:

 

The = draft-ymbk-idr-rs-bfd-00 is adopted, and the authors should submit the = draft as: draft-ietf-idr-rs-bfd-00.

 

There seems to be = interest in the topic with alternate solutions.  If the authors of =   

 

https://= tools.ietf.org/id/draft-jdurand-auto-bfd-00.txt

 
wish to request =
adoption of the draft, please send the WG chairs a request.  With =
this type of interest, we will schedule a virtual interim (tentative =
4/27/15) for a longer discussion of each draft. =

 
 
Sue Hares and =
John Scudder

 

 

------=_NextPart_000_00F5_01D06607.F4858660-- From nobody Tue Mar 24 05:33:12 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDE31B2E82 for ; Tue, 24 Mar 2015 05:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kLkp_0f2Ylj for ; Tue, 24 Mar 2015 05:33:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3E31B2E7C for ; Tue, 24 Mar 2015 05:33:09 -0700 (PDT) Received: from CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) by CO2PR05MB700.namprd05.prod.outlook.com (10.141.229.22) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 12:33:08 +0000 Received: from [172.29.33.104] (66.129.241.13) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 12:33:00 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: Date: Tue, 24 Mar 2015 07:32:54 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: BY2PR02CA0022.namprd02.prod.outlook.com (10.141.216.12) To CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB729; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB700; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(6049001)(69234005)(41574002)(15975445007)(77096005)(97756001)(122386002)(23726002)(46102003)(36756003)(92566002)(50466002)(42186005)(33656002)(83716003)(450100001)(62966003)(77156002)(66066001)(47776003)(86362001)(19580395003)(107886001)(50226001)(50986999)(229853001)(82746002)(57306001)(40100003)(110136001)(87976001)(46406003)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB729; H:[172.29.33.104]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO2PR05MB729; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB729; X-Forefront-PRVS: 0525BB0ADF X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2015 12:33:00.4723 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB729 X-OriginatorOrg: juniper.net Archived-At: Subject: [Idr] slides for today, call for notes and jabber X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 12:33:11 -0000 Thanks to everyone for getting their slides in. For some reason = datatracker isn't showing them all, although all are uploaded. All of = them can be seen if you use https://www.ietf.org/proceedings/92/idr.html We've asked the Secretariat to look into the datatracker problem. FYI. Also, I don't believe we've gotten any volunteers for notes or jabber = yet. Please consider doing this, we have a full agenda and would like to = be able to start without delay. Thanks! --John= From nobody Tue Mar 24 07:10:35 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515F61A872D for ; Tue, 24 Mar 2015 07:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqj2PM3sA0mG for ; Tue, 24 Mar 2015 07:10:32 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [IPv6:2a02:c50:0:1e::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471A01A8739 for ; Tue, 24 Mar 2015 07:10:30 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,458,1422918000"; d="p7s'?scan'208"; a="1639836" Received: from ms-exchange.de-cix.net ([192.168.67.12]) by mailgw011.de-cix.net with ESMTP/TLS/AES128-SHA; 24 Mar 2015 15:10:30 +0100 Received: from MS-Exchange.de-cix.net ([fe80::250:56ff:fe9e:3eea]) by MS-Exchange.de-cix.net ([fe80::250:56ff:fe9e:3eea%10]) with mapi id 14.03.0224.002; Tue, 24 Mar 2015 15:10:04 +0100 From: Thomas King To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ymbk-idr-rs-bfd-01.txt Thread-Index: AQHQZiXfycBozjlIMkyQ9J0ZqXWq1J0rm30A Date: Tue, 24 Mar 2015 14:10:03 +0000 Message-ID: <8C2FFFD2-B118-4B96-A074-8FEE0D6692C5@de-cix.net> References: <20150324112947.8601.67824.idtracker@ietfa.amsl.com> In-Reply-To: <20150324112947.8601.67824.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.140.93] Content-Type: multipart/signed; boundary="Apple-Mail=_DA5B1A3E-7812-4E7F-B0AB-7BED60D91EBB"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] I-D Action: draft-ymbk-idr-rs-bfd-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:10:34 -0000 --Apple-Mail=_DA5B1A3E-7812-4E7F-B0AB-7BED60D91EBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi IDR group, I uploaded rev 01 which contains the following changes: - Added section "Utilizing Next Hop Unreachablility Information at = Client Routers=E2=80=9D - Added section "Recommendations for Using BFD=E2=80=9D - Minor typo and wording improvements Thanks for the valuable feedback and suggestions. Best regards, Thomas > On 24 Mar 2015, at 06:29, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing Working Group of = the IETF. >=20 > Title : Making Route Servers Aware of Data Link = Failures at IXPs > Authors : Randy Bush > Jeffrey Haas > John G. Scudder > Arnold Nipper > Thomas King > Filename : draft-ymbk-idr-rs-bfd-01.txt > Pages : 8 > Date : 2015-03-24 >=20 > Abstract: > When route servers are used, the data plane is not congruent with = the > control plane. Therefore, the peers on the Internet exchange can > lose data connectivity without the control plane being aware of it, > and packets are dropped on the floor. This document proposes the = use > of BFD between the two peering routers to detect a data plane > failure, and then uses BGP next hop cost to signal the state of the > data link to the route server(s). >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ymbk-idr-rs-bfd/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ymbk-idr-rs-bfd-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ymbk-idr-rs-bfd-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 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_DA5B1A3E-7812-4E7F-B0AB-7BED60D91EBB Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCCBBcw ggL/oAMCAQICCwQAAAAAATGJxjDEMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNp Z24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWdu MB4XDTExMDgwMjEwMDAwMFoXDTE5MDgwMjEwMDAwMFowXTELMAkGA1UEBhMCQkUxGTAXBgNVBAoT EEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0Eg LSBTSEEyNTYgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKYBOgY+TD0lJ71l 7FcN0/Nzj61Z4eB/NxJMsSxhevgtUUcwxyWYkoHDl+FoQMXe8JSYraOIN7UpZvvDa9fVVpouxlnk 1upfRTHJRpU636SlHTEE5ZnXTYWQ3pTL51oEoPL4fL4OIHHO8Xe0H7X/9nw+N8tNxCCiGKRBMCcH HXuJLeW3pFUISGaVwfc2mye8mjIw+bjIJ6gtjK66WaUW6fWY323qkkS8W9uzdCXKVpGPkZUhsmqW fGlg2msfbx3O8to8LaCk0RqlVvV+g7ZrY7xBwdWGfZKCRd5R1kt2QBYOBtZfRBV7dfPMsjI4XcQU uKyTYpccj7VTvLdaf+B+TZkCAwEAAaOB6DCB5TAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgw BgEB/wIBADAdBgNVHQ4EFgQUP2xXRJ5Xn339aDnLufEa5Ll2UDgwRwYDVR0gBEAwPjA8BgRVHSAA MDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC1yMy5jcmwwHwYD VR0jBBgwFoAUj/BLf6guRSSuTVD6Y5qL3uLdG7wwDQYJKoZIhvcNAQELBQADggEBAEWk43dt8+mP vv8ou8ZzoNxtjS0WuP0v/qiu9VX/JBjb+7X1tiWtGc2UqaUO+Y4irbiawHdgYnAXDNW1h8pCog+u z7kVIYegYhBWyQhlrn3c2sjXK+aRVFe44Ygfdmgcrj1Y7E6g9YvaGOhwZsr1IyQYkgejewpRDb+O B+3Cr5JtwJYuar3TNXrzOZnDnZSqOkvSASOlk1m5fPCYam4MdSTCJQRtz9Apcz3zcaJmlBkQsSix LzUqfPpTjheBjLoMJzhnRpZnOZiwe6J4LDrXyZqNSB5MCUIdCxWQlrt6ed8y07KPueYXPlZh0iUt vUEdL6Et8YULkFMQqQ7aAZtxBYMwggUgMIIECKADAgECAhEA2O44+rO7W3RMNf2nPhVNvTANBgkq hkiG9w0BAQsFADBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEG A1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyMB4XDTE0MTIx NzE0MDMwNVoXDTE3MTIxNzE0MDMwNVowgaExCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNOUlcxEDAO BgNVBAcTB0NvbG9nbmUxHzAdBgNVBAoTFkRFLUNJWCBNYW5hZ2VtZW50IEdtYkgxFDASBgNVBAsT C0VuZ2luZWVyaW5nMRQwEgYDVQQDEwtUaG9tYXMgS2luZzElMCMGCSqGSIb3DQEJARYWdGhvbWFz LmtpbmdAZGUtY2l4Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOP1el+NQvS5 4TU/sO77bxd2pGMFw15OZIPm4ggIanvFGMo/UqUEpq4eOSQp7qhyYr4ROr1bbTGkPNEnsXn1Ogoa 0/xt2mQhpWlO4IykBN9eo09ZSuiQEWGHnKWNUevDRQpbkugZuvla8MVCWhIuDyc3JlzA8SaCVooj aKltl5qqLYf4yln61tvu44ByaKMniTzHrUvSPeEntr9ZkN477MCL3h4tp38vyvGvzEJTPv2x/i5v S2kFxNl7oSdd3TcBsevz5ui3XxXy1isO05KrVD6JTkXbZejsPRPEa6VsgeR6Q0FP833K/+7/EiYO tHfwiIAydO9wK6/u5mUX6n9MGJsCAwEAAaOCAZQwggGQMA4GA1UdDwEB/wQEAwIFoDBNBgNVHSAE RjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j b20vcmVwb3NpdG9yeS8wIQYDVR0RBBowGIEWdGhvbWFzLmtpbmdAZGUtY2l4Lm5ldDAJBgNVHRME AjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBHBgNVHR8EQDA+MDygOqA4hjZodHRw Oi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMnNoYTJnMi5jcmwwWQYIKwYB BQUHAQEETTBLMEkGCCsGAQUFBzAChj1odHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2Vy dC9nc3BlcnNvbmFsc2lnbjJzaGEyZzIuY3J0MB0GA1UdDgQWBBRWuQrVK+3zTtZn1ORSIsFcQJX+ 2jAfBgNVHSMEGDAWgBQ/bFdEnlefff1oOcu58RrkuXZQODANBgkqhkiG9w0BAQsFAAOCAQEAoMDH FHReZqkQtBmjceWw09VArN6a8h4GXRRJ+Tmv3ia2u66bgBRBtmE1vEeIPoS4OtoJSbAG0WUIVucW N9HgTJS7Cq1BvjHOaW5H0qxIViY67Re0coWnWhFdlQlCcZHTHDhgejZUhOdON3wLxzAkzctT/ACp 3SYBBGyqGo+XEPITbeqN33kf29qAjd+4kNuyLrF71I60wPwnNOCZxgKqxl0mLlcYU1XSz49rqk1N xko/OnrEY5w6brxIBABdOWe4b/He596QBdum0xq9CdHIRabYRzsKvChrT+TVkEI9pRRl2zsoNg+h JKWTGgLZHpnnq/3Ktc0z3xUiJtUvyz67nDGCAwQwggMAAgEBMHIwXTELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24gUGVyc29uYWxTaWdu IDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wCQYFKw4DAhoFAKCCAWcwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwMzI0MTQxMDI3WjAjBgkq hkiG9w0BCQQxFgQUB4iOCQ0Rrph61XIif0SIhEuVdYcwgYEGCSsGAQQBgjcQBDF0MHIwXTELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExMzAxBgNVBAMTKkdsb2JhbFNpZ24g UGVyc29uYWxTaWduIDIgQ0EgLSBTSEEyNTYgLSBHMgIRANjuOPqzu1t0TDX9pz4VTb0wgYMGCyqG SIb3DQEJEAILMXSgcjBdMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEz MDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIFNIQTI1NiAtIEcyAhEA2O44 +rO7W3RMNf2nPhVNvTANBgkqhkiG9w0BAQEFAASCAQA6lB53bXEZ4Maiqq6oYnXN+Rnp8Ng9peGI bxUEedadz0vBzy/K8w32y9tXdYqwPFshKiUvLfxSqnEnvw0sgp7PYkO4oJgIEz9tFeaNtL1BH1A7 TSJ0iiloNQdwBIzWq7/N0GBGI92yrDNP4MNe/Ltm8vgNhug3MePaL+eqwvUw80XpRecGFTVlHSRl CZpZ5se3y08D+h+oXzq4hou3TXjS0Z/7kJXyJZ3RfUZ8tKLF6U2CRXIjP5ius8QMHX84fNKc/5sp rxA/nCgIyNFkG8W+oYCL0bQgBi3VPgW+ae5X6/xA9dFqueBxUJiDosnvu/RfYbK8mfYVZpFNQOh6 5+PxAAAAAAAA --Apple-Mail=_DA5B1A3E-7812-4E7F-B0AB-7BED60D91EBB-- From nobody Tue Mar 24 08:18:09 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF621A88B3 for ; Tue, 24 Mar 2015 08:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn068q_QMoA1 for ; Tue, 24 Mar 2015 08:18:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5E1A8893 for ; Tue, 24 Mar 2015 08:17:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.166.41; From: "Susan Hares" To: "idr wg" Date: Tue, 24 Mar 2015 11:17:52 -0400 Message-ID: <002301d06645$b2c3fe30$184bfa90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01D06624.2BB2D360" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBmRV2/zhbSgRqOQXWmB4XsYEbVgQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Meeting room is small this afternoon X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:18:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01D06624.2BB2D360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just a warning - our room for the IDR meeting this afternoon is smaller than normal. Sue and John ------=_NextPart_000_0024_01D06624.2BB2D360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a = warning – our room for the IDR meeting this afternoon is smaller = than normal.   

 

Sue and John =

------=_NextPart_000_0024_01D06624.2BB2D360-- From nobody Tue Mar 24 09:00:20 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF371B2EA0 for ; Tue, 24 Mar 2015 09:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.378 X-Spam-Level: **** X-Spam-Status: No, score=4.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MANGLED_EXTNSN=2.3, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwiekveCx5um for ; Tue, 24 Mar 2015 09:00:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6A91A8FD4 for ; Tue, 24 Mar 2015 08:59:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQQ79613; Tue, 24 Mar 2015 15:59:52 +0000 (GMT) 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, 24 Mar 2015 15:59:51 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.168]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 23:59:45 +0800 From: "Dongjie (Jimmy)" To: Pushpasis Sarkar , "idr@ietf.org" Thread-Topic: New Version Notification for draft-psarkar-idr-bgp-ls-node-admin-tag-extension-00.txt Thread-Index: AQHQSfE7MqUX1IpgaUiBRD8mn4eTjp0r8Tog Date: Tue, 24 Mar 2015 15:59:44 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92757CA9F29@nkgeml512-mbx.china.huawei.com> References: <20150216135932.15342.73832.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.246] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] =?gb2312?b?tPC4tDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk?= =?gb2312?b?cmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0ZW5z?= =?gb2312?b?aW9uLTAwLnR4dA==?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:00:16 -0000 SGkgUHVzaHBhc2lzLA0KDQpUaGFua3MgZm9yIHRoaXMgZHJhZnQuIElNTyBJdCBpcyByZWFzb25h YmxlIHRvIGV4dGVuZCBCR1AtTFMgZm9yIHRoZSBkaXN0cmlidXRpb24gb2Ygbm9kZSBhZG1pbiB0 YWdzLiBIZXJlIGFyZSBhIGZldyBjb21tZW50czoNCg0KMS4gcGFnZSAzLCBpdCBzYXlzOg0KDQoi YSBuZXcgTm9kZSBBdHRyaWJ1dGUgVExWIHRvIGJlIGNhcnJpZWQgaW4gdGhlIGNvcnJlc3BvbmRp bmcgQkdQLUxTIE5vZGUgTkxSSSBpcyBwcm9wb3NlZCIsIA0KDQogTWF5YmUgaXQgaXMgbW9yZSBh Y2N1cmF0ZSB0byBzYXkgIiB0byBiZSBjYXJyaWVkIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgQkdQ LUxTIE5vZGUgTkxSSSIsIGFzIHRoaXMgbmV3IFRMViBpcyBjYXJyaWVkIGluIHRoZSBCR1AtTFMg YXR0cmlidXRlLg0KDQoyLiBzZWN0aW9uIDMuMSBwcm9wb3NlcyB0byBwdXQgYWRtaW4gdGFncyB3 aXRoIGRpZmZlcmVudCBzY29wZXMgaW50byBzZXBhcmF0ZSBub2RlIGFkbWluIHRhZyBUTFZzLCBh bmQgdGhlIEwgYml0IGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIHNjb3BlLiBUaGlzIHdheSBhbGwg dGhlIG5vZGUgYWRtaW4gdGFncyB3aXRoIHBlci1hcmVhIHNjb3BlIHdvdWxkIGJlIHBhY2tlZCBp bnRvIHRoZSBzYW1lIFRMVi4gV2hpbGUgdGhlIEFCUnMgaW4gT1NQRiBjYW4gcGFydGljaXBhdGUg aW4gbXVsdGlwbGUgYXJlYXMsIGFuZCB0aGUgc2FtZSBub2RlIGFkbWluIHRhZyBtYXkgaGF2ZSBk aWZmZXJlbnQgbWVhbmluZ3MgaW4gdGhlc2UgYXJlYXMsIGluIHN1Y2ggY2FzZSBzb21lIG1lY2hh bmlzbSBtYXkgYmUgbmVlZGVkIHRvIHNlcGFyYXRlIHRoZSBwZXItYXJlYSBhZG1pbiB0YWdzIG9m IGRpZmZlcmVudCBhcmVhcyBpbnRvIHNlcGFyYXRlIG5vZGUgYWRtaW4gdGFnIFRMVnMuIA0KDQpC ZXN0IHJlZ2FyZHMsDQpKaWUNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IElkciBbbWFp bHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFB1c2hwYXNpcyBTYXJrYXINCreiy83Ksbzk OiAyMDE1xOoy1MIxNsjVIDg6MDMNCsrVvP7IyzogaWRyQGlldGYub3JnDQrW98ziOiBbSWRyXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMt bm9kZS1hZG1pbi10YWctZXh0ZW5zaW9uLTAwLnR4dA0KDQpIaSBFdmVyeW9uZSwNCg0KSXQgd2ls bCBiZSBncmVhdCBpZiB5b3UgY2FuIHJldmlldyB0aGlzIG5ldyBkcmFmdCBhbmQgcHJvdmlkZSB5 b3VyIGNvbW1lbnRzIGFuZCBmZWVkYmFjay4NCg0KVGhhbmtzIGZvciB5b3VyIHRpbWUgaW4gYWR2 YW5jZS4NCg0KUmVnYXJkcywNCi1QdXNocGFzaXMNCg0KT24gMi8xNi8xNSwgNzoyOSBQTSwgImlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCndyb3Rl Og0KDQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsDQo+ZHJhZnQtcHNhcmthci1pZHItYmdwLWxz LW5vZGUtYWRtaW4tdGFnLWV4dGVuc2lvbi0wMC50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFB1c2hwYXNpcyBTYXJrYXIgYW5kIHBvc3RlZCB0byB0aGUgDQo+SUVURiBy ZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMtbm9kZS1hZG1p bi10YWctZXh0ZW5zaW9uDQo+UmV2aXNpb246CTAwDQo+VGl0bGU6CQlBZHZlcnRpc2luZyBQZXIt bm9kZSBBZG1pbiBUYWdzIGluIEJHUCBMaW5rLVN0YXRlIEFkdmVydGlzZW1lbnRzDQo+RG9jdW1l bnQgZGF0ZToJMjAxNS0wMi0xNg0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFn ZXM6CQkxMQ0KPlVSTDogICAgICAgICAgICANCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMtbm9kZS1hZG1pbg0KPi10YQ0KPmctZXh0 ZW5zaW9uLTAwLnR4dA0KPlN0YXR1czogICAgICAgICANCj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YQ0KPmctZQ0K Pnh0ZW5zaW9uLw0KPkh0bWxpemVkOiAgICAgICANCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1wc2Fya2FyLWlkci1iZ3AtbHMtbm9kZS1hZG1pbi10YWctZXh0ZQ0KPm5zaQ0KPm9u LTAwDQo+DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHBy b3RvY29sIGV4dGVuc2lvbnMgdG8gY29sbGVjdCBwZXItbm9kZQ0KPiAgIGFkbWluaXN0cmF0aXZl IHRhZ3MgYWRldmVydGlzZWQgaW4gSUdQIExpbmsgU3RhdGUgYWR2ZXJ0aXNlbWVudHMgYW5kDQo+ ICAgZGlzc2VtaW5hdGUgdGhlIHNhbWUgaW4gQkdQIExpbmstU3RhdGUgYWR2ZXJ0aXNlbWVudCBw cm90b2NvbCwgdG8NCj4gICBmYWNpbGl0YXRlIGludGVyLUFTIFRFIGFwcGxpY2F0aW9ucyB0aGF0 IG1heSBuZWVkIHRoZSBzYW1lIHBlci1ub2RlDQo+ICAgYWRtaW5pc3RyYXRpdmUgdGFncyB0byBh c3NvY2lhdGUgYSBzdWJzZXQgb2YgbmV0d29yayBkZXZpY2VzIHNwYW5uaW5nDQo+ICAgYWNyb3Nz IG1vcmUgdGhhbiBvbmUgQVMgd2l0aCBhIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkuDQo+DQo+DQo+ ICAgICAgICAgICAgICAgICAgDQo+ICAgICAgICANCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj5zdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg DQo+dG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxp c3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p ZHINCg== From nobody Tue Mar 24 14:29:57 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE61A1A66 for ; Tue, 24 Mar 2015 14:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHD-gGi5PI8I for ; Tue, 24 Mar 2015 14:29:44 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CBCF1A1A82 for ; Tue, 24 Mar 2015 14:29:42 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.85) (envelope-from ) id 1YaWOF-003TFu-RQ; Tue, 24 Mar 2015 22:29:36 +0100 Date: Tue, 24 Mar 2015 22:29:35 +0100 From: David Lamparter To: bruno.decraene@orange.com, ilya.varlashkin@easynet.com, robert@raszuk.net Message-ID: <20150324212935.GG612698@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg Subject: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:29:55 -0000 Hi Bruno, Ilya, Robert, Hi idr list, the next-hop-capability draft currently seems to target using the new nexthop capability on a per-advertisement level. Considering that draft-idr-bgp-nh-cost adds a new SAFI to convey information about nexthops, it seems natural to tranposrt the capability information in that place? (That would also remove the question of what behaviour should be when you get different advertisements with the same nexthop, but with a different nexthop capability attribute.) -David From nobody Tue Mar 24 14:42:56 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616101A1AD9 for ; Tue, 24 Mar 2015 14:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im4TX8xE2G-u for ; Tue, 24 Mar 2015 14:42:53 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AFD1A0E10 for ; Tue, 24 Mar 2015 14:42:53 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so8772017iec.0 for ; Tue, 24 Mar 2015 14:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nTxpc7prktzEhVqzr3A2/WV3gBKnJFdlvf7Cq1Se0xU=; b=YaJXGwyT6yhgsf3STJ33GOQ18LLkX0zqq0vaeF3JKj3rodF7wjqwAar3IbzTqx2Pkn Vku40OtGM24t7DcAgbVWNwlLrC4NaO3z2ygUqP+FD2G4eDLHe5VwtXO+cuV+7T4qMfdA QWYjQG08ctvPMYDfWOoQnUlr928UYCO+vj1JCV6iAVH7E+mPq6qTLfMrQWk9Gkg5M+CF sUHFHnja/lFLi5edZvjOTbj/NlRgUHBLPrl5Q8rdWXfeWlako4bvOY0PA07Kpla0SXvH r9VW0wfCsi4e5bTM3V1u0emku5zXIQny+QHsKMQjZ2auJiXfgwPkALSYgI2Fxm5bRF8b hrHw== MIME-Version: 1.0 X-Received: by 10.50.29.109 with SMTP id j13mr25621032igh.2.1427233372847; Tue, 24 Mar 2015 14:42:52 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.70 with HTTP; Tue, 24 Mar 2015 14:42:52 -0700 (PDT) Received: by 10.107.137.70 with HTTP; Tue, 24 Mar 2015 14:42:52 -0700 (PDT) In-Reply-To: <20150324212935.GG612698@eidolon> References: <20150324212935.GG612698@eidolon> Date: Tue, 24 Mar 2015 22:42:52 +0100 X-Google-Sender-Auth: usAe9Ps2bFeuO7UcG3ZGWxFTfMg Message-ID: From: Robert Raszuk To: David Lamparter Content-Type: multipart/alternative; boundary=047d7bd74a3033439305120faa47 Archived-At: Cc: idr wg , ilya.varlashkin@easynet.com, Bruno Decraene Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 21:42:55 -0000 --047d7bd74a3033439305120faa47 Content-Type: text/plain; charset=UTF-8 Hello David, Yes I very much agree with you that nh safi is a much better fit for transporting bgp next hop capabilities. Many thx, R. On Mar 24, 2015 4:29 PM, "David Lamparter" wrote: > Hi Bruno, Ilya, Robert, > Hi idr list, > > > the next-hop-capability draft currently seems to target using the new > nexthop capability on a per-advertisement level. Considering that > draft-idr-bgp-nh-cost adds a new SAFI to convey information about > nexthops, it seems natural to tranposrt the capability information in > that place? > > (That would also remove the question of what behaviour should be when > you get different advertisements with the same nexthop, but with a > different nexthop capability attribute.) > > > -David > --047d7bd74a3033439305120faa47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello David,

Yes I very much agree with you that nh safi is a much better= fit for transporting bgp next hop capabilities.

Many thx,
R.

On Mar 24, 2015 4:29 PM, "David Lamparter&q= uot; <equinox@diac24.net> w= rote:
Hi Bruno, Ilya= , Robert,
Hi idr list,


the next-hop-capability draft currently seems to target using the new
nexthop capability on a per-advertisement level.=C2=A0 Considering that
draft-idr-bgp-nh-cost adds a new SAFI to convey information about
nexthops, it seems natural to tranposrt the capability information in
that place?

(That would also remove the question of what behaviour should be when
you get different advertisements with the same nexthop, but with a
different nexthop capability attribute.)


-David
--047d7bd74a3033439305120faa47-- From nobody Tue Mar 24 15:30:24 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ACA1A1B29 for ; Tue, 24 Mar 2015 15:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.044 X-Spam-Level: X-Spam-Status: No, score=-99.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, T_HTML_ATTACH=0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhTmNiaPazFO for ; Tue, 24 Mar 2015 15:30:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 577551A1A4D for ; Tue, 24 Mar 2015 15:30:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.166.41; From: "Susan Hares" To: "idr wg" Date: Tue, 24 Mar 2015 18:30:09 -0400 Message-ID: <004e01d06682$176c0080$46440180$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004F_01D06660.905BE720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBmgawUQjwxrgetQ7m5XjKiaKylxA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: dbrungard@att.com Subject: [Idr] Here's two initial minutes notes X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 22:30:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01D06660.905BE720 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0050_01D06660.905BE720" ------=_NextPart_001_0050_01D06660.905BE720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR folks: I've attached two very rough drafts from Sue Hares and Steve Ulrich. I will send a merged set of notes on Wednesday . Sue ------=_NextPart_001_0050_01D06660.905BE720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR = folks:

 

I’ve attached two very rough drafts from Sue = Hares and Steve Ulrich.  I will send a merged set of notes on = Wednesday .

 

Sue

------=_NextPart_001_0050_01D06660.905BE720-- ------=_NextPart_000_004F_01D06660.905BE720 Content-Type: text/plain; name="20150324-idr-wg-notes-steve-ulrich.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="20150324-idr-wg-notes-steve-ulrich.txt" # -*- mode: org; mode:visual-line; tab-width: 2 -*- * * 20150324 (15:18:21 - CDT) - IDR working group (scribe notes) location: IETF 92 (dallas, tx) - far east conference room scribe: steve ulrich (sulrich@juniper.net) misc. notes - crowded house - get a bigger room next time. seriously - = sell it to management. * administravia ** chair slides / note well ** chair status - misc. review of the queue and shepherds activity - revisiting targeted monthly work items. - IDR work for may 2015 - see slides * AS and Communities Discussions ** AS-Migration (presenter: Wes George) misc. overview of document - per slides *** discussion john scudder - prefers approach of not retroactively making vendor = implementations broken wes - care required on the eric rosen - suggested specifying the intended behavior a sri - standards track vs. BCP - specification of local behavior and not = a BCP chair - supposing that this is a request for candidate text. alvaro retana (cisco) - draft points to a venodr web site (cisco). = there's a need for a durable reference. scudder - upshot, there's going to be another spin of the doc wes - yes, seeking text and will consolidated and org document per = feedback. ** BGP Wide Communities - robert raaszuk document(s): - http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05 misc. overview of document - per slides ** BGP registered Wide Communities - robert raaszuk document(s): - = http://tools.ietf.org/html/draft-raszuk-registered-wide-bgp-communities-0= 0 - misc. overview of document - per slides - authors feel that the documents are ready for last call. *** discussion (both BGP wide community presos) scudder - take it to the list acee (cisco) - query re: the location for the values and reference ** BGP time stamp: Updated (presenter: Stephane Litowski) document(s): = http://datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timestamp/ - misc. document overview per slides - requesting feedback from WG *** discussion - robert raszuck - feels work is useful, proposes BGP path record = attribute to capture multiple attributes, inquiry as to receptivity of = encoding - stephane - concerns re: impacting timestamp w/attribute and/or the = weight of the implementation - Q: robin (huawei) - inquiry re: clock source for syncronization - stephane - use of internal clocking mechanism. timestamp from = internal source (NTP, etc.) - COMMENT robin (huawei) - ... inaudible ... document(s): = http://datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timestamp/ - misc. document overview - per slides - requesting feedback from WG *** discussion - robert raszuck - feels work is useful, proposes BGP path record = attribute to capture multiple attributes, inquiry as to receptivity of = encoding - stephane - concerns re: impacting timestamp w/attribute and/or the = weight of the implementation - Q: robin (huawei) - inquiry re: clock source for syncronization - stephane - use of internal clocking mechanism. timestamp from = internal source (NTP, etc.) - COMMENT robin (huawei) - ... inaudible ... ** bgp rtc-interas (presenter: Stephane Litowski) document(s): = http://datatracker.ietf.org/doc/draft-litkowski-idr-rtc-interas/ - misc. document overview - per slides - requesting WG feedback and feedback re: solution - request for WG adoption *** discussion scudder - WG adoption query to go to ML scudder (speaking as WG member) - good candidate for WG adoption tony p - is this related to the pruning of hierarchical RRs? * Flow Spec and Segment Routing ** draft-litkowski-idr-flowspec-interfaceset (presenter: Stephane = Litowski) document(s): - misc. document overview - per slides - request for *** discussion - scudder - WG adoption query to go to ML - Q: acee (cisco) - guidance re: how to group the interfaces? looking = for a pre-determined way to - stephane - looking for an ACL like interface and/or interface type ** draft-previdi-idr-bgpls-segment-routing-epe (presenter: stefano = previdi) document(s): = http://datatracker.ietf.org/doc/draft-previdi-idr-bgpls-segment-routing-e= pe/ - misc. document overview - per slides - request for WG working group adoption *** discussion - XXX ... inaudible ... comments re: securing a code point? ** Advertising Per-node Admin Tags in BGP Link-State Advertisements = (presenter: Pushpasis Sarkar) document(s):http://datatracker.ietf.org/doc/draft-psarkar-idr-bgp-ls-node= -admin-tag-extension/ - misc. document overview - per slides - request for WG working group adoption and feedback from WG *** discussion - ZZZ (huawei) - seeking example of an inter-as application - pushpasis - there have been applications where the carrier needs to be = able to signal / hint - stefane (orange) - e.g.: providing the ability to hint path ... = inaudible ... - scudder - working group adoption to be list - need to stagger adoption = of documents w/i working group * nexthop ** draft-decraene-idr-next-hop-capability-00 (presenter: bruno decraene) document(s): http://datatracker.ietf.org/doc/draft-decraene-idr-next-hop-capability/ misc. overview of document - per slides *** discussion - hgredler (juniper) - similar proposal discussing announcement of ELC = capability at the node level - discrepancy between protocols node capability - suggesting that = there be refinement of the capability announcement in - jabber question #+BEGIN_COMMENT David Lamparter [16:19:36]: (mic) this is used on each individual route? = how does this relate to draft-ietf-idr-bgp-nh-cost / would it be = possible to use in the new SAFI introduced by that? #+END_COMMENT - bruno - requested that the question be brought up on the mailing list - ZZZ (huawei) - as described EL only to be announced to BGP NH. - misc. discussion re: processing operations by the node - scudder - request to table EL discussion - ZZZ (huawei) - another draft has been proposed - query as to whether = there is a list of capabilities expressed per session or only a single = attribute. - keyur patel (cisco) - is there a need to communicate the capability or = need to strip on transit for a non-compliant node - references the = non-transitive note in the slides. * YANG Section ** OpenConfig BGP Config Model Update (presenter: Anees Shakih) document(s): http://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ companion draft in rtrwg http://datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model/ - misc. overview of document - per slides *** discussion - no discussion - time reserved after keyur patel's presentation for = discussion ** Zhdankin BGP Config Model Update (presenter: Keyur Patel) document(s): http://datatracker.ietf.org/doc/draft-zhdankin-idr-bgp-cfg/ - misc. overview of document - per slides - next revision plans - replacement of enums w/identities - use of deviations to harmonize command params across vendor = implementations - if-feature - potential for eventual merging w/OC draft - suggested assembling a design team w/OC and vendors *** discussion - no discussion - time reserved after keyur patel's presentation for = discussion * BGP Controls ** Route Leak Detection (presenter: K. Scram) document(s): - = http://tools.ietf.org/html/draft-sriram-idr-route-leak-detection-mitigati= on-00 - companion draft in grow - = http://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-= 01 - misc. doc overview - per slides *** discussion - keyur - (scribe - missed the question) - wes george - request to define intent - up/lateral references, but not = entirely clear as to the nature of the relationship. - sriram - assumption is that SP understands the nature of the peering = relationship (customer vs. peer) - wes - request to look at BCP documents and map these against the = propsed solutoin - XXX (unknown) - difference between detection and mitigation and this = is focused on detection - wes - misc. comments re: anomalous behavior relative to baseline - sriram - noted that there's also a request to make this a working = group item - scudder - since adoption request not noted within slides - please send = a note. * new concepts ** service oriented MPLS path programming (SoMPP) (presenter: Shunwan = Zhuang) document(s): draft-li-spring-mpls-path-programming-01 - document overview - per slides and draft *** discussion - ran out of time - send comments / feedback to ML ** BGP-LU for HSDN Label Distribution (presenter: Luyuan Fang) document(s):http://datatracker.ietf.org/doc/draft-fang-idr-bgplu-for-hsdn= / - overview of the draft and architecture - per slides - seeking feedback on the draft *** discussion - scudder - comments to the ML ** BGP extensions for BIER (presenter: Xiaohu Xu) document(s):https://tools.ietf.org/html/draft-xu-idr-bier-extensions-00 agenda description: BIER: Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to = maintain any multicast state - overview of the draft and architecture - per slides - seeking feedback on the draft *** discussion - no comments ------=_NextPart_000_004F_01D06660.905BE720 Content-Type: text/html; name="minutes-ietf-92-idr.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="minutes-ietf-92-idr.html" =0A= =0A= =0A= notes-ietf-92-idr=0A= =0A= =0A= =0A= 1) Agenda Bashing/document Status [5 minutes] 

AS = and Communities Discussions [30 minutes]
2) AS-Migration  [Wes = George] [10 minutes] 
[draft-ietf-idr-as-migration]
http://= ;datatracker.ietf.org/doc/draft-ietf-idr-as-migration/=
  • Discussions: 
  • Questions posed = by Wes:  
    • Should we specify = something that will cause all implementations to be out of = specification? 
    • Should we put justifications in the = document? 
    • Is this document vendor = neutral? 
  • o  John: Ido not want to specify = something that will break existing implementations.
  • o  Wes: = I already threaded the needle to try to be vendor = netural 
  • o  Eric: Put in much justification as = possible.  For vendors, it is difficult to recall why something = occurred unless it is document someplace. 
  • o  Sidram: = Did you consider standards track versus BCP.  
  • o  = Wes: It is does require adherence to to work onthis.  There is a = subsequent draft. 
  • o  John: Please send = text. 
  • o  Wes: I will spin a draft with my = changes. 
  • o  Alvaro (incoming AD):  It read me = like “go read this cisco web-site”.  My comment was to = make it general since theweb site will = change.  
  • o  Wes: How many changes = move 
  • o  John: You are another plan.  You will = contact when you need additionalhelp. 

3) BGP Wide = Communities [10 = minutes] 
draft-raszuk-wide-bgp-communities
http:/&#= x2F;tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05
draft-raszuk-registered-wide-bgp-communities
http://tools.ietf.org/html/draft-raszuk-registered= -wide-bgp-communities-00
  • Discussion: 
  • John: We will do an = adoption call to the list
  • Acee Linden: I looked at the registry = with wide communities? 
  • Robert: One draft is the encoding, = and the second draft is the use cases.  If it is not enough, please = let me know. 

4) BGP time  stamp: Updated = [Stephane Litowski]  [5 minutes]  
http:/= ;/datatracker.ietf.org/doc/draft-litkowski-idr-bgp-timesta= mp/ 
  • Discussion: 
    • Robert: I like the work in general, but as a first = reaction that I suggest the BGP path record draft to do both timestamp = and record routes. 
    • Stephane: I think we need to keep the = timestamp as light a possible. I agree that we need a generatic = container. 
    • Robin (Huawei): When you reference the time = stamp, what will you use for the clock.
    • Stephane: We can use the = timestamp from different types of clock.  
    • Robin = (Huawei): I think the synchronization the clock is = key. 
    • Stephane: We keep detailed information on the types = of synchronization. 

5) = draft-litkowski-idr-rtc-interas: Updated [Stephane Litowski] [5 = minutes]
http:/&= #x2F;datatracker.ietf.org/doc/draft-litkowski-idr-rtc-interas&#= x2F;
  • [presented at IDR in Toronto] - = rewritten for peering-type pruning and NLRI type = pruning. 
  • Discussion: 
    • STephane: Ask for WG adoption: 
    • John: = As a WG member, we should adopt this point. 
    • Tony P: Is = similar to a previous draft (____ name = missed)? 

Flow Spec and Segment Routing  [30 = minutes]
6) draft-litkowski-idr-flowspec-interfaceset [Stephane = Litkowski] [5 minutes]
ht= tp://datatracker.ietf.org/doc/draft-litkowski-idr-flo= wspec-interfaceset/
  • Discussion 
    • Stephane: adoption requested on the = list. 
    • Acee Linden: Do offer any guidance for grouping the = interfaces? 
    • Stephane: We are grouping these = flowspecification by interface = type. 

7)draft-previdi-idr-bgpls-segment-routing-e= pe [Stefano Previdi] [10 minutes] 
http://datatracker.ietf.org/doc/draft-previ= di-idr-bgpls-segment-routing-epe/
  • Discussion
    • Stefano: = This is a post merge draft. 
    • pap [Ericsson]: Please clean = up the NLRI sections,and the links to other drafts.
    • Stefano: = Ok. 
8) Advertising Per-node Admin Tags in BGP = Link-State Advertisements [Pushpasis Sarkar] [10 = minutes]  
http://datatracker.ietf.org/doc&= #x2F;draft-psarkar-idr-bgp-ls-node-admin-tag-extension/
  • Discussion: 
    • Pushpasis: Please note this draft was shownin = previous IETFs. 
    • Robin: Will this support inter-as = TE? 
    • Pushpasis: This will support inter-area TE.  I do = not have examples of this in the draft.  
    • Stephane: We = may use the same allocation of the administrative tags across = ASes.
    • John: This is another WG adoption call. These WG may be = rolling so that people can read drafts = carefully. 

NextHop [10 = minutes] 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
9) draft-decraene-idr-next-hop-capability-00 [10 = minutes]
 = http://datatracker.ietf.org/doc/draft-decraene-idr-ne= xt-hop-capability/
  •  Bruno = Decraene: This is a non-transitive BGP attribute. Capability is = add/deleted with the next-hops.  Based on RFC6790 (Entropy = label)
  • Hannes: We have been discussing similar proposal for the = IGPs.  It is only announced only if all your interfaces are = supported. In IGP it is a node capabiity, and there is not eleciton = odel. 
  • Bruno: We can go in more detail with EGP and = IGP.  
  • David Lampster (jabber): Is this used on each = route? How does this match with the other remote nexthop = draft? 
  • Bruno: It is used on each advertisement of = route.  I do know the draft.    
  • Robin: = What is the step in the BGP nexthop? 
  • Bruno: = (missed)
  • Robin: You must synchronize the entropy label and the = nexthop.
  • Bruno: Do you mean that you must synchronize for load = balancing?  If so, it must be linked to route. 
  • Robin: = We proposed another draft with a list of next-hops. You can have many = capabilities. 
  • Keyur: Do you need a text on the route = reflector to indicate if the route reflector is in the forwarding = path? 
  • Bruno: [discussion = piece] 
 
Yang Section  [10 = minutes] 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
10) OpenConfig BGP Config Model Update  = [Anees Shakih] [7 minutes] 
 http://= datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ companion draft in rtrwg 
  http:/&= #x2F;datatracker.ietf.org/doc/draft-shaikh-rtgwg-policy-model&#= x2F;
  • models: built out of the operators = configuration model. 
  • scope: configuration, multi-address = families, operational state. 
  • Format: uses new format for = state. 
  • Convergence: progression = with   
 
11) Zhdankin BGP Config Model = Update  [Keyur Patel] [3 minutes] 
http://= datatracker.ietf.org/doc/draft-zhdankin-idr-bgp-cfg/
  • discussion: 
  • Keyur: We wish to = have a design team and merge with the = operators. 

BGP Controls [10 = minutes]

12) Route Leak Detection [K. Sriram] [10 = minutes] 
http://tools.ietf.org/html/draft-sriram-i= dr-route-leak-detection-mitigation-00   
[companion= draft in grow
http://tools.ietf.org/html/draft-ietf-grow-r= oute-leak-problem-definition-01 ]

Discussion: 
  • Keyur: This is a good solution.  A provider = receives a route from a customer, and then leaks it out. Does this help = prevent part of the process. 
  • Sriram: I need to examine = this question, 
  • Wes: Your taxonomy is really helpful. You = use the word "intent", but you do not define it.  You use = the words "up" or "lateral", but you do not define = it.  It would be helpful. 
  • Sriram: Is it on a customer = link or provider link? 
  • Wes: If you do not provide more = detail on the solution.  We have community based filtering than = NO_EXPORT community. Is it better than this? You have the RFC7454.  = Please indicate if these will fix tis point. 
  • Doug: There = is a difference in prevention.  This is about detection and = mitigation. 
  • Wes: This is a good point.  This also = brings up another point that we can infer routes = the 
  • Sriram: We request WG = adoption.  
  • John: Will you send a note to the WG = chairs. 

New Concepts [30 = minutes]
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
13) Draft Name: draft-li-spring-mpls-path-programming-01 = [10 = minutes] 
         &= nbsp;     = draft-li-idr-mpls-path-programming-01
Speaker: Shunwan = Zhuang
Duration: 10 minutes
Description: The BGP extensions has = been enhanced for the MPP solutions. 
We would like to do the = presentation to collect more comments.
  • John: = Unfortunately we do not have time for questions and comments.  = Please send these to the list. 

14)  = draft-fang-idr-bgplu-for-hsdn-00 [10]  [Luyuan = Fang] 
BGP-LU for HSDN Label Distribution
http:= F;/datatracker.ietf.org/doc/draft-fang-idr-bgplu-for-hsdn&= #x2F;

This document describes the use of BGP Labeled Unicast = (BGP-LU) with
   modified BGP Route Reflector (RR) = operation for label distribution in
   the Hierarchical SDN = (HSDN)control plane for the hyper-scale Data
   Center (DC) = and cloud networks
  • John: Unfortunately, we = must have discussion on the list. 
  • Sue: yakov picked up = some of these concepts from a previously successful peer = mechanism.   

15) Xiaohu Xu [10 = minutes]
 https://= ;tools.ietf.org/html/draft-xu-idr-bier-extensions-00 <= br> BIER: Bit Index Explicit Replication (BIER) is a new multicast = forwarding
   architecture which doesn't require an = explicit tree-building protocol
   and doesn't require = intermediate routers to maintain any multicast
   = state
  • john: Please send discussions to the = list. 

   

=0A= =0A= ------=_NextPart_000_004F_01D06660.905BE720-- From nobody Wed Mar 25 08:53:10 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236E81A887F for ; Wed, 25 Mar 2015 08:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2bcTmOMWZDG for ; Wed, 25 Mar 2015 08:53:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6619B1A8896 for ; Wed, 25 Mar 2015 08:52:52 -0700 (PDT) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0301.namprd09.prod.outlook.com (25.160.96.146) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 15:52:51 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0118.022; Wed, 25 Mar 2015 15:52:51 +0000 From: "Sriram, Kotikalapudi" To: Hares Susan , John G.Scudder Thread-Topic: draft-sriram-idr-route-leak-detection-mitigation Thread-Index: AQHQZxKCSMLPtEIgmUWl3tmpEX/k6Q== Date: Wed, 25 Mar 2015 15:52:50 +0000 Message-ID: <1427298768882.31869@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.223.238] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0301; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(106116001)(229853001)(117636001)(86362001)(230783001)(46102003)(36756003)(558084003)(99286002)(66066001)(2656002)(87936001)(122556002)(92566002)(77156002)(62966003)(40100003)(2900100001)(50986999)(54356999)(102836002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0301; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR09MB0301; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0301; x-forefront-prvs: 052670E5A4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 15:52:50.8647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0301 Archived-At: Cc: "idr@ietf.org" Subject: [Idr] draft-sriram-idr-route-leak-detection-mitigation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 15:53:07 -0000 Since it was not included in my slides of the presentation yesterday in the= IDR WG meeting, we (authors) hereby formally request the chairs to place this draft in the = request queue for WG adoption calls. Thank you. Sriram / Doug From nobody Wed Mar 25 12:56:55 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DD41A893F for ; Wed, 25 Mar 2015 12:56:54 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuYsk_qNpF65 for ; Wed, 25 Mar 2015 12:56:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB411A899F for ; Wed, 25 Mar 2015 12:56:51 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id D63B73B42F7; Wed, 25 Mar 2015 20:56:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id AFEC8C804F; Wed, 25 Mar 2015 20:56:49 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 25 Mar 2015 20:56:49 +0100 From: To: David Lamparter Thread-Topic: decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost Thread-Index: AQHQZnmjSF6fofZKJU2JukfyUyESZp0tg4OQ Date: Wed, 25 Mar 2015 19:56:48 +0000 Message-ID: <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20150324212935.GG612698@eidolon> In-Reply-To: <20150324212935.GG612698@eidolon> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.25.163622 Archived-At: Cc: idr wg , "ilya.varlashkin@easynet.com" , "robert@raszuk.net" Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:56:54 -0000 Hi David, Thanks for your comments. Please see inline. > From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, March = 24, 2015 4:30 PM >=20 > Hi Bruno, Ilya, Robert, > Hi idr list, >=20 >=20 > the next-hop-capability draft currently seems to target using the new nex= thop > capability on a per-advertisement level. Considering that draft-idr-bgp-= nh- > cost adds a new SAFI to convey information about nexthops, it seems natur= al > to tranposrt the capability information in that place? That's a valid comment. 1) cost/benefit=20 Avertising the next-hop-capability on a per update basis has indeed a cost = but also a benefit. In term of cost, the simplest next-hop-capability is 5 octets. Compared to = an update in the range of 100-1000 octets, that's 5% to 0,5%. In term of benefit, this allow customizing the capability on a per update/r= outes granularity if required, which may be a useful possibility for some c= apabilities. Engineering is about trade-off. IMO, the benefit, especially long term, out= weight the fixe cost, which is small and will become smaller, in relative = term, in the future (thanks to Moore's law). 2) deployability=20 In addition, in term of deployability, a new attribute has no impact. On t= he other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires recon= figuration and reboot of all BGP sessions. This is a much higher cost for I= BGP alone. For EBGP, this is simply not an option IMO. =20 So, I agree that this is a valid option to consider, however I don't think = that it's a better one. > (That would also remove the question of what behaviour should be when you > get different advertisements with the same nexthop, but with a different > nexthop capability attribute.) For a given route/NLRI, you use the next-hop capability attached to this ro= ute. To rephrase, you do not consider next-hop capability that may have been adv= ertised in another update. I agree that this may not be crystal clear in the text, I will clarify in t= he next revision. Thanks again for your comments, Bruno >=20 >=20 > -David ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Mar 25 13:32:33 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E721A8AB0 for ; Wed, 25 Mar 2015 13:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWmXstS2JJjY for ; Wed, 25 Mar 2015 13:32:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2291A1A87C9 for ; Wed, 25 Mar 2015 13:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4632; q=dns/txt; s=iport; t=1427315551; x=1428525151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aiHnlBYhxw9eTQZOovfyiHjEJ9WGuU1nKNHCw9yTMg4=; b=frZLkz3tjAz2DOEWPESB3lNeyB/l4J+Z3UQi3JKxcV/BF7RRrsRiW/Y9 Qr2XTW4v+XzeR2FKr3sBz3IM38PHufRUPfQ3+SRV+5LCcRy7LFdDnYXfB gQ9mEdVYrF/1oI7PRiKPj48tw4s+epRZelTrmjzzM5z1Xas6hcRQfynOs I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBQDqGhNV/5RdJa1cgwZSWgTFBwqFdQKBWkwBAQEBAQF9hBQBAQEDAQEBASRHCwULAgEIFQEpBycLFBECBA4FG4gMCA3KEgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEiyGEFBEBHTMHgxeBFgEEjkKCDoYTg1yBG4MwiGyDLoNHIoNub4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,466,1422921600"; d="scan'208";a="135400455" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 25 Mar 2015 20:32:30 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2PKWTQp019462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Mar 2015 20:32:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 15:32:28 -0500 From: "Jerome Durand (jerduran)" To: "bruno.decraene@orange.com" Thread-Topic: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost Thread-Index: AQHQZzXg9spUaUUeT0y0VZhzj0BroZ0t+waA Date: Wed, 25 Mar 2015 20:32:28 +0000 Message-ID: <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.246] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:32:32 -0000 Hi Bruno, Interesting there are some similarities to what I proposed here: draft-jdurand-idr-next-hop-liveliness-00 Where I tried to describe how we could carry next-hop capability to impleme= nt a host liveliness mechanism and solve the route-server black-holing stuf= f we have been talking about lately. Having a kind of general framework for= any capability (ie. not just host liveliness) makes sense. But your proposal relies on a non transitive attribute and couldn=92t pass = the route-server so I cannot adjust my proposal to fit in yours. Anyway note that now I more or less stopped that work for the moment to foc= us on a more automated solution as there were some challenges with BGP (iss= ues described in the draft). Also it seems that it was quite heavy from a p= rocessing/memory point of view to have new attributes per route. Note we ha= d the idea to use some kind of "magic route" in order to have the attribute= transported only once. Maybe to be investigated further. This is also desc= ribed in the draft. Thanks! Jerome Le 25 mars 2015 =E0 20:56, a =E9crit : > Hi David, >=20 > Thanks for your comments. > Please see inline. >=20 >> From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, March= 24, 2015 4:30 PM >>=20 >> Hi Bruno, Ilya, Robert, >> Hi idr list, >>=20 >>=20 >> the next-hop-capability draft currently seems to target using the new ne= xthop >> capability on a per-advertisement level. Considering that draft-idr-bgp= -nh- >> cost adds a new SAFI to convey information about nexthops, it seems natu= ral >> to tranposrt the capability information in that place? >=20 > That's a valid comment. >=20 > 1) cost/benefit=20 > Avertising the next-hop-capability on a per update basis has indeed a cos= t but also a benefit. > In term of cost, the simplest next-hop-capability is 5 octets. Compared t= o an update in the range of 100-1000 octets, that's 5% to 0,5%. > In term of benefit, this allow customizing the capability on a per update= /routes granularity if required, which may be a useful possibility for some= capabilities. > Engineering is about trade-off. IMO, the benefit, especially long term, o= ut weight the fixe cost, which is small and will become smaller, in relativ= e term, in the future (thanks to Moore's law). >=20 > 2) deployability=20 > In addition, in term of deployability, a new attribute has no impact. On= the other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires rec= onfiguration and reboot of all BGP sessions. This is a much higher cost for= IBGP alone. For EBGP, this is simply not an option IMO. >=20 >=20 > So, I agree that this is a valid option to consider, however I don't thin= k that it's a better one. >=20 >> (That would also remove the question of what behaviour should be when yo= u >> get different advertisements with the same nexthop, but with a different >> nexthop capability attribute.) >=20 > For a given route/NLRI, you use the next-hop capability attached to this = route. > To rephrase, you do not consider next-hop capability that may have been a= dvertised in another update. > I agree that this may not be crystal clear in the text, I will clarify in= the next revision. >=20 > Thanks again for your comments, > Bruno >=20 >>=20 >>=20 >> -David >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Mar 25 14:04:14 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96551A8AB3 for ; Wed, 25 Mar 2015 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEAqzKtf9JRx for ; Wed, 25 Mar 2015 14:04:09 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a02:238:f02a:8e2f:1::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66021A1B34 for ; Wed, 25 Mar 2015 14:04:09 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.85) (envelope-from ) id 1YasT6-004A33-Jv; Wed, 25 Mar 2015 22:04:05 +0100 Date: Wed, 25 Mar 2015 22:04:04 +0100 From: David Lamparter To: bruno.decraene@orange.com Message-ID: <20150325210404.GL612698@eidolon> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: idr wg , "ilya.varlashkin@easynet.com" , "robert@raszuk.net" Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:04:12 -0000 On Wed, Mar 25, 2015 at 07:56:48PM +0000, bruno.decraene@orange.com wrote: > > From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, March 24, 2015 4:30 PM > > the next-hop-capability draft currently seems to target using the new nexthop > > capability on a per-advertisement level. Considering that draft-idr-bgp-nh- > > cost adds a new SAFI to convey information about nexthops, it seems natural > > to tranposrt the capability information in that place? > > That's a valid comment. > > 1) cost/benefit > Avertising the next-hop-capability on a per update basis has indeed a cost but also a benefit. > In term of cost, the simplest next-hop-capability is 5 octets. Compared to an update in the range of 100-1000 octets, that's 5% to 0,5%. > In term of benefit, this allow customizing the capability on a per update/routes granularity if required, which may be a useful possibility for some capabilities. Sure, the attribute is smaller. But how many neighbors are there? How many routes are there? What's the semantic / complexity impact of tying this to update processing? I assume the attribute is sent only once, on a randomly picked update that has the "right" nexthop - what happens if that route is withdrawn? What if the last route with nexthop X gets withdrawn? > Engineering is about trade-off. IMO, the benefit, especially long term, out weight the fixe cost, which is small and will become smaller, in relative term, in the future (thanks to Moore's law). > > 2) deployability > In addition, in term of deployability, a new attribute has no impact. On the other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires reconfiguration and reboot of all BGP sessions. This is a much higher cost for IBGP alone. For EBGP, this is simply not an option IMO. I don't think we should design "around" limitations. Fix the limitation? > So, I agree that this is a valid option to consider, however I don't think that it's a better one. > > > (That would also remove the question of what behaviour should be when you > > get different advertisements with the same nexthop, but with a different > > nexthop capability attribute.) > > For a given route/NLRI, you use the next-hop capability attached to this route. > To rephrase, you do not consider next-hop capability that may have been advertised in another update. > I agree that this may not be crystal clear in the text, I will clarify in the next revision. Er - I'd go as far as change the name then. It's not "next-hop capability", it's "route's (including next-hop) capability". Most significantly, it won't be useful in any context that is really nexthop. The way you describe it, I can't feed information from this attribute into the nexthop table. If there's a need to signal route 'flag bit' capabilities more efficiently than adding an empty attribute - sure. But that's not "next-hop capabilities". -David From nobody Wed Mar 25 16:53:07 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1F1A87A4 for ; Wed, 25 Mar 2015 16:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-eQspQoIWie for ; Wed, 25 Mar 2015 16:53:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954C41A7017 for ; Wed, 25 Mar 2015 16:52:59 -0700 (PDT) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 23:52:58 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0118.022; Wed, 25 Mar 2015 23:52:58 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Thread-Topic: Keyur's question -- draft-sriram-idr-route-leak-detection-mitigation Thread-Index: AQHQZ1bRHfhygyu980qTB9I2Y8Bktw== Date: Wed, 25 Mar 2015 23:52:57 +0000 Message-ID: <1427327576605.11421@nist.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.223.238] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(561944003)(87936001)(2656002)(86362001)(66066001)(99286002)(102836002)(110136001)(92566002)(117636001)(2900100001)(46102003)(40100003)(2950100001)(122556002)(230783001)(106116001)(62966003)(77156002)(2501003)(76176999)(107886001)(50986999)(54356999)(2351001)(450100001)(36756003)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0302; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR09MB0302; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0302; x-forefront-prvs: 052670E5A4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 23:52:57.4166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0302 Archived-At: Subject: [Idr] Keyur's question -- draft-sriram-idr-route-leak-detection-mitigation X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:53:06 -0000 Posting this message on the list per Sue=92s request. Keyur asked a question about the proposed solution at the mike during my pr= esentation yesterday. I spoke with him afterwards to fully understand his question/suggestion. As I understand now, his question is: Is it possible to augment your route-= leak solution=20 with another solution that is based on AS path filtering?=20 This should be especially easy for ISPs that have only stub AS customers.=20 My answer: Using a combination of different approaches makes sense.=20 Also, in cases when the ISP has a complete and accurate view of its custome= r cone (CC), then also the AS path filtering can be applied for the set of ASes in the CC (by the = ISP=92s customer facing routers).=20 The draft does present a stopgap solution in the form of construction of=20 a customer-cone prefix filter list from ROAs (when RPKI is in a mature stat= e). For ISPs to have an accurate picture of their CCs is easier when closer to = the edges of the Internet,=20 but much harder for the ISPs in the middle or at the top. =20 Keyur also mentioned about the possibility of augmenting the RLP indicator = based proposal with=20 the use of AS path based Outbound Router Filter (ORF). This needs further d= iscussion. Sriram= From nobody Thu Mar 26 04:41:25 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51681B2C96 for ; Thu, 26 Mar 2015 04:41:23 -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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry6pX9wgCmgA for ; Thu, 26 Mar 2015 04:41:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDEB1B2C9A for ; Thu, 26 Mar 2015 04:41:18 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 84DED1B834A for ; Thu, 26 Mar 2015 12:41:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5963B15804E for ; Thu, 26 Mar 2015 12:41:17 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 12:41:17 +0100 From: To: "idr@ietf.org" Thread-Topic: draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcw== Date: Thu, 26 Mar 2015 11:41:16 +0000 Message-ID: <13392_1427370077_5513F05D_13392_2397_1_9E32478DFA9976438E7A22F69B08FF921662B61C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.111222 Archived-At: Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 11:41:24 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi IDR Folks, During this week, I presented the updates of the flowspec interfaceset draf= t. We are currently thinking on moving this interfaceset from extcommunity to = NLRI and we require your feedback on this. Why such change ? Consider that you may apply filters with the same "matching" but different = actions to different interface-groups. For example: Rule#1 Match : src-ip 10/8, dst-port 53 Action : rate-limit 10000 Rule#2 Match : src-ip 10/8, dst-port 53 Action : drop I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfacese= t #200. As interfaceset is an extct and not part of NLRI, ADDPATH will be required = in order to ensure propagation of both paths for the same NLRI. In case we move interfaceset as part of the NLRI, we do not have this ADDPA= TH requirement anymore, as we would have two different NLRIs Now Robert R. pointed me the need to control interAS advertisement, as inte= rfaceset have only a local significance. There's two cases : - #1 : There is an agreement between myAS and myUpstreamAS to use = some interface-set of myUpstreamAS and let myAS apply some filters on myUps= treamAS. - #2 : Such interfaceset information sharing is not authorized bet= ween both ASes, and only BGPFS rules with no interfaceset should be propaga= ted to myUpstreamAS. In #2, in case the interfaceset is extct, a BGP policy could be implemented= to deny BGP paths containing interfaceset towards myUpstreamAS. In case th= e interfaceset is part of NLRI, policy is still doable but requires some fi= ne grain NLRI matching in policy framework. To summarize : EXTCT approach : - Pros : o Permit easy filtering o Permit to use a common NLRI for multiple interfaceset if action is the = same - Cons : o But requires ADDPATH as soon as action is different for each interfaces= et NLRI approach : - Pros : o Do not require ADDPATH, may be permit an easier reading. Interfaceset i= s more a "match-like" - Cons : o Filtering requires more advanced policy matching o Requires multiple NLRIs if we want to apply the same matching/actions t= o different interfaceset These pros/cons may not be exhaustive, so please comment and raise your poi= nt regarding the approach we need to take. Thanks a lot ! [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi IDR Folks,

 

During this week, I presented the updates of the flo= wspec interfaceset draft.

We are currently thinking on moving this interfacese= t from extcommunity to NLRI and we require your feedback on this. Why such = change ?

 

Consider that you may apply filters with the same &#= 8220;matching” but different actions to different interface-groups. F= or example:

Rule#1

Match : src-ip 10/8, dst-port 53

Action : rate-limit 10000

 

Rule#2

Match : src-ip 10/8, dst-port 53

Action : drop

 

I would like to apply Rule#1 on interfaceset #100 an= d Rule#2 on interfaceset #200.

 

As interfaceset is an extct and not part of NLRI, AD= DPATH will be required in order to ensure propagation of both paths for the= same NLRI.

In case we move interfaceset as part of the NLRI, we= do not have this ADDPATH requirement anymore, as we would have two differe= nt NLRIs

 

 

 

Now Robert R. pointed me the need to control interAS= advertisement, as interfaceset have only a local significance.<= /p>

There’s two cases :

-       = ;   #1 : There is an agreement between myAS and myUpstr= eamAS to use some interface-set of myUpstreamAS and let myAS apply some fil= ters on myUpstreamAS.

-       = ;   #2 : Such interfaceset information sharing is not a= uthorized between both ASes, and only BGPFS rules with no interfaceset shou= ld be propagated to myUpstreamAS.

In #2, in case the interfaceset is extct, a BGP poli= cy could be implemented to deny BGP paths containing interfaceset towards m= yUpstreamAS. In case the interfaceset is part of NLRI, policy is still doab= le but requires some fine grain NLRI matching in policy framework.

 

To summarize :

EXTCT approach :

-       = ;   Pros :

o   Permit easy filtering

o   Permit to use a common NLRI for multiple int= erfaceset if action is the same

-       = ;   Cons :

o   But requires ADDPATH as soon as action is di= fferent for each interfaceset

 

NLRI approach :

-       = ;   Pros :

o   Do not require ADDPATH, may be permit an eas= ier reading. Interfaceset is more a “match-like”

-       = ;   Cons :

o   Filtering requires more advanced policy matc= hing

o   Requires multiple NLRIs if we want to apply = the same matching/actions to different interfaceset

 

 

These pros/cons may not be exhaustive, so please com= ment and raise your point regarding the approach we need to take.

 

Thanks a lot !

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks=

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 26 Mar 2015 11:41:15 GMT"; modification-date="Thu, 26 Mar 2015 11:41:15 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_-- From nobody Thu Mar 26 05:33:25 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC81B2CD2 for ; Thu, 26 Mar 2015 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWxl-03Mpyas for ; Thu, 26 Mar 2015 05:33:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF931B2CCD for ; Thu, 26 Mar 2015 05:33:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQS75409; Thu, 26 Mar 2015 12:33:17 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Mar 2015 12:33:15 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.209]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 20:33:08 +0800 From: Zhuangshunwan To: Robert Raszuk , idr wg Thread-Topic: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt Thread-Index: AdBZK68bN1BCIhIeS2ydNnWIffKe0AOkHFBg Date: Thu, 26 Mar 2015 12:33:07 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB98588D28952E@NKGEML512-MBS.china.huawei.com> References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> 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.86.195] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB98588D28952ENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 12:33:23 -0000 --_000_19AB2A007F56DB4E8257F949A2FB98588D28952ENKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGhhdmUgYSBjb21tZW50IHRvIHRoZSBleGFtcGxlIGluIHRoaXMgZG9j dW1lbnQ6DQoNCj45LjIuICBFeGFtcGxlIFdpZGUgQ29tbXVuaXR5IEVuY29kaW5nDQoNCj4gICAg IEFTX1BBVEggcHJlcGVuZCA0IFRJTUVTIFRPIEFTIDI0MjQsIEFTIDg4ODgsIHRvIHBlZXJzIG1h cmtlZCBhcw0KPiAgICAgQW1zdGVyZGFtICgxMDApIG9yIHRvIHBlZXJzIG1hcmtlZCBNb3Njb3cg KDEwNCksIGJ1dCBub3QgdG8gcGVlcnMNCj4gICAgIGluIE5ldyBZb3JrICgxMDEpLg0KDQpJZiAg QVMgNjQ0OTYgaGFzIGFub3RoZXIgcGVlciBBUyAoZS5nLiwgQVMgMTAwMDApLCAgQVMgMTAwMDAg bm90IGNvbnRhaW5pbmcgaW4gVGFyZ2V0IFRMViwgYW5kIGFsc28gbm90IGNvbnRhaW5pbmcgaW4g RXhjbHVkZSBUYXJnZXQgVExWLg0KV2hlbiBBUyA2NDQ5NiBzZW5kcyBhIGJncCByb3V0ZSB0byBB UyAxMDAwMCwgd2hhdCBhIHBvbGljeSBpdCB3aWxsIGJlIGV4ZWN1dGVkID8NClByZXBlbmQgb3Ig bm90IHByZXBlbmQgNCBUSU1FUyB0byBwZWVyIGFzIDEwMDAwPw0KDQpNYXliZSBJIG1pc3VuZGVy c3RhbmQgdGhlIGNhc2U/DQoNCi0tU2h1bndhbg0KDQrlj5Hku7bkuro6IElkciBbbWFpbHRvOmlk ci1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0IFJhc3p1aw0K5Y+R6YCB5pe26Ze0OiAy MDE15bm0M+aciDjml6UgNzowOQ0K5pS25Lu25Lq6OiBpZHIgd2cNCuS4u+mimDogW0lkcl0gRndk OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJhc3p1ay13aWRlLWJncC1jb21t dW5pdGllcy0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmFzenVrLXdp ZGUtYmdwLWNvbW11bml0aWVzLTA1LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBSb2JlcnQgUmFzenVrIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6ICAgICAgICAgICBkcmFmdC1yYXN6dWstd2lkZS1iZ3AtY29tbXVuaXRpZXMNClJldmlz aW9uOiAgICAgICAwNQ0KVGl0bGU6ICAgICAgICAgIFdpZGUgQkdQIENvbW11bml0aWVzIEF0dHJp YnV0ZQ0KRG9jdW1lbnQgZGF0ZTogIDIwMTUtMDMtMDYNCkdyb3VwOiAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAyMw0KVVJMOiAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJhc3p1ay13aWRlLWJncC1jb21t dW5pdGllcy0wNS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1yYXN6dWstd2lkZS1iZ3AtY29tbXVuaXRpZXMvDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVrLXdpZGUtYmdwLWNvbW11 bml0aWVzLTA1DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtcmFzenVrLXdpZGUtYmdwLWNvbW11bml0aWVzLTA1DQoNCkFic3RyYWN0Og0KICAg Um91dGUgdGFnZ2luZyBwbGF5cyBhbiBpbXBvcnRhbnQgcm9sZSBpbiBleHRlcm5hbCBCR1AgW1JG QzQyNzFdDQogICByZWxhdGlvbnMsIGluIGNvbW11bmljYXRpbmcgdmFyaW91cyByb3V0aW5nIHBv bGljaWVzIGJldHdlZW4gcGVlcnMuDQogICBJdCBpcyBhbHNvIGEgdmVyeSBjb21tb24gYmVzdCBw cmFjdGljZSBhbW9uZyBvcGVyYXRvcnMgdG8gcHJvcGFnYXRlDQogICB2YXJpb3VzIGFkZGl0aW9u YWwgaW5mb3JtYXRpb24gYWJvdXQgcm91dGVzIGludHJhLWRvbWFpbi4gIFRoZSBtb3N0DQogICBj b21tb24gdG9vbCB1c2VkIHRvZGF5IHRvIGF0dGFjaCB2YXJpb3VzIGluZm9ybWF0aW9uIGFib3V0 IHJvdXRlcyBpcw0KICAgdGhyb3VnaCB0aGUgdXNlIG9mIEJHUCBjb21tdW5pdGllcyBbUkZDMTk5 N10uDQoNCiAgIFN1Y2ggaW5mb3JtYXRpb24gaXMgaW1wb3J0YW50IHRvIGFsbG93IEJHUCBzcGVh a2VycyB0byBwZXJmb3JtIHNvbWUNCiAgIG11dHVhbGx5IGFncmVlZCBhY3Rpb25zIHdpdGhvdXQg dGhlIG5lZWQgdG8gbWFpbnRhaW4gYSBzZXBhcmF0ZQ0KICAgb2ZmbGluZSBkYXRhYmFzZSBmb3Ig ZWFjaCB0dXBsZSBvZiBwcmVmaXggYW5kIGFzc29jaWF0ZWQgc2V0IG9mDQogICBhY3Rpb24gZW50 cmllcy4NCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IGVuY29kaW5nIHdoaWNoIHdp bGwgZW5oYW5jZSBhbmQgc2ltcGxpZnkNCiAgIHdoYXQgY2FuIGJlIGFjY29tcGxpc2hlZCB0b2Rh eSB3aXRoIHRoZSB1c2Ugb2YgQkdQIGNvbW11bml0aWVzLiAgVGhlDQogICBtb3N0IGltcG9ydGFu dCBhZGRpdGlvbiB0aGlzIHNwZWNpZmljYXRpb24gbWFrZXMgb3ZlciBjdXJyZW50bHkNCiAgIGRl ZmluZWQgQkdQIGNvbW11bml0aWVzIGlzIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnksIGNhcnJ5IGFz IHdlbGwgYXMNCiAgIHVzZSBmb3IgZXhlY3V0aW9uIGFuIG9wZXJhdG9yJ3MgZGVmaW5lZCBzZXQg b2YgcGFyYW1ldGVycy4gIEl0IGFsc28NCiAgIHByb3ZpZGVzIGFuIGV4dGVuc2libGUgcGxhdGZv cm0gZm9yIGFueSBuZXcgY29tbXVuaXR5IGVuY29kaW5nIG5lZWRzDQogICBpbiB0aGUgZnV0dXJl Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= --_000_19AB2A007F56DB4E8257F949A2FB98588D28952ENKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo4ODQyMTg1MjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi01NTIyMDIxNTggNTc3MTE1NzY0IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6OTsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674GuOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDox OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBoYXZlIGEgY29tbWVudCB0byB0aGUgZXhhbXBsZSBpbiB0aGlzIGRvY3VtZW50OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OzkuMi4m bmJzcDsgRXhhbXBsZSBXaWRlIENvbW11bml0eSBFbmNvZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFTX1BBVEggcHJl cGVuZCA0IFRJTUVTIFRPIEFTIDI0MjQsIEFTIDg4ODgsIHRvIHBlZXJzIG1hcmtlZCBhczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtBbXN0ZXJkYW0gKDEwMCkgb3IgdG8gcGVlcnMgbWFya2VkIE1vc2NvdyAoMTA0 KSwgYnV0IG5vdCB0byBwZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBOZXcgWW9yayAoMTAxKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYmbmJzcDsgQVMgNjQ0OTYgaGFzIGFu b3RoZXIgcGVlciBBUyAoZS5nLiwgQVMgMTAwMDApLCAmbmJzcDtBUyAxMDAwMCBub3QgY29udGFp bmluZyBpbiBUYXJnZXQgVExWLCBhbmQgYWxzbyBub3QgY29udGFpbmluZyBpbiBFeGNsdWRlIFRh cmdldCBUTFYuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldo ZW4gQVMgNjQ0OTYgc2VuZHMgYSBiZ3Agcm91dGUgdG8gQVMgMTAwMDAsIHdoYXQgYSBwb2xpY3kg aXQgd2lsbCBiZSBleGVjdXRlZCA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5QcmVwZW5kIG9yIG5vdCBwcmVwZW5kIDQgVElNRVMgdG8gcGVlciBhcyAxMDAwMD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWF5YmUgSSBtaXN1bmRlcnN0YW5k IHRoZSBjYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLVNodW53YW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXQ0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7ku6PooaggPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlJvYmVydCBSYXN6dWs8 YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkemAgeaXtumX tDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxNTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjM8L3NwYW4+5pyIPHNwYW4gbGFuZz0i RU4tVVMiPjg8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiA3OjA5PGJyPg0KPC9zcGFuPjxi PuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IGlkciB3Zzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBbSWRyXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtcmFzenVrLXdpZGUtYmdwLWNvbW11bml0aWVzLTA1LnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJhc3p1ay13aWRlLWJncC1jb21tdW5pdGll cy0wNS50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2JlcnQg UmFzenVrIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4N Ck5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1yYXN6 dWstd2lkZS1iZ3AtY29tbXVuaXRpZXM8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDswNTxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg V2lkZSBCR1AgQ29tbXVuaXRpZXMgQXR0cmlidXRlPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsg MjAxNS0wMy0wNjxicj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAyMzxicj4NClVSTDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1yYXN6dWstd2lkZS1iZ3AtY29tbXVuaXRpZXMtMDUudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYXN6dWstd2lkZS1iZ3At Y29tbXVuaXRpZXMtMDUudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcmFzenVrLXdpZGUtYmdwLWNvbW11bml0aWVzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJhc3p1ay13aWRlLWJncC1jb21tdW5pdGll cy88L2E+PGJyPg0KSHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFzenVrLXdpZGUtYmdwLWNvbW11bml0 aWVzLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt cmFzenVrLXdpZGUtYmdwLWNvbW11bml0aWVzLTA1PC9hPjxicj4NCkRpZmY6Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1yYXN6dWstd2lkZS1iZ3AtY29tbXVuaXRpZXMtMDUiIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1yYXN6dWst d2lkZS1iZ3AtY29tbXVuaXRpZXMtMDU8L2E+PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7ICZuYnNwO1JvdXRlIHRhZ2dpbmcgcGxheXMgYW4gaW1wb3J0YW50IHJvbGUgaW4gZXh0ZXJu YWwgQkdQIFtSRkM0MjcxXTxicj4NCiZuYnNwOyAmbmJzcDtyZWxhdGlvbnMsIGluIGNvbW11bmlj YXRpbmcgdmFyaW91cyByb3V0aW5nIHBvbGljaWVzIGJldHdlZW4gcGVlcnMuPGJyPg0KJm5ic3A7 ICZuYnNwO0l0IGlzIGFsc28gYSB2ZXJ5IGNvbW1vbiBiZXN0IHByYWN0aWNlIGFtb25nIG9wZXJh dG9ycyB0byBwcm9wYWdhdGU8YnI+DQombmJzcDsgJm5ic3A7dmFyaW91cyBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIGFib3V0IHJvdXRlcyBpbnRyYS1kb21haW4uJm5ic3A7IFRoZSBtb3N0PGJyPg0K Jm5ic3A7ICZuYnNwO2NvbW1vbiB0b29sIHVzZWQgdG9kYXkgdG8gYXR0YWNoIHZhcmlvdXMgaW5m b3JtYXRpb24gYWJvdXQgcm91dGVzIGlzPGJyPg0KJm5ic3A7ICZuYnNwO3Rocm91Z2ggdGhlIHVz ZSBvZiBCR1AgY29tbXVuaXRpZXMgW1JGQzE5OTddLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtT dWNoIGluZm9ybWF0aW9uIGlzIGltcG9ydGFudCB0byBhbGxvdyBCR1Agc3BlYWtlcnMgdG8gcGVy Zm9ybSBzb21lPGJyPg0KJm5ic3A7ICZuYnNwO211dHVhbGx5IGFncmVlZCBhY3Rpb25zIHdpdGhv dXQgdGhlIG5lZWQgdG8gbWFpbnRhaW4gYSBzZXBhcmF0ZTxicj4NCiZuYnNwOyAmbmJzcDtvZmZs aW5lIGRhdGFiYXNlIGZvciBlYWNoIHR1cGxlIG9mIHByZWZpeCBhbmQgYXNzb2NpYXRlZCBzZXQg b2Y8YnI+DQombmJzcDsgJm5ic3A7YWN0aW9uIGVudHJpZXMuPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBlbmNvZGluZyB3aGljaCB3aWxsIGVuaGFu Y2UgYW5kIHNpbXBsaWZ5PGJyPg0KJm5ic3A7ICZuYnNwO3doYXQgY2FuIGJlIGFjY29tcGxpc2hl ZCB0b2RheSB3aXRoIHRoZSB1c2Ugb2YgQkdQIGNvbW11bml0aWVzLiZuYnNwOyBUaGU8YnI+DQom bmJzcDsgJm5ic3A7bW9zdCBpbXBvcnRhbnQgYWRkaXRpb24gdGhpcyBzcGVjaWZpY2F0aW9uIG1h a2VzIG92ZXIgY3VycmVudGx5PGJyPg0KJm5ic3A7ICZuYnNwO2RlZmluZWQgQkdQIGNvbW11bml0 aWVzIGlzIHRoZSBhYmlsaXR5IHRvIHNwZWNpZnksIGNhcnJ5IGFzIHdlbGwgYXM8YnI+DQombmJz cDsgJm5ic3A7dXNlIGZvciBleGVjdXRpb24gYW4gb3BlcmF0b3IncyBkZWZpbmVkIHNldCBvZiBw YXJhbWV0ZXJzLiZuYnNwOyBJdCBhbHNvPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3ZpZGVzIGFuIGV4 dGVuc2libGUgcGxhdGZvcm0gZm9yIGFueSBuZXcgY29tbXVuaXR5IGVuY29kaW5nIG5lZWRzPGJy Pg0KJm5ic3A7ICZuYnNwO2luIHRoZSBmdXR1cmUuPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_19AB2A007F56DB4E8257F949A2FB98588D28952ENKGEML512MBSchi_-- From nobody Thu Mar 26 08:39:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50A1AD289 for ; Thu, 26 Mar 2015 08:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPa1pSLnJs54 for ; Thu, 26 Mar 2015 08:39:32 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6DB71AD23D for ; Thu, 26 Mar 2015 08:39:32 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so49392649iec.2 for ; Thu, 26 Mar 2015 08:39:32 -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=T0t95502BcsNFv18nfDmNzzeTG74JJ/CKyY7e+JcUXc=; b=jUeGGIRA6yEt9wMayUMIS5w6sGZ7L1KN4vEzi+YPVoTMBQKUpdicLxH72MRJ6fjlu/ mnnKVR0tNI4Z/NNe7hLu7DKpvGloWW808yyarxvakXOzUsCoHl8aBbq1EPT+jUsgudcn JYfiiVmpUSIVgWgXXwRBG+dH/nuzXJTfPHETtdCGtkKISqqzk59fR36U97OHoHLtmK7R YDTmfHf7By7F/LlKFTQQPUpEgGSv/1RTEZEEyjTaWNQDy77KeiFiX84dF0QBF8+RGrfa LibFMjooB4Gmmhl8t4TR56ZTXYRR+Zf+R1pyFuKNvwnvZS7P/wiLgrKxhMBsxaltCHmi JQ1g== MIME-Version: 1.0 X-Received: by 10.50.131.196 with SMTP id oo4mr38207130igb.2.1427384372193; Thu, 26 Mar 2015 08:39:32 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.70 with HTTP; Thu, 26 Mar 2015 08:39:32 -0700 (PDT) In-Reply-To: <19AB2A007F56DB4E8257F949A2FB98588D28952E@NKGEML512-MBS.china.huawei.com> References: <20150307225549.18830.9906.idtracker@ietfa.amsl.com> <19AB2A007F56DB4E8257F949A2FB98588D28952E@NKGEML512-MBS.china.huawei.com> Date: Thu, 26 Mar 2015 16:39:32 +0100 X-Google-Sender-Auth: hva7fSid8ejjEA212HFVHE9UrIE Message-ID: From: Robert Raszuk To: Zhuangshunwan Content-Type: multipart/alternative; boundary=047d7b2e1465767298051232d2b6 Archived-At: Cc: idr wg Subject: Re: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-communities-05.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 15:39:35 -0000 --047d7b2e1465767298051232d2b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Shunwan, The expected behaviour when processing such wide community would be not to execute the prepend to AS 10000. Of course if you already have other policy permitting such append it will be executed, but this is outside of the scope. Cheers, r. On Thu, Mar 26, 2015 at 1:33 PM, Zhuangshunwan wrote: > Hi Robert, > > > > I have a comment to the example in this document: > > > > >9.2. Example Wide Community Encoding > > > > > AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers marked as > > > Amsterdam (100) or to peers marked Moscow (104), but not to peers > > > in New York (101). > > > > If AS 64496 has another peer AS (e.g., AS 10000), AS 10000 not > containing in Target TLV, and also not containing in Exclude Target TLV. > > When AS 64496 sends a bgp route to AS 10000, what a policy it will be > executed ? > > Prepend or not prepend 4 TIMES to peer as 10000? > > > > Maybe I misunderstand the case? > > > > --Shunwan > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Idr [mailto:idr-bounces@ietf.org] *=E4=BB= =A3=E8=A1=A8 *Robert Raszuk > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2015=E5=B9=B43=E6=9C=888=E6=97=A5= 7:09 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* idr wg > *=E4=B8=BB=E9=A2=98:* [Idr] Fwd: New Version Notification for > draft-raszuk-wide-bgp-communities-05.txt > > > > > > A new version of I-D, draft-raszuk-wide-bgp-communities-05.txt > > has been successfully submitted by Robert Raszuk and posted to the > IETF repository. > > Name: draft-raszuk-wide-bgp-communities > Revision: 05 > Title: Wide BGP Communities Attribute > Document date: 2015-03-06 > Group: Individual Submission > Pages: 23 > URL: > http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.= txt > Status: > https://datatracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/ > Htmlized: > http://tools.ietf.org/html/draft-raszuk-wide-bgp-communities-05 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-raszuk-wide-bgp-communities-05 > > Abstract: > Route tagging plays an important role in external BGP [RFC4271] > relations, in communicating various routing policies between peers. > It is also a very common best practice among operators to propagate > various additional information about routes intra-domain. The most > common tool used today to attach various information about routes is > through the use of BGP communities [RFC1997]. > > Such information is important to allow BGP speakers to perform some > mutually agreed actions without the need to maintain a separate > offline database for each tuple of prefix and associated set of > action entries. > > This document defines a new encoding which will enhance and simplify > what can be accomplished today with the use of BGP communities. The > most important addition this specification makes over currently > defined BGP communities is the ability to specify, carry as well as > use for execution an operator's defined set of parameters. It also > provides an extensible platform for any new community encoding needs > in the future. > > The IETF Secretariat > > > --047d7b2e1465767298051232d2b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Shunwan,

=
The expected behaviour when processing such wide community wo= uld be not to execute the prepend to AS 10000.=C2=A0
Of course if you already have other policy permitting = such append it will be executed, but this is outside of the scope.

Cheers,
r.



On Thu, Mar 26, 2015 at 1:33 PM, Zhuangshun= wan <zhuangshunwan@huawei.com> wrote:

Hi Robert,=

=C2= =A0

I have a c= omment to the example in this document:

=C2=A0

>9.2.=C2=A0 Example Wide C= ommunity Encoding

=C2= =A0

>=C2=A0= =C2=A0=C2=A0=C2=A0 AS_PATH prepend 4 TIMES TO AS 2424, AS 8888, to peers ma= rked as

> =C2= =A0=C2=A0=C2=A0=C2=A0Amsterdam (100) or to peers marked Moscow (104), but n= ot to peers

>=C2=A0= =C2=A0=C2=A0=C2=A0 in New York (101).

=C2= =A0

If=C2=A0 A= S 64496 has another peer AS (e.g., AS 10000), =C2=A0AS 10000 not containing= in Target TLV, and also not containing in Exclude Target TLV.

When AS 64= 496 sends a bgp route to AS 10000, what a policy it will be executed ?

Prepend or= not prepend 4 TIMES to peer as 10000?

=C2= =A0

Maybe I mi= sunderstand the case?

=C2= =A0

--Shunwan<= u>

=C2= =A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: Idr [mailto:idr-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Robert Raszuk
=E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4: 2015=E5=B9=B43=E6=9C=888=E6=97=A5<= span lang=3D"EN-US"> 7:09
=E6=94=B6=E4=BB=B6=E4=BA=BA: idr wg
=E4=B8=BB=E9=A2=98: [Idr] Fwd: New Version Notification for draft-raszuk-wide-bgp-commu= nities-05.txt

=C2=A0

=C2=A0

A new version of I-D, draft-raszuk-wide-bgp= -communities-05.txt

= has been successfully submitted by Robert Raszuk and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-raszuk-wide-bgp-communi= ties
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Wide BGP Communities Attribute
Document date:=C2=A0 2015-03-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 23
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-raszuk-wide-bgp-communities-05.tx= t
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://dat= atracker.ietf.org/doc/draft-raszuk-wide-bgp-communities/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.or= g/html/draft-raszuk-wide-bgp-communities-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-raszuk-wide-bgp-communities-05
Abstract:
=C2=A0 =C2=A0Route tagging plays an important role in external BGP [RFC4271= ]
=C2=A0 =C2=A0relations, in communicating various routing policies between p= eers.
=C2=A0 =C2=A0It is also a very common best practice among operators to prop= agate
=C2=A0 =C2=A0various additional information about routes intra-domain.=C2= =A0 The most
=C2=A0 =C2=A0common tool used today to attach various information about rou= tes is
=C2=A0 =C2=A0through the use of BGP communities [RFC1997].

=C2=A0 =C2=A0Such information is important to allow BGP speakers to perform= some
=C2=A0 =C2=A0mutually agreed actions without the need to maintain a separat= e
=C2=A0 =C2=A0offline database for each tuple of prefix and associated set o= f
=C2=A0 =C2=A0action entries.

=C2=A0 =C2=A0This document defines a new encoding which will enhance and si= mplify
=C2=A0 =C2=A0what can be accomplished today with the use of BGP communities= .=C2=A0 The
=C2=A0 =C2=A0most important addition this specification makes over currentl= y
=C2=A0 =C2=A0defined BGP communities is the ability to specify, carry as we= ll as
=C2=A0 =C2=A0use for execution an operator's defined set of parameters.= =C2=A0 It also
=C2=A0 =C2=A0provides an extensible platform for any new community encoding= needs
=C2=A0 =C2=A0in the future.

The IETF Secretariat

=C2=A0


--047d7b2e1465767298051232d2b6-- From nobody Thu Mar 26 14:19:03 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84B1B2F2F for ; Thu, 26 Mar 2015 14:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYuSzbk6dw-y for ; Thu, 26 Mar 2015 14:18:57 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F4B1B2F27 for ; Thu, 26 Mar 2015 14:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28387; q=dns/txt; s=iport; t=1427404737; x=1428614337; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=cZCQ8lHtas+KGbhHCJcUKvI2ofgoFboPSTxpICUmacE=; b=lPT7dp6hmdAiZd4KYJAlUTMeP7hr8sT6NoyLNbMdG+mWPwiTwB5pKZ/p SwnilmUc+uSc3OSFG7TcolSFhijHoFcGZfj6bafr2I0SHtmd3Adm581gR LyZwLGcX3dPN6VWEWBpoX5RhGVc1Z3/4e0q29RxYFrEbMtcky1mkuAzbK 0=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBQDgdhRV/5FdJa1cgkNDUloEwl+CS4V4AoFZTAEBAQEBAX2EFAECBAUBHwgBNgccBAEIBwoDAQIGAQIYAQYJFQEDAgkMFAkIAQEEAREBBgiIDQMRDcZDA4VNAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLJIQWCgEGASQRCgwBCgEGhCcFimmDWYFDS4FpgTIBU4Ikg1yBGzqCdowbg0cig25vAQEBAX4BCBcifwEBAQ X-IronPort-AV: E=Sophos;i="5.11,475,1422921600"; d="gif'147?scan'147,208,217,147";a="135765843" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 26 Mar 2015 21:18:56 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2QLItZo019685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 21:18:55 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 16:18:55 -0500 From: "Hyojeong Kim (hyojekim)" To: "stephane.litkowski@orange.com" , "idr@ietf.org" Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcwAQA00A Date: Thu, 26 Mar 2015 21:18:55 +0000 Message-ID: In-Reply-To: <13392_1427370077_5513F05D_13392_2397_1_9E32478DFA9976438E7A22F69B08FF921662B61C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.154.212.208] Content-Type: multipart/mixed; boundary="_004_D139C38A324B2hyojekimciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 21:19:01 -0000 --_004_D139C38A324B2hyojekimciscocom_ Content-Type: multipart/alternative; boundary="_000_D139C38A324B2hyojekimciscocom_" --_000_D139C38A324B2hyojekimciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable First, I have a general comment. We cannot control the mapping of interface= to group id for all upstream routers/ASes. At FS NLRI originator, group id= 1 identifies all Internet customer interfaces, but we cannot assume the sa= me at a far upstream router which belongs to a different AS. Regarding this NLRI vs. EXTCT issue, as the interface group id is meaningfu= l within a limited set of routers/ASes, we should not add it to NLRI. If it= is implemented as EXTCT, we could consider a different AS border router mi= ght replace it into some other EXTCT which is meaningful within its domain. -Hyojeong From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 4:41 AM To: "idr@ietf.org" > Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT Hi IDR Folks, During this week, I presented the updates of the flowspec interfaceset draf= t. We are currently thinking on moving this interfaceset from extcommunity to = NLRI and we require your feedback on this. Why such change ? Consider that you may apply filters with the same =93matching=94 but differ= ent actions to different interface-groups. For example: Rule#1 Match : src-ip 10/8, dst-port 53 Action : rate-limit 10000 Rule#2 Match : src-ip 10/8, dst-port 53 Action : drop I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfacese= t #200. As interfaceset is an extct and not part of NLRI, ADDPATH will be required = in order to ensure propagation of both paths for the same NLRI. In case we move interfaceset as part of the NLRI, we do not have this ADDPA= TH requirement anymore, as we would have two different NLRIs Now Robert R. pointed me the need to control interAS advertisement, as inte= rfaceset have only a local significance. There=92s two cases : - #1 : There is an agreement between myAS and myUpstreamAS to use = some interface-set of myUpstreamAS and let myAS apply some filters on myUps= treamAS. - #2 : Such interfaceset information sharing is not authorized bet= ween both ASes, and only BGPFS rules with no interfaceset should be propaga= ted to myUpstreamAS. In #2, in case the interfaceset is extct, a BGP policy could be implemented= to deny BGP paths containing interfaceset towards myUpstreamAS. In case th= e interfaceset is part of NLRI, policy is still doable but requires some fi= ne grain NLRI matching in policy framework. To summarize : EXTCT approach : - Pros : o Permit easy filtering o Permit to use a common NLRI for multiple interfaceset if action is the = same - Cons : o But requires ADDPATH as soon as action is different for each interfaces= et NLRI approach : - Pros : o Do not require ADDPATH, may be permit an easier reading. Interfaceset i= s more a =93match-like=94 - Cons : o Filtering requires more advanced policy matching o Requires multiple NLRIs if we want to apply the same matching/actions t= o different interfaceset These pros/cons may not be exhaustive, so please comment and raise your poi= nt regarding the approach we need to take. Thanks a lot ! [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D139C38A324B2hyojekimciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4F456940934E1547867AEB6C302F50E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
First, I have a general comment. We cannot control the mapping of inte= rface to group id for all upstream routers/ASes. At FS NLRI originator, gro= up id 1 identifies all Internet customer interfaces, but we cannot assume t= he same at a far upstream router which belongs to a different AS. 

Regarding this NLRI vs. EXTCT issue, as the interface group id is mean= ingful within a limited set of routers/ASes, we should not add it to NLRI. = If it is implemented as EXTCT, we could consider a different AS border rout= er might replace it into some other EXTCT which is meaningful within its domain. 

-Hyojeong


From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Thursday, March 26, 2015 4:41= AM
To: "idr@ietf.org" <idr@ietf.= org>
Subject: [Idr] draft-litkowski-idr-= flowspec-interfaceset =3D> NLRI vs EXTCT

Hi IDR Folks,

 

During this week, I presented the updates of the flo= wspec interfaceset draft.

We are currently thinking on moving this interfacese= t from extcommunity to NLRI and we require your feedback on this. Why such = change ?

 

Consider that you may apply filters with the same = =93matching=94 but different actions to different interface-groups. For exa= mple:

Rule#1

Match : src-ip 10/8, dst-port 53

Action : rate-limit 10000

 

Rule#2

Match : src-ip 10/8, dst-port 53

Action : drop

 

I would like to apply Rule#1 on interfaceset #100 an= d Rule#2 on interfaceset #200.

 

As interfaceset is an extct and not part of NLRI, AD= DPATH will be required in order to ensure propagation of both paths for the= same NLRI.

In case we move interfaceset as part of the NLRI, we= do not have this ADDPATH requirement anymore, as we would have two differe= nt NLRIs

 

 

 

Now Robert R. pointed me the need to control interAS= advertisement, as interfaceset have only a local significance.<= /p>

There=92s two cases :

-   =        #1 : There is an agreement between myAS and myU= pstreamAS to use some interface-set of myUpstreamAS and let myAS apply some= filters on myUpstreamAS.

-   =        #2 : Such interfaceset information sharing is n= ot authorized between both ASes, and only BGPFS rules with no interfaceset = should be propagated to myUpstreamAS.

In #2, in case the interfaceset is extct, a BGP poli= cy could be implemented to deny BGP paths containing interfaceset towards m= yUpstreamAS. In case the interfaceset is part of NLRI, policy is still doab= le but requires some fine grain NLRI matching in policy framework.

 

To summarize :

EXTCT approach :

-   =        Pros :

o   Permit easy filtering

o   Permit to use a common NLRI for multiple= interfaceset if action is the same

-   =        Cons :

o   But requires ADDPATH as soon as action i= s different for each interfaceset

 

NLRI approach :

-   =        Pros :

o   Do not require ADDPATH, may be permit an= easier reading. Interfaceset is more a =93match-like=94

-   =        Cons :

o   Filtering requires more advanced policy = matching

o   Requires multiple NLRIs if we want to ap= ply the same matching/actions to different interfaceset

 

 

These pros/cons may not be exhaustive, so please com= ment and raise your point regarding the approach we need to take.

 

Thanks a lot !

 

 

3D"Orange

 <= /p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D139C38A324B2hyojekimciscocom_-- --_004_D139C38A324B2hyojekimciscocom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Thu, 26 Mar 2015 21:18:54 GMT"; modification-date="Thu, 26 Mar 2015 21:18:54 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_D139C38A324B2hyojekimciscocom_-- From nobody Thu Mar 26 15:54:15 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D01A1A70 for ; Thu, 26 Mar 2015 15:54:14 -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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zxXdK59-5qj for ; Thu, 26 Mar 2015 15:54:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2756C1A049A for ; Thu, 26 Mar 2015 15:54:08 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id CEB79374303; Thu, 26 Mar 2015 23:54:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B115318004F; Thu, 26 Mar 2015 23:54:06 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 23:54:06 +0100 From: To: "Hyojeong Kim (hyojekim)" , "idr@ietf.org" Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcwAQA00AAAdafGA= Date: Thu, 26 Mar 2015 22:54:05 +0000 Message-ID: <2641_1427410446_55148E0E_2641_15689_1_9E32478DFA9976438E7A22F69B08FF921662BE12@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <13392_1427370077_5513F05D_13392_2397_1_9E32478DFA9976438E7A22F69B08FF921662B61C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.181519 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 22:54:14 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Inline comments From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com] Sent: Thursday, March 26, 2015 16:19 To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT First, I have a general comment. We cannot control the mapping of interface= to group id for all upstream routers/ASes. At FS NLRI originator, group id= 1 identifies all Internet customer interfaces, but we cannot assume the sa= me at a far upstream router which belongs to a different AS. [SLI] Agree, its similar to BGP community, an upstream AS may authorize you= to use its own interface-group. But for sure group-id x in AS#1 may not ex= ist or mean something else in AS#2. Regarding this NLRI vs. EXTCT issue, as the interface group id is meaningfu= l within a limited set of routers/ASes, we should not add it to NLRI. If it= is implemented as EXTCT, we could consider a different AS border router mi= ght replace it into some other EXTCT which is meaningful within its domain. [SLI] That's a good point. But as pointed for interAS, you may be able to f= ilter those NLRIs that apply only to your AS. It's technically possible, no= w the question is : is it a good design ? may be not In case we keep EXTCT, we must point that using ADD-PATH is mandatory. Robert R. pointed me also that maybe using another AFI/SAFI and putting int= erface-group in NLRI of this new AFI/SAFI will permit to keep a level of is= olation with the DDoS use case which is typically interAS. -Hyojeong From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 4:41 AM To: "idr@ietf.org" > Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT Hi IDR Folks, During this week, I presented the updates of the flowspec interfaceset draf= t. We are currently thinking on moving this interfaceset from extcommunity to = NLRI and we require your feedback on this. Why such change ? Consider that you may apply filters with the same "matching" but different = actions to different interface-groups. For example: Rule#1 Match : src-ip 10/8, dst-port 53 Action : rate-limit 10000 Rule#2 Match : src-ip 10/8, dst-port 53 Action : drop I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfacese= t #200. As interfaceset is an extct and not part of NLRI, ADDPATH will be required = in order to ensure propagation of both paths for the same NLRI. In case we move interfaceset as part of the NLRI, we do not have this ADDPA= TH requirement anymore, as we would have two different NLRIs Now Robert R. pointed me the need to control interAS advertisement, as inte= rfaceset have only a local significance. There's two cases : - #1 : There is an agreement between myAS and myUpstreamAS to use = some interface-set of myUpstreamAS and let myAS apply some filters on myUps= treamAS. - #2 : Such interfaceset information sharing is not authorized bet= ween both ASes, and only BGPFS rules with no interfaceset should be propaga= ted to myUpstreamAS. In #2, in case the interfaceset is extct, a BGP policy could be implemented= to deny BGP paths containing interfaceset towards myUpstreamAS. In case th= e interfaceset is part of NLRI, policy is still doable but requires some fi= ne grain NLRI matching in policy framework. To summarize : EXTCT approach : - Pros : o Permit easy filtering o Permit to use a common NLRI for multiple interfaceset if action is the = same - Cons : o But requires ADDPATH as soon as action is different for each interfaces= et NLRI approach : - Pros : o Do not require ADDPATH, may be permit an easier reading. Interfaceset i= s more a "match-like" - Cons : o Filtering requires more advanced policy matching o Requires multiple NLRIs if we want to apply the same matching/actions t= o different interfaceset These pros/cons may not be exhaustive, so please comment and raise your poi= nt regarding the approach we need to take. Thanks a lot ! [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Inline comments

 

From: Hyojeong= Kim (hyojekim) [mailto:hyojekim@cisco.com]
Sent: Thursday, March 26, 2015 16:19
To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D>= NLRI vs EXTCT

 

First, = I have a general comment. We cannot control the mapping of interface to gro= up id for all upstream routers/ASes. At FS NLRI originator, group id 1 iden= tifies all Internet customer interfaces, but we cannot assume the same at a far upstream router which belongs to a = different AS. 

[SLI] Agree, its simil= ar to BGP community, an upstream AS may authorize you to use its own interf= ace-group. But for sure group-id x in AS#1 may not exist or mean something = else in AS#2.

&n= bsp;

Regardi= ng this NLRI vs. EXTCT issue, as the interface group id is meaningful withi= n a limited set of routers/ASes, we should not add it to NLRI. If it is imp= lemented as EXTCT, we could consider a different AS border router might replace it into some other EXTCT which = is meaningful within its domain. 

[SLI]= That’s a good point. But as pointed for interAS, you may be able to = filter those NLRIs that apply only to your AS. It’s technically possi= ble, now the question is : is it a good design ? may be not

In ca= se we keep EXTCT, we must point that using ADD-PATH is mandatory.

=  

Rober= t R. pointed me also that maybe using another AFI/SAFI and putting interfac= e-group in NLRI of this new AFI/SAFI will permit to keep a level of isolati= on with the DDoS use case which is typically interAS.

=  

=  

 

-Hyojeo= ng

&n= bsp;

&n= bsp;

From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Thursday, March 26, 2015 4:41 AM
To: "idr@ietf.org" <= ;idr@ietf.org>
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLR= I vs EXTCT

&n= bsp;

Hi IDR Folks,=

 =

During this week, I pres= ented the updates of the flowspec interfaceset draft.

We are currently thinkin= g on moving this interfaceset from extcommunity to NLRI and we require your= feedback on this. Why such change ?

 =

Consider that you may ap= ply filters with the same “matching” but different actions to d= ifferent interface-groups. For example:

Rule#1=

Match : src-ip 10/8, dst= -port 53

Action : rate-limit 1000= 0

 =

Rule#2=

Match : src-ip 10/8, dst= -port 53

Action : drop=

 =

I would like to apply Ru= le#1 on interfaceset #100 and Rule#2 on interfaceset #200.

 =

As interfaceset is an ex= tct and not part of NLRI, ADDPATH will be required in order to ensure propa= gation of both paths for the same NLRI.

In case we move interfac= eset as part of the NLRI, we do not have this ADDPATH requirement anymore, = as we would have two different NLRIs

 =

 =

 =

Now Robert R. pointed me= the need to control interAS advertisement, as interfaceset have only a loc= al significance.

There’s two cases = :

-  &= nbsp;       #1 : There is an= agreement between myAS and myUpstreamAS to use some interface-set of myUps= treamAS and let myAS apply some filters on myUpstreamAS.<= /p>

-  &= nbsp;       #2 : Such interf= aceset information sharing is not authorized between both ASes, and only BG= PFS rules with no interfaceset should be propagated to myUpstreamAS.

In #2, in case the inter= faceset is extct, a BGP policy could be implemented to deny BGP paths conta= ining interfaceset towards myUpstreamAS. In case the interfaceset is part o= f NLRI, policy is still doable but requires some fine grain NLRI matching in policy framework.

 =

To summarize :

EXTCT approach :

-  &= nbsp;       Pros :

o   Permit easy filt= ering

o   Permit to use a = common NLRI for multiple interfaceset if action is the same

-  &= nbsp;       Cons :

o   But requires ADD= PATH as soon as action is different for each interfaceset=

 =

NLRI approach :

-  &= nbsp;       Pros :

o   Do not require A= DDPATH, may be permit an easier reading. Interfaceset is more a “matc= h-like”

-  &= nbsp;       Cons :

o   Filtering requir= es more advanced policy matching

o   Requires multipl= e NLRIs if we want to apply the same matching/actions to different interfac= eset

 =

 =

These pros/cons may not = be exhaustive, so please comment and raise your point regarding the approac= h we need to take.

 =

Thanks a lot !

 =

 =

3D"Orange

 

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks=

phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 = 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 26 Mar 2015 22:54:04 GMT"; modification-date="Thu, 26 Mar 2015 22:54:04 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_-- From nobody Thu Mar 26 16:04:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56701A005D for ; Thu, 26 Mar 2015 16:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4xqV2s1psNe for ; Thu, 26 Mar 2015 16:04:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BEE1A0354 for ; Thu, 26 Mar 2015 16:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40635; q=dns/txt; s=iport; t=1427411071; x=1428620671; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=BntCj+DakN4hcsnTT4MDbBb1fx7hpw4kmMZ1E+s/lvE=; b=BTxvYBYcadBIajSVP1u/gE/b4fBPMayy58Y+Rtt+5B5NLtL+wsElBVqT 8ayBXStf7vqBuQxF+35So1gguA4CTwphCHV7tMJHswY6VVyGx62C7QLdF q0i3tV/GOmAHubWdQzyJqem5t+nhkB8xRZfVrc+jgfshRZ0kimdfGkY0c M=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBQCDjxRV/4gNJK1cgkNDUloEwl+CS4V4AoFFTAEBAQEBAX2EFAEBAQQFAR8IATYHHAQBCAcKAwEBAQYBAhgBBgkVAQMCCQwUCQgBAQQBEQEGCAaIBwMRDcYtA4VNAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLJIQWCgEGASQRCgwBCgEGhCcFimmDWYFDS4FpgTIBU4Ikg1yBGzqCdowbg0cig25vAQEBAX4BCBcifwEBAQ X-IronPort-AV: E=Sophos;i="5.11,475,1422921600"; d="gif'147?scan'147,208,217,147";a="407015833" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 26 Mar 2015 23:04:30 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2QN4UKE009933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 23:04:30 GMT Received: from xmb-aln-x13.cisco.com ([169.254.15.15]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 18:04:29 -0500 From: "Hyojeong Kim (hyojekim)" To: "stephane.litkowski@orange.com" , "idr@ietf.org" Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcwAQA00AAAdafGD//+KsgA== Date: Thu, 26 Mar 2015 23:04:29 +0000 Message-ID: In-Reply-To: <2641_1427410446_55148E0E_2641_15689_1_9E32478DFA9976438E7A22F69B08FF921662BE12@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.154.212.208] Content-Type: multipart/mixed; boundary="_004_D139DD32324D2hyojekimciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:04:35 -0000 --_004_D139DD32324D2hyojekimciscocom_ Content-Type: multipart/alternative; boundary="_000_D139DD32324D2hyojekimciscocom_" --_000_D139DD32324D2hyojekimciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Please see the reply inline: From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 3:54 PM To: Hyojeong Kim >, "idr@ietf= .org" > Subject: RE: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT Hi, Inline comments From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com] Sent: Thursday, March 26, 2015 16:19 To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT First, I have a general comment. We cannot control the mapping of interface= to group id for all upstream routers/ASes. At FS NLRI originator, group id= 1 identifies all Internet customer interfaces, but we cannot assume the sa= me at a far upstream router which belongs to a different AS. [SLI] Agree, its similar to BGP community, an upstream AS may authorize you= to use its own interface-group. But for sure group-id x in AS#1 may not ex= ist or mean something else in AS#2. Regarding this NLRI vs. EXTCT issue, as the interface group id is meaningfu= l within a limited set of routers/ASes, we should not add it to NLRI. If it= is implemented as EXTCT, we could consider a different AS border router mi= ght replace it into some other EXTCT which is meaningful within its domain. [SLI] That=92s a good point. But as pointed for interAS, you may be able to= filter those NLRIs that apply only to your AS. It=92s technically possible= , now the question is : is it a good design ? may be not In case we keep EXTCT, we must point that using ADD-PATH is mandatory. Robert R. pointed me also that maybe using another AFI/SAFI and putting int= erface-group in NLRI of this new AFI/SAFI will permit to keep a level of is= olation with the DDoS use case which is typically interAS. [HK] I understand the point/concern about ADD-PATH becoming mandatory. But, if we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs = at border routers, but we cannot modify the NLRIs so that it has different = group id. -Hyojeong From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 4:41 AM To: "idr@ietf.org" > Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT Hi IDR Folks, During this week, I presented the updates of the flowspec interfaceset draf= t. We are currently thinking on moving this interfaceset from extcommunity to = NLRI and we require your feedback on this. Why such change ? Consider that you may apply filters with the same =93matching=94 but differ= ent actions to different interface-groups. For example: Rule#1 Match : src-ip 10/8, dst-port 53 Action : rate-limit 10000 Rule#2 Match : src-ip 10/8, dst-port 53 Action : drop I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfacese= t #200. As interfaceset is an extct and not part of NLRI, ADDPATH will be required = in order to ensure propagation of both paths for the same NLRI. In case we move interfaceset as part of the NLRI, we do not have this ADDPA= TH requirement anymore, as we would have two different NLRIs Now Robert R. pointed me the need to control interAS advertisement, as inte= rfaceset have only a local significance. There=92s two cases : - #1 : There is an agreement between myAS and myUpstreamAS to use = some interface-set of myUpstreamAS and let myAS apply some filters on myUps= treamAS. - #2 : Such interfaceset information sharing is not authorized bet= ween both ASes, and only BGPFS rules with no interfaceset should be propaga= ted to myUpstreamAS. In #2, in case the interfaceset is extct, a BGP policy could be implemented= to deny BGP paths containing interfaceset towards myUpstreamAS. In case th= e interfaceset is part of NLRI, policy is still doable but requires some fi= ne grain NLRI matching in policy framework. To summarize : EXTCT approach : - Pros : o Permit easy filtering o Permit to use a common NLRI for multiple interfaceset if action is the = same - Cons : o But requires ADDPATH as soon as action is different for each interfaces= et NLRI approach : - Pros : o Do not require ADDPATH, may be permit an easier reading. Interfaceset i= s more a =93match-like=94 - Cons : o Filtering requires more advanced policy matching o Requires multiple NLRIs if we want to apply the same matching/actions t= o different interfaceset These pros/cons may not be exhaustive, so please comment and raise your poi= nt regarding the approach we need to take. Thanks a lot ! [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_D139DD32324D2hyojekimciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

Please see the reply inline:


Hi,<= /p>

 

Inline comments

 

From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com]
Sent: Thursday, March 26, 2015 16:19
To: LITKOWSKI Stephane SCE/IBNF; idr= @ietf.org
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D>= NLRI vs EXTCT

 

First, = I have a general comment. We cannot control the mapping of interface to gro= up id for all upstream routers/ASes. At FS NLRI originator, group id 1 iden= tifies all Internet customer interfaces, but we cannot assume the same at a far upstream router which belongs to a = different AS. 

[SLI] Agree, its simil= ar to BGP community, an upstream AS may authorize you to use its own interf= ace-group. But for sure group-id x in AS#1 may not exist or mean something = else in AS#2.

&n= bsp;

Regardi= ng this NLRI vs. EXTCT issue, as the interface group id is meaningful withi= n a limited set of routers/ASes, we should not add it to NLRI. If it is imp= lemented as EXTCT, we could consider a different AS border router might replace it into some other EXTCT which = is meaningful within its domain. 

[SLI]= That=92s a good point. But as pointed for interAS, you may be able to filt= er those NLRIs that apply only to your AS. It=92s technically possible, now= the question is : is it a good design ? may be not

In ca= se we keep EXTCT, we must point that using ADD-PATH is mandatory.

=  

Rober= t R. pointed me also that maybe using another AFI/SAFI and putting interfac= e-group in NLRI of this new AFI/SAFI will permit to keep a level of isolati= on with the DDoS use case which is typically interAS.

=  
[HK] I understand the point/concern about ADD-PATH becoming mandatory.=  

But, if we extend NLRI, we can filter out unwanted (or inapplicable) N= LRIs at border routers, but we cannot modify the NLRIs so that it has diffe= rent group id.
 

-Hyojeo= ng

&n= bsp;

&n= bsp;

From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Thursday, March 26, 2015 4:41 AM
To: "idr@ietf.org" <= ;idr@ietf.org>
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLR= I vs EXTCT

&n= bsp;

Hi IDR Folks,=

 =

During this week, I pres= ented the updates of the flowspec interfaceset draft.

We are currently thinkin= g on moving this interfaceset from extcommunity to NLRI and we require your= feedback on this. Why such change ?

 =

Consider that you may ap= ply filters with the same =93matching=94 but different actions to different= interface-groups. For example:

Rule#1=

Match : src-ip 10/8, dst= -port 53

Action : rate-limit 1000= 0

 =

Rule#2=

Match : src-ip 10/8, dst= -port 53

Action : drop=

 =

I would like to apply Ru= le#1 on interfaceset #100 and Rule#2 on interfaceset #200.

 =

As interfaceset is an ex= tct and not part of NLRI, ADDPATH will be required in order to ensure propa= gation of both paths for the same NLRI.

In case we move interfac= eset as part of the NLRI, we do not have this ADDPATH requirement anymore, = as we would have two different NLRIs

 =

 =

 =

Now Robert R. pointed me= the need to control interAS advertisement, as interfaceset have only a loc= al significance.

There=92s two cases :

-          #1 : There i= s an agreement between myAS and myUpstreamAS to use some interface-set of m= yUpstreamAS and let myAS apply some filters on myUpstreamAS.

-          #2 : Such in= terfaceset information sharing is not authorized between both ASes, and onl= y BGPFS rules with no interfaceset should be propagated to myUpstreamAS.

In #2, in case the inter= faceset is extct, a BGP policy could be implemented to deny BGP paths conta= ining interfaceset towards myUpstreamAS. In case the interfaceset is part o= f NLRI, policy is still doable but requires some fine grain NLRI matching in policy framework.

 =

To summarize :

EXTCT approach :

-          Pros :<= /o:p>

o   Permit easy = filtering

o   Permit to us= e a common NLRI for multiple interfaceset if action is the same<= /span>

-          Cons :<= /o:p>

o   But requires= ADDPATH as soon as action is different for each interfaceset

 =

NLRI approach :

-          Pros :<= /o:p>

o   Do not requi= re ADDPATH, may be permit an easier reading. Interfaceset is more a =93matc= h-like=94

-          Cons :<= /o:p>

o   Filtering re= quires more advanced policy matching

o   Requires mul= tiple NLRIs if we want to apply the same matching/actions to different inte= rfaceset

 =

 =

These pros/cons may not = be exhaustive, so please comment and raise your point regarding the approac= h we need to take.

 =

Thanks a lot !

 =

 =

3D"=

 

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 = 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_D139DD32324D2hyojekimciscocom_-- --_004_D139DD32324D2hyojekimciscocom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Thu, 26 Mar 2015 23:04:29 GMT"; modification-date="Thu, 26 Mar 2015 23:04:29 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_D139DD32324D2hyojekimciscocom_-- From nobody Fri Mar 27 10:07:36 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F98C1A884D for ; Fri, 27 Mar 2015 10:07:35 -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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqo_B4-iR5hG for ; Fri, 27 Mar 2015 10:07:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEADB1A882C for ; Fri, 27 Mar 2015 10:07:27 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 291E53B4191; Fri, 27 Mar 2015 18:07:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 0A291C8075; Fri, 27 Mar 2015 18:07:26 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Fri, 27 Mar 2015 18:07:26 +0100 From: To: "Hyojeong Kim (hyojekim)" , "idr@ietf.org" Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcwAQA00AAAdafGD//+KsgP/+sAEQ Date: Fri, 27 Mar 2015 17:07:25 +0000 Message-ID: <32325_1427476046_55158E4E_32325_13510_1_9E32478DFA9976438E7A22F69B08FF921662C3B3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <2641_1427410446_55148E0E_2641_15689_1_9E32478DFA9976438E7A22F69B08FF921662BE12@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.27.160619 Archived-At: Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 17:07:35 -0000 --_004_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [HK] I understand the point/concern about ADD-PATH becoming mandatory. But, if we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs = at border routers, but we cannot modify the NLRIs so that it has different = group id. [SLI] I definitely agree. From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com] Sent: Thursday, March 26, 2015 18:04 To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT Hi, Please see the reply inline: From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 3:54 PM To: Hyojeong Kim >, "idr@ietf= .org" > Subject: RE: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT Hi, Inline comments From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com] Sent: Thursday, March 26, 2015 16:19 To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs E= XTCT First, I have a general comment. We cannot control the mapping of interface= to group id for all upstream routers/ASes. At FS NLRI originator, group id= 1 identifies all Internet customer interfaces, but we cannot assume the sa= me at a far upstream router which belongs to a different AS. [SLI] Agree, its similar to BGP community, an upstream AS may authorize you= to use its own interface-group. But for sure group-id x in AS#1 may not ex= ist or mean something else in AS#2. Regarding this NLRI vs. EXTCT issue, as the interface group id is meaningfu= l within a limited set of routers/ASes, we should not add it to NLRI. If it= is implemented as EXTCT, we could consider a different AS border router mi= ght replace it into some other EXTCT which is meaningful within its domain. [SLI] That's a good point. But as pointed for interAS, you may be able to f= ilter those NLRIs that apply only to your AS. It's technically possible, no= w the question is : is it a good design ? may be not In case we keep EXTCT, we must point that using ADD-PATH is mandatory. Robert R. pointed me also that maybe using another AFI/SAFI and putting int= erface-group in NLRI of this new AFI/SAFI will permit to keep a level of is= olation with the DDoS use case which is typically interAS. [HK] I understand the point/concern about ADD-PATH becoming mandatory. But, if we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs = at border routers, but we cannot modify the NLRIs so that it has different = group id. -Hyojeong From: "stephane.litkowski@orange.com"= > Date: Thursday, March 26, 2015 4:41 AM To: "idr@ietf.org" > Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLRI vs EXTCT Hi IDR Folks, During this week, I presented the updates of the flowspec interfaceset draf= t. We are currently thinking on moving this interfaceset from extcommunity to = NLRI and we require your feedback on this. Why such change ? Consider that you may apply filters with the same "matching" but different = actions to different interface-groups. For example: Rule#1 Match : src-ip 10/8, dst-port 53 Action : rate-limit 10000 Rule#2 Match : src-ip 10/8, dst-port 53 Action : drop I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfacese= t #200. As interfaceset is an extct and not part of NLRI, ADDPATH will be required = in order to ensure propagation of both paths for the same NLRI. In case we move interfaceset as part of the NLRI, we do not have this ADDPA= TH requirement anymore, as we would have two different NLRIs Now Robert R. pointed me the need to control interAS advertisement, as inte= rfaceset have only a local significance. There's two cases : - #1 : There is an agreement between myAS and myUpstreamAS to use = some interface-set of myUpstreamAS and let myAS apply some filters on myUps= treamAS. - #2 : Such interfaceset information sharing is not authorized bet= ween both ASes, and only BGPFS rules with no interfaceset should be propaga= ted to myUpstreamAS. In #2, in case the interfaceset is extct, a BGP policy could be implemented= to deny BGP paths containing interfaceset towards myUpstreamAS. In case th= e interfaceset is part of NLRI, policy is still doable but requires some fi= ne grain NLRI matching in policy framework. To summarize : EXTCT approach : - Pros : o Permit easy filtering o Permit to use a common NLRI for multiple interfaceset if action is the = same - Cons : o But requires ADDPATH as soon as action is different for each interfaces= et NLRI approach : - Pros : o Do not require ADDPATH, may be permit an easier reading. Interfaceset i= s more a "match-like" - Cons : o Filtering requires more advanced policy matching o Requires multiple NLRIs if we want to apply the same matching/actions t= o different interfaceset These pros/cons may not be exhaustive, so please comment and raise your poi= nt regarding the approach we need to take. Thanks a lot ! [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[HK] I = understand the point/concern about ADD-PATH becoming mandatory. <= /o:p>

But, if= we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs at bord= er routers, but we cannot modify the NLRIs so that it has different group i= d.

[SLI] I definitely agr= ee.

 

From: Hyojeong= Kim (hyojekim) [mailto:hyojekim@cisco.com]
Sent: Thursday, March 26, 2015 18:04
To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D>= NLRI vs EXTCT

 

&n= bsp;

Hi,

&n= bsp;

Please = see the reply inline:

&n= bsp;

From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Thursday, March 26, 2015 3:54 PM
To: Hyojeong Kim <hyojekim@= cisco.com>, "idr@ietf.org&q= uot; <idr@ietf.org>
Subject: RE: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D>= NLRI vs EXTCT

&n= bsp;

Hi,

 

Inline comments=

 

From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com]
Sent: Thursday, March 26, 2015 16:19
To: LITKOWSKI Stephane SCE/IBNF; idr= @ietf.org
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D>= NLRI vs EXTCT

 =

First, = I have a general comment. We cannot control the mapping of interface to gro= up id for all upstream routers/ASes. At FS NLRI originator, group id 1 iden= tifies all Internet customer interfaces, but we cannot assume the same at a far upstream router which belongs to a = different AS. 

[SLI] Agree, its simil= ar to BGP community, an upstream AS may authorize you to use its own interf= ace-group. But for sure group-id x in AS#1 may not exist or mean something = else in AS#2.

 <= /span>

Regardi= ng this NLRI vs. EXTCT issue, as the interface group id is meaningful withi= n a limited set of routers/ASes, we should not add it to NLRI. If it is imp= lemented as EXTCT, we could consider a different AS border router might replace it into some other EXTCT which = is meaningful within its domain. 

[SLI]= That’s a good point. But as pointed for interAS, you may be able to = filter those NLRIs that apply only to your AS. It’s technically possi= ble, now the question is : is it a good design ? may be not

In ca= se we keep EXTCT, we must point that using ADD-PATH is mandatory.

 = ;

Rober= t R. pointed me also that maybe using another AFI/SAFI and putting interfac= e-group in NLRI of this new AFI/SAFI will permit to keep a level of isolati= on with the DDoS use case which is typically interAS.

 = ;

[HK] I = understand the point/concern about ADD-PATH becoming mandatory. <= /o:p>

&n= bsp;

But, if= we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs at bord= er routers, but we cannot modify the NLRIs so that it has different group i= d.

 = ;

-Hyojeo= ng

 <= /span>

 <= /span>

From: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>
Date: Thursday, March 26, 2015 4:41 AM
To: "idr@ietf.org" <= ;idr@ietf.org>
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset =3D> NLR= I vs EXTCT

 <= /span>

Hi IDR Folks,=

 =

During this week, I pres= ented the updates of the flowspec interfaceset draft.

We are currently thinkin= g on moving this interfaceset from extcommunity to NLRI and we require your= feedback on this. Why such change ?

 =

Consider that you may ap= ply filters with the same “matching” but different actions to d= ifferent interface-groups. For example:

Rule#1=

Match : src-ip 10/8, dst= -port 53

Action : rate-limit 1000= 0

 =

Rule#2=

Match : src-ip 10/8, dst= -port 53

Action : drop=

 =

I would like to apply Ru= le#1 on interfaceset #100 and Rule#2 on interfaceset #200.

 =

As interfaceset is an ex= tct and not part of NLRI, ADDPATH will be required in order to ensure propa= gation of both paths for the same NLRI.

In case we move interfac= eset as part of the NLRI, we do not have this ADDPATH requirement anymore, = as we would have two different NLRIs

 =

 =

 =

Now Robert R. pointed me= the need to control interAS advertisement, as interfaceset have only a loc= al significance.

There’s two cases = :

-  &= nbsp;       #1 : There is an= agreement between myAS and myUpstreamAS to use some interface-set of myUps= treamAS and let myAS apply some filters on myUpstreamAS.<= /p>

-  &= nbsp;       #2 : Such interf= aceset information sharing is not authorized between both ASes, and only BG= PFS rules with no interfaceset should be propagated to myUpstreamAS.

In #2, in case the inter= faceset is extct, a BGP policy could be implemented to deny BGP paths conta= ining interfaceset towards myUpstreamAS. In case the interfaceset is part o= f NLRI, policy is still doable but requires some fine grain NLRI matching in policy framework.

 =

To summarize :

EXTCT approach :

-  &= nbsp;       Pros :

o   Permit easy filt= ering

o   Permit to use a = common NLRI for multiple interfaceset if action is the same

-  &= nbsp;       Cons :

o   But requires ADD= PATH as soon as action is different for each interfaceset=

 =

NLRI approach :

-  &= nbsp;       Pros :

o   Do not require A= DDPATH, may be permit an easier reading. Interfaceset is more a “matc= h-like”

-  &= nbsp;       Cons :

o   Filtering requir= es more advanced policy matching

o   Requires multipl= e NLRIs if we want to apply the same matching/actions to different interfac= eset

 =

 =

These pros/cons may not = be exhaustive, so please comment and raise your point regarding the approac= h we need to take.

 =

Thanks a lot !

 =

 =

3D"Orange

 

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Future Networks=

phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 = 

__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
__________________________________________=
___________________________________________________________________________=
____
 
Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Fri, 27 Mar 2015 17:07:24 GMT"; modification-date="Fri, 27 Mar 2015 17:07:24 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF921662C3B3OPEXCLILMA4corp_-- From nobody Tue Mar 31 03:22:27 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED851A8A94 for ; Tue, 31 Mar 2015 03:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCuM77_lEFZk for ; Tue, 31 Mar 2015 03:22:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84A31A8A9C for ; Tue, 31 Mar 2015 03:22:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5AE0832411D; Tue, 31 Mar 2015 12:22:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3EBD135C06C; Tue, 31 Mar 2015 12:22:18 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 12:22:18 +0200 From: To: "Jerome Durand (jerduran)" Thread-Topic: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost Thread-Index: AQHQZzXg9spUaUUeT0y0VZhzj0BroZ0t+waAgAhrikA= Date: Tue, 31 Mar 2015 10:22:17 +0000 Message-ID: <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> In-Reply-To: <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Cc: "idr@ietf.org" Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:22:26 -0000 Hi J=E9rome, all > From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com] > Sent: Wednes= day, March 25, 2015 9:32 PM >=20 > Hi Bruno, >=20 > Interesting there are some similarities to what I proposed here: > draft-jdurand-idr-next-hop-liveliness-00 You are right.=20 I had read your document and had considered chatting this with you, but the= n understood that you were now favoring a different approach (namely draft-= jdurand-auto-bfd). > Where I tried to describe how we could carry next-hop capability to > implement a host liveliness mechanism and solve the route-server black- > holing stuff we have been talking about lately. Having a kind of general > framework for any capability (ie. not just host liveliness) makes sense. Thanks. I clearly agree with you. =20 > But your proposal relies on a non transitive attribute and couldn't pass = the > route-server so I cannot adjust my proposal to fit in yours. ID. next-hop-capability _needs_ a non transitive attribute so this is not s= omething that I can accommodate. Can't the route-server be extended to support the capability? Looks like a = relatively small change (and if the Route Server is known to never change t= he next-hop, a (horrible) hack would be just a matter of recognizing the at= tribute to pass it unchanged. But I will deny having said this ;-) ) =20 > Anyway note that now I more or less stopped that work for the moment to > focus on a more automated solution as there were some challenges with BGP > (issues described in the draft). Also it seems that it was quite heavy fr= om a > processing/memory point of view to have new attributes per route. Note we > had the idea to use some kind of "magic route" in order to have the attri= bute > transported only once. Maybe to be investigated further. This is also > described in the draft. Thanks for the feedback. As of today, IMO carrying the attribute in each up= date is simpler and more flexible. Some NH capability may need this (and as= a matter of fact, the entropy label capability needs this). Thanks for the comments and feedback. /Bruno =20 > Thanks! >=20 > Jerome >=20 >=20 >=20 >=20 >=20 >=20 > Le 25 mars 2015 =E0 20:56, > a =E9crit : >=20 > > Hi David, > > > > Thanks for your comments. > > Please see inline. > > > >> From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, > >> March 24, 2015 4:30 PM > >> > >> Hi Bruno, Ilya, Robert, > >> Hi idr list, > >> > >> > >> the next-hop-capability draft currently seems to target using the new > >> nexthop capability on a per-advertisement level. Considering that > >> draft-idr-bgp-nh- cost adds a new SAFI to convey information about > >> nexthops, it seems natural to tranposrt the capability information in = that > place? > > > > That's a valid comment. > > > > 1) cost/benefit > > Avertising the next-hop-capability on a per update basis has indeed a c= ost > but also a benefit. > > In term of cost, the simplest next-hop-capability is 5 octets. Compared= to an > update in the range of 100-1000 octets, that's 5% to 0,5%. > > In term of benefit, this allow customizing the capability on a per > update/routes granularity if required, which may be a useful possibility = for > some capabilities. > > Engineering is about trade-off. IMO, the benefit, especially long term,= out > weight the fixe cost, which is small and will become smaller, in relative= term, > in the future (thanks to Moore's law). > > > > 2) deployability > > In addition, in term of deployability, a new attribute has no impact. = On the > other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires > reconfiguration and reboot of all BGP sessions. This is a much higher cos= t for > IBGP alone. For EBGP, this is simply not an option IMO. > > > > > > So, I agree that this is a valid option to consider, however I don't th= ink that > it's a better one. > > > >> (That would also remove the question of what behaviour should be when > >> you get different advertisements with the same nexthop, but with a > >> different nexthop capability attribute.) > > > > For a given route/NLRI, you use the next-hop capability attached to this > route. > > To rephrase, you do not consider next-hop capability that may have been > advertised in another update. > > I agree that this may not be crystal clear in the text, I will clarify = in the next > revision. > > > > Thanks again for your comments, > > Bruno > > > >> > >> > >> -David > > > > > ____________________________________________________________ > __________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > Idr mailing list > > Idr@ietf.org > > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 03:22:46 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537311A8AA6 for ; Tue, 31 Mar 2015 03:22:44 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHYYH28MvXSo for ; Tue, 31 Mar 2015 03:22:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5C71A8A94 for ; Tue, 31 Mar 2015 03:22:31 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id C66903B4322; Tue, 31 Mar 2015 12:22:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9F6B635C048; Tue, 31 Mar 2015 12:22:29 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 12:22:29 +0200 From: To: David Lamparter Thread-Topic: decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost Thread-Index: AQHQZz85SF6fofZKJU2JukfyUyESZp02Vyuw Date: Tue, 31 Mar 2015 10:22:28 +0000 Message-ID: <31245_1427797349_551A7565_31245_1418_1_53C29892C857584299CBF5D05346208A0EB817CF@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <20150325210404.GL612698@eidolon> In-Reply-To: <20150325210404.GL612698@eidolon> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Cc: idr wg , "ilya.varlashkin@easynet.com" , "robert@raszuk.net" Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:22:44 -0000 David, all > From: David Lamparter [mailto:equinox@diac24.net] > Sent: Wednesday, Marc= h 25, 2015 10:04 PM >=20 > On Wed, Mar 25, 2015 at 07:56:48PM +0000, bruno.decraene@orange.com > wrote: > > > From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, > > > March 24, 2015 4:30 PM the next-hop-capability draft currently seems > > > to target using the new nexthop capability on a per-advertisement > > > level. Considering that draft-idr-bgp-nh- cost adds a new SAFI to > > > convey information about nexthops, it seems natural to tranposrt the > capability information in that place? > > > > That's a valid comment. > > > > 1) cost/benefit > > Avertising the next-hop-capability on a per update basis has indeed a c= ost > but also a benefit. > > In term of cost, the simplest next-hop-capability is 5 octets. Compared= to an > update in the range of 100-1000 octets, that's 5% to 0,5%. > > In term of benefit, this allow customizing the capability on a per > update/routes granularity if required, which may be a useful possibility = for > some capabilities. >=20 > Sure, the attribute is smaller. But how many neighbors are there? How m= any > routes are there?=20 This is application specific. The first capability is applicable to MPLS routes, typically inter AS MPLS = routes, typically within an administrative domain. e.g. in the range of 1k = to 10k If your point is that BGP will not scale one additional attribute/ 10 bytes= per update, you could comment many more IDR related documents. (I will ref= rain from picking names to avoid trolling IDR ML) If your point is about the trade-off with regard to a different encoding (n= amely ID.bgp-nh-cost), I have already replied to that point. > What's the semantic / complexity impact of tying this to update processin= g? You mean, compared to other attribute? I'd say roughly the same as others (= I would even say on the low end side). Do you see an issue? > I assume the attribute is sent only once, on a randomly > picked update that has the "right" nexthop - what happens if that route is > withdrawn? What if the last route with nexthop X gets withdrawn? The attribute defines NH capabilities for the NLRI advertised in the update= . Hence, it's advertised in each UPDATE requiring the advertisement of a ca= pability. e.g. for the Entropy Label Capability, typically in each UPDATE c= arrying labels routes to Entropy Label capable routers loopback This may not be clear in -00. This will be clarified in -01. Thanks for the= comment. =20 > > Engineering is about trade-off. IMO, the benefit, especially long term,= out > weight the fixe cost, which is small and will become smaller, in relative= term, > in the future (thanks to Moore's law). > > > > 2) deployability > > In addition, in term of deployability, a new attribute has no impact. = On the > other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires > reconfiguration and reboot of all BGP sessions. This is a much higher cos= t for > IBGP alone. For EBGP, this is simply not an option IMO. >=20 > I don't think we should design "around" limitations. I think we should design based on reality, especially if deployment is the = goal. > Fix the limitation? In the meantime, the argument holds. =20 > > So, I agree that this is a valid option to consider, however I don't th= ink that > it's a better one. > > > > > (That would also remove the question of what behaviour should be > > > when you get different advertisements with the same nexthop, but > > > with a different nexthop capability attribute.) > > > > For a given route/NLRI, you use the next-hop capability attached to this > route. > > To rephrase, you do not consider next-hop capability that may have been > advertised in another update. > > I agree that this may not be crystal clear in the text, I will clarify = in the next > revision. >=20 > Er - I'd go as far as change the name then. It's not "next-hop capabilit= y", it's > "route's (including next-hop) capability".=20 Changing the name is a possibility. However, the key behavior is that such = capabilities are removed when the next-hop is changed. The current name ref= lects this behavior. > Most significantly, it won't be useful > in any context that is really nexthop. > The way you describe it, I can't feed information from this attribute int= o the > nexthop table. Meaning ietf-idr-bgp-nh-cost is not applicable? =20 > If there's a need to signal route 'flag bit' capabilities more efficientl= y than > adding an empty attribute - sure. But that's not "next-hop capabilities". Using ID.next-hop-capability, one may define a capability carrying flags. T= his has been considered in -00 but rejected to favor simplicity and to focu= s first discussions. This may be added in a subsequent version. Regarding the first capability (Entropy Label), following first discussion = after IDR meeting, it seems likely that the value will be used to advertise= the Readable Label Size Depth. Hence flag would not be applicable. Thanks, /Bruno >=20 > -David ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 05:34:43 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA591A911A for ; Tue, 31 Mar 2015 05:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kX3FbvuLMJF for ; Tue, 31 Mar 2015 05:34:38 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F711A9231 for ; Tue, 31 Mar 2015 05:34:38 -0700 (PDT) Received: by igcau2 with SMTP id au2so11355795igc.1 for ; Tue, 31 Mar 2015 05:34:38 -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=k6IXwWm9McXA6vSNcg7bk3ALP0LT3pPjCUlUXi0BYos=; b=bMuNSXj5a0ZxUssEh8sG2UR791QVqHtgKqKnWSbUxGqmQnawZdYrckcT9nyhWB/Gqs Yo4RZuRikkxmaVUbaHaeWzg4foXAGggRks8qBxYM4/ZEDt3m/rkUgJURWyqVpRHmK2fw lj/4nt53wJWz5FiEB/LU+lDAuzI4/Ekb4KwIDqc/oEBioUk/d2dvdpXZ4FJd+nS72F9R 6Cd/iRCnuxZdtLVwS55fagg2SEdi6KqC9GqvfNff22+RQoy5JKFrl8kCb3B+tpQ9WYwj DmhsCWW7BjhE9RTDOeWGfXxYH8LuHkuOe+IgFXpG15JKq0Ka7x/xthbzhu5rbiRqrXkV czaA== MIME-Version: 1.0 X-Received: by 10.50.66.141 with SMTP id f13mr3943829igt.9.1427805278177; Tue, 31 Mar 2015 05:34:38 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.66 with HTTP; Tue, 31 Mar 2015 05:34:38 -0700 (PDT) Received: by 10.107.137.66 with HTTP; Tue, 31 Mar 2015 05:34:38 -0700 (PDT) In-Reply-To: <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 07:34:38 -0500 X-Google-Sender-Auth: 8n3YQQrP5l59h6dQ4KQ7bXoROOg Message-ID: From: Robert Raszuk To: bruno.decraene@orange.com Content-Type: multipart/alternative; boundary=047d7bdc0dd26a12ca051294d27b Archived-At: Cc: idr wg Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 12:34:41 -0000 --047d7bdc0dd26a12ca051294d27b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno, Three small questions (to warm up :) - do you assume in practice next hop self on ingress border router towards your ibgp - how do you handle third party next hop behaviour - do you plan to modify the draft to use it with next hop new SAFI Many thx, R. On Mar 31, 2015 3:22 AM, wrote: > Hi J=C3=A9rome, all > > > From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com] > Sent: > Wednesday, March 25, 2015 9:32 PM > > > > Hi Bruno, > > > > Interesting there are some similarities to what I proposed here: > > draft-jdurand-idr-next-hop-liveliness-00 > > You are right. > I had read your document and had considered chatting this with you, but > then understood that you were now favoring a different approach (namely > draft-jdurand-auto-bfd). > > > > Where I tried to describe how we could carry next-hop capability to > > implement a host liveliness mechanism and solve the route-server black- > > holing stuff we have been talking about lately. Having a kind of genera= l > > framework for any capability (ie. not just host liveliness) makes sense= . > > Thanks. I clearly agree with you. > > > But your proposal relies on a non transitive attribute and couldn't pas= s > the > > route-server so I cannot adjust my proposal to fit in yours. > > ID. next-hop-capability _needs_ a non transitive attribute so this is not > something that I can accommodate. > Can't the route-server be extended to support the capability? Looks like = a > relatively small change (and if the Route Server is known to never change > the next-hop, a (horrible) hack would be just a matter of recognizing the > attribute to pass it unchanged. But I will deny having said this ;-) ) > > > Anyway note that now I more or less stopped that work for the moment to > > focus on a more automated solution as there were some challenges with B= GP > > (issues described in the draft). Also it seems that it was quite heavy > from a > > processing/memory point of view to have new attributes per route. Note = we > > had the idea to use some kind of "magic route" in order to have the > attribute > > transported only once. Maybe to be investigated further. This is also > > described in the draft. > > Thanks for the feedback. As of today, IMO carrying the attribute in each > update is simpler and more flexible. Some NH capability may need this (an= d > as a matter of fact, the entropy label capability needs this). > > Thanks for the comments and feedback. > /Bruno > > > > Thanks! > > > > Jerome > > > > > > > > > > > > > > Le 25 mars 2015 =C3=A0 20:56, > > a =C3=A9crit : > > > > > Hi David, > > > > > > Thanks for your comments. > > > Please see inline. > > > > > >> From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday, > > >> March 24, 2015 4:30 PM > > >> > > >> Hi Bruno, Ilya, Robert, > > >> Hi idr list, > > >> > > >> > > >> the next-hop-capability draft currently seems to target using the ne= w > > >> nexthop capability on a per-advertisement level. Considering that > > >> draft-idr-bgp-nh- cost adds a new SAFI to convey information about > > >> nexthops, it seems natural to tranposrt the capability information i= n > that > > place? > > > > > > That's a valid comment. > > > > > > 1) cost/benefit > > > Avertising the next-hop-capability on a per update basis has indeed a > cost > > but also a benefit. > > > In term of cost, the simplest next-hop-capability is 5 octets. > Compared to an > > update in the range of 100-1000 octets, that's 5% to 0,5%. > > > In term of benefit, this allow customizing the capability on a per > > update/routes granularity if required, which may be a useful possibilit= y > for > > some capabilities. > > > Engineering is about trade-off. IMO, the benefit, especially long > term, out > > weight the fixe cost, which is small and will become smaller, in > relative term, > > in the future (thanks to Moore's law). > > > > > > 2) deployability > > > In addition, in term of deployability, a new attribute has no impact. > On the > > other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires > > reconfiguration and reboot of all BGP sessions. This is a much higher > cost for > > IBGP alone. For EBGP, this is simply not an option IMO. > > > > > > > > > So, I agree that this is a valid option to consider, however I don't > think that > > it's a better one. > > > > > >> (That would also remove the question of what behaviour should be whe= n > > >> you get different advertisements with the same nexthop, but with a > > >> different nexthop capability attribute.) > > > > > > For a given route/NLRI, you use the next-hop capability attached to > this > > route. > > > To rephrase, you do not consider next-hop capability that may have be= en > > advertised in another update. > > > I agree that this may not be crystal clear in the text, I will clarif= y > in the next > > revision. > > > > > > Thanks again for your comments, > > > Bruno > > > > > >> > > >> > > >> -David > > > > > > > > ____________________________________________________________ > > __________ > > > ___________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > > exploites ou copies sans autorisation. Si vous avez recu ce message > > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les > > pieces jointes. Les messages electroniques etant susceptibles > d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou > > falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not = be > > distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender an= d > delete > > this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that have > been > > modified, changed or falsified. > > > Thank you. > > > > > > _______________________________________________ > > > Idr mailing list > > > Idr@ietf.org > > > https://www.ietf.org/mailman/listinfo/idr > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --047d7bdc0dd26a12ca051294d27b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bruno,

Three small questions (to warm up :)

- do you assume in practice next hop self on ingress border = router towards your ibgp

- how do you handle third party next hop behaviour

- do you plan to modify the draft to use it with next hop ne= w SAFI

Many thx,
R.

On Mar 31, 2015 3:22 AM, <bruno.decraene@orange.com> wrote:
Hi J=C3=A9rome, all

> From: Jerome Durand (jerduran) [mailto:jerduran@cisco.com] > Sent: Wednesday, March 25, 2015 9:32 PM=
>
> Hi Bruno,
>
> Interesting there are some similarities to what I proposed here:
> draft-jdurand-idr-next-hop-liveliness-00

You are right.
I had read your document and had considered chatting this with you, but the= n understood that you were now favoring a different approach (namely draft-= jdurand-auto-bfd).


> Where I tried to describe how we could carry next-hop capability to > implement a host liveliness mechanism and solve the route-server black= -
> holing stuff we have been talking about lately. Having a kind of gener= al
> framework for any capability (ie. not just host liveliness) makes sens= e.

Thanks. I clearly agree with you.

> But your proposal relies on a non transitive attribute and couldn'= t pass the
> route-server so I cannot adjust my proposal to fit in yours.

ID. next-hop-capability _needs_ a non transitive attribute so this is not s= omething that I can accommodate.
Can't the route-server be extended to support the capability? Looks lik= e a relatively small change (and if the Route Server is known to never chan= ge the next-hop, a (horrible) hack would be just a matter of recognizing th= e attribute to pass it unchanged. But I will deny having said this ;-) )
> Anyway note that now I more or less stopped that work for the moment t= o
> focus on a more automated solution as there were some challenges with = BGP
> (issues described in the draft). Also it seems that it was quite heavy= from a
> processing/memory point of view to have new attributes per route. Note= we
> had the idea to use some kind of "magic route" in order to h= ave the attribute
> transported only once. Maybe to be investigated further. This is also<= br> > described in the draft.

Thanks for the feedback. As of today, IMO carrying the attribute in each up= date is simpler and more flexible. Some NH capability may need this (and as= a matter of fact, the entropy label capability needs this).

Thanks for the comments and feedback.
/Bruno


> Thanks!
>
> Jerome
>
>
>
>
>
>
> Le 25 mars 2015 =C3=A0 20:56, <bruno.decraene@orange.com>
> <bruno.decraene@orange= .com> a =C3=A9crit :
>
> > Hi David,
> >
> > Thanks for your comments.
> > Please see inline.
> >
> >> From: David Lamparter [mailto:equinox@diac24.net] > Sent: Tuesday,
> >> March 24, 2015 4:30 PM
> >>
> >> Hi Bruno, Ilya, Robert,
> >> Hi idr list,
> >>
> >>
> >> the next-hop-capability draft currently seems to target using= the new
> >> nexthop capability on a per-advertisement level.=C2=A0 Consid= ering that
> >> draft-idr-bgp-nh- cost adds a new SAFI to convey information = about
> >> nexthops, it seems natural to tranposrt the capability inform= ation in that
> place?
> >
> > That's a valid comment.
> >
> > 1)=C2=A0 cost/benefit
> > Avertising the next-hop-capability on a per update basis has inde= ed a cost
> but also a benefit.
> > In term of cost, the simplest next-hop-capability is 5 octets. Co= mpared to an
> update in the range of 100-1000 octets, that's 5% to 0,5%.
> > In term of benefit, this allow customizing the capability on a pe= r
> update/routes granularity if required, which may be a useful possibili= ty for
> some capabilities.
> > Engineering is about trade-off. IMO, the benefit, especially long= term, out
> weight the fixe cost, which is small and will become smaller, in relat= ive term,
> in the future (thanks to Moore's law).
> >
> > 2) deployability
> > In addition, in term of deployability, a new attribute has no imp= act.=C2=A0 On the
> other hand draft-idr-bgp-nh-cost use a new AFI/SAIF which requires
> reconfiguration and reboot of all BGP sessions. This is a much higher = cost for
> IBGP alone. For EBGP, this is simply not an option IMO.
> >
> >
> > So, I agree that this is a valid option to consider, however I do= n't think that
> it's a better one.
> >
> >> (That would also remove the question of what behaviour should= be when
> >> you get different advertisements with the same nexthop, but w= ith a
> >> different nexthop capability attribute.)
> >
> > For a given route/NLRI, you use the next-hop capability attached = to this
> route.
> > To rephrase, you do not consider next-hop capability that may hav= e been
> advertised in another update.
> > I agree that this may not be crystal clear in the text, I will cl= arify in the next
> revision.
> >
> > Thanks again for your comments,
> > Bruno
> >
> >>
> >>
> >> -David
> >
> >
> ____________________________________________________________
> __________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des information= s
> > confidentielles ou privilegiees et ne doivent donc pas etre diffu= ses,
> > exploites ou copies sans autorisation. Si vous avez recu ce messa= ge
> > par erreur, veuillez le signaler a l'expediteur et le detruir= e ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles d'al= teration,
> Orange decline toute responsabilite si ce message a ete altere, deform= e ou
> falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should = not be
> distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sende= r and delete
> this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that = have been
> modified, changed or falsified.
> > Thank you.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--047d7bdc0dd26a12ca051294d27b-- From nobody Tue Mar 31 06:30:39 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05061ACD2A for ; Tue, 31 Mar 2015 06:30:38 -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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56uLwzt6ya2H for ; Tue, 31 Mar 2015 06:30:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BAF1ACD31 for ; Tue, 31 Mar 2015 06:30:33 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id B76B41B80E5; Tue, 31 Mar 2015 15:30:31 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 4CD1A1800D2; Tue, 31 Mar 2015 15:30:31 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 15:30:31 +0200 From: To: Robert Raszuk Thread-Topic: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost Thread-Index: AQHQa68PUmxQ4n8H1UqmT7iJqJVtdZ02iXig Date: Tue, 31 Mar 2015 13:30:30 +0000 Message-ID: <27737_1427808631_551AA177_27737_351_1_53C29892C857584299CBF5D05346208A0EB81D34@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20150324212935.GG612698@eidolon> <25308_1427313409_55131301_25308_9958_1_53C29892C857584299CBF5D05346208A0EB7BCF2@PEXCVZYM11.corporate.adroot.infra.ftgroup> <2FF01A48-5057-42C9-81D2-91B864F84E47@cisco.com> <31245_1427797338_551A755A_31245_1405_1_53C29892C857584299CBF5D05346208A0EB817C7@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0EB81D34PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Cc: idr wg Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 13:30:38 -0000 --_000_53C29892C857584299CBF5D05346208A0EB81D34PEXCVZYM11corpo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2Ugc2VlIGlubGluZWQuDQoNCkZyb206IHJyYXN6dWtAZ21haWwu Y29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVr IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDMxLCAyMDE1IDI6MzUgUE0NCg0KDQoNCkhpIEJydW5vLA0K DQpUaHJlZSBzbWFsbCBxdWVzdGlvbnMgKHRvIHdhcm0gdXAgOikNCg0KW0JydW5vXSBJIHdhcyB3 YWl0aW5nIGZvciB5b3VyIGVtYWlsIDstKQ0KDQotIGRvIHlvdSBhc3N1bWUgaW4gcHJhY3RpY2Ug bmV4dCBob3Agc2VsZiBvbiBpbmdyZXNzIGJvcmRlciByb3V0ZXIgdG93YXJkcyB5b3VyIGliZ3AN Cg0KW0JydW5vXSBObyBhc3N1bXB0aW9uLiBTaG91bGQgd29yayBmb3IgTmV4dC1Ib3Agc2VsZiAg YW5kIE5leHQtSG9wIHVuY2hhbmdlZC4NCg0KTW9yZSBzcGVjaWZpY2FsbHkNCg0KLSBmb3IgTmV4 dC1Ib3AgU2VsZiwgdGhlIE5leHQtSG9wIENhcGFiaWxpdHkgbXVzdCBiZSByZW1vdmVkLiBBIG5l dyBvbmUgbWF5IGJlIGF0dGFjaGVkLCB3aXRoIHdoYXRldmVyIHJlbGV2YW50IGluZm9ybWF0aW9u Lg0KDQotIGZvciBuZXh0LWhvcCB1bmNoYW5nZWQsIHRoZSBOZXh0LUhvcCBDYXBhYmlsaXR5IHNo b3VsZCBiZSBrZXB0DQoNCi0gaG93IGRvIHlvdSBoYW5kbGUgdGhpcmQgcGFydHkgbmV4dCBob3Ag YmVoYXZpb3VyDQoNCltCcnVub10gQXMgdGhlIE5leHQtSG9wIGlzIG5vdCBjaGFuZ2VkLCB0aGUg TmV4dC1Ib3AgQ2FwYWJpbGl0eSBpcyBub3QgY2hhbmdlZCwgaGVuY2UgcmVmbGVjdCB0aGUgY2Fw YWJpbGl0eSBvZiB0aGUgdGhpcmQgcGFydHkuDQoNCi0gZG8geW91IHBsYW4gdG8gbW9kaWZ5IHRo ZSBkcmFmdCB0byB1c2UgaXQgd2l0aCBuZXh0IGhvcCBuZXcgU0FGSQ0KDQpbQnJ1bm9dIFRoZSBO ZXh0LUhvcCBDYXBhYmlsaXR5IGlzIGEgQkdQIGF0dHJpYnV0ZSB3aGljaCBjYW4gYmUgYXR0YWNo ZWQgdG8gcm91dGVzIG9mIChhIHByaW9yaSkgYW55IEFGSS9TQUZJLiBUaGVyZWZvcmUgaXQgbWF5 IGEgcHJpb3JpIGJlIHVzZWQgd2l0aCB0aGUgbmV4dC1ob3AgU0FGSS4gVGhhdCBiZWluZyBzYWlk LCBpdOKAmXMgbm90IGNsZWFyIHRvIG1lIHdoYXQgSUQubmgtY29zdCBzZXRzIGluIHRoZSDigJxO ZXR3b3JrIEFkZHJlc3Mgb2YgTmV4dCBIb3DigJ0gZmllbGQgb2YgdGhlIE1QX1JFQUNIX05MUkkg YXR0cmlidXRlLiBpLmUuIGl04oCZcyBub3QgY2xlYXIgaWYgSUQubmgtY29zdCB1c2UgdGhlIEJH UCBOZXh0LUhvcCBmaWVsZC4gSSBndWVzcyBmaXJzdCBhY3Rpb24gd291bGQgYmUgdG8gY2xhcmlm eSB0aGlzIGluIElELm5oLWNvc3QuDQoNCkluIHRoZSBtZWFudGltZSwgdHJ5aW5nIHRvIHRoZW9y aXplDQoNCiAtIElmIHRoaXMgQkdQIE5leHQtSG9wIGlzIHNldCB0byB0aGUgTkVYVF9IT1AgZmll bGQgb2YgdGhlIG5oLWNvc3QgU0FGSSwgdGhlbiBpdCBsb29rcyBsaWtlIHRoZSBJRC5uZXh0LWhv cC1jYXBhYmlsaXR5IGNhbiBiZSBkaXJlY3RseSBhcHBsaWVkIHRvIG5oLWNvc3QgU0FGSQ0KDQot IE90aGVyd2lzZSwgc2hvcnQgYW5zd2VyIGlzIHRoYXQgSUQuIG5oLWNvc3QgbWF5IG5lZWQgdG8g ZGVmaW5lIGhvdyB0aGUgTmV4dC1Ib3AgQ2FwYWJpbGl0eSBpcyB1c2VkIGZvciB0aGlzIFNBRkku IE9uZSBzdWItb3B0aW9uIHdvdWxkIGJlIHRvIGFkdmVydGlzZSBhIHNpbmdsZSBOTFJJIChoZW5j ZSBuZXh0LWhvcCByb3V0ZSBwZXIgdXBkYXRlKS4gT3IgdG8gZXh0ZW5kIHRoZSBuaC1jb3N0IFNB RkkgTkxSSSB0byBhbHNvIGNhcnJ5IEJHUCBhdHRyaWJ1dGVzIHJlbGF0ZWQgdG8gdGhpcyBOTFJJ IChORVhULUhPUCnigKZJIHRydXN0IHlvdXIgY3JlYXRpdml0eS4NCg0KL0JydW5vDQoNCg0KDQpN YW55IHRoeCwNClIuDQpPbiBNYXIgMzEsIDIwMTUgMzoyMiBBTSwgPGJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIErD qXJvbWUsIGFsbA0KDQo+IEZyb206IEplcm9tZSBEdXJhbmQgKGplcmR1cmFuKSBbbWFpbHRvOmpl cmR1cmFuQGNpc2NvLmNvbTxtYWlsdG86amVyZHVyYW5AY2lzY28uY29tPl0gPiBTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDI1LCAyMDE1IDk6MzIgUE0NCj4NCj4gSGkgQnJ1bm8sDQo+DQo+IEludGVy ZXN0aW5nIHRoZXJlIGFyZSBzb21lIHNpbWlsYXJpdGllcyB0byB3aGF0IEkgcHJvcG9zZWQgaGVy ZToNCj4gZHJhZnQtamR1cmFuZC1pZHItbmV4dC1ob3AtbGl2ZWxpbmVzcy0wMA0KDQpZb3UgYXJl IHJpZ2h0Lg0KSSBoYWQgcmVhZCB5b3VyIGRvY3VtZW50IGFuZCBoYWQgY29uc2lkZXJlZCBjaGF0 dGluZyB0aGlzIHdpdGggeW91LCBidXQgdGhlbiB1bmRlcnN0b29kIHRoYXQgeW91IHdlcmUgbm93 IGZhdm9yaW5nIGEgZGlmZmVyZW50IGFwcHJvYWNoIChuYW1lbHkgZHJhZnQtamR1cmFuZC1hdXRv LWJmZCkuDQoNCg0KPiBXaGVyZSBJIHRyaWVkIHRvIGRlc2NyaWJlIGhvdyB3ZSBjb3VsZCBjYXJy eSBuZXh0LWhvcCBjYXBhYmlsaXR5IHRvDQo+IGltcGxlbWVudCBhIGhvc3QgbGl2ZWxpbmVzcyBt ZWNoYW5pc20gYW5kIHNvbHZlIHRoZSByb3V0ZS1zZXJ2ZXIgYmxhY2stDQo+IGhvbGluZyBzdHVm ZiB3ZSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dCBsYXRlbHkuIEhhdmluZyBhIGtpbmQgb2YgZ2Vu ZXJhbA0KPiBmcmFtZXdvcmsgZm9yIGFueSBjYXBhYmlsaXR5IChpZS4gbm90IGp1c3QgaG9zdCBs aXZlbGluZXNzKSBtYWtlcyBzZW5zZS4NCg0KVGhhbmtzLiBJIGNsZWFybHkgYWdyZWUgd2l0aCB5 b3UuDQoNCj4gQnV0IHlvdXIgcHJvcG9zYWwgcmVsaWVzIG9uIGEgbm9uIHRyYW5zaXRpdmUgYXR0 cmlidXRlIGFuZCBjb3VsZG4ndCBwYXNzIHRoZQ0KPiByb3V0ZS1zZXJ2ZXIgc28gSSBjYW5ub3Qg YWRqdXN0IG15IHByb3Bvc2FsIHRvIGZpdCBpbiB5b3Vycy4NCg0KSUQuIG5leHQtaG9wLWNhcGFi aWxpdHkgX25lZWRzXyBhIG5vbiB0cmFuc2l0aXZlIGF0dHJpYnV0ZSBzbyB0aGlzIGlzIG5vdCBz b21ldGhpbmcgdGhhdCBJIGNhbiBhY2NvbW1vZGF0ZS4NCkNhbid0IHRoZSByb3V0ZS1zZXJ2ZXIg YmUgZXh0ZW5kZWQgdG8gc3VwcG9ydCB0aGUgY2FwYWJpbGl0eT8gTG9va3MgbGlrZSBhIHJlbGF0 aXZlbHkgc21hbGwgY2hhbmdlIChhbmQgaWYgdGhlIFJvdXRlIFNlcnZlciBpcyBrbm93biB0byBu ZXZlciBjaGFuZ2UgdGhlIG5leHQtaG9wLCBhIChob3JyaWJsZSkgaGFjayB3b3VsZCBiZSBqdXN0 IGEgbWF0dGVyIG9mIHJlY29nbml6aW5nIHRoZSBhdHRyaWJ1dGUgdG8gcGFzcyBpdCB1bmNoYW5n ZWQuIEJ1dCBJIHdpbGwgZGVueSBoYXZpbmcgc2FpZCB0aGlzIDstKSApDQoNCj4gQW55d2F5IG5v dGUgdGhhdCBub3cgSSBtb3JlIG9yIGxlc3Mgc3RvcHBlZCB0aGF0IHdvcmsgZm9yIHRoZSBtb21l bnQgdG8NCj4gZm9jdXMgb24gYSBtb3JlIGF1dG9tYXRlZCBzb2x1dGlvbiBhcyB0aGVyZSB3ZXJl IHNvbWUgY2hhbGxlbmdlcyB3aXRoIEJHUA0KPiAoaXNzdWVzIGRlc2NyaWJlZCBpbiB0aGUgZHJh ZnQpLiBBbHNvIGl0IHNlZW1zIHRoYXQgaXQgd2FzIHF1aXRlIGhlYXZ5IGZyb20gYQ0KPiBwcm9j ZXNzaW5nL21lbW9yeSBwb2ludCBvZiB2aWV3IHRvIGhhdmUgbmV3IGF0dHJpYnV0ZXMgcGVyIHJv dXRlLiBOb3RlIHdlDQo+IGhhZCB0aGUgaWRlYSB0byB1c2Ugc29tZSBraW5kIG9mICJtYWdpYyBy b3V0ZSIgaW4gb3JkZXIgdG8gaGF2ZSB0aGUgYXR0cmlidXRlDQo+IHRyYW5zcG9ydGVkIG9ubHkg b25jZS4gTWF5YmUgdG8gYmUgaW52ZXN0aWdhdGVkIGZ1cnRoZXIuIFRoaXMgaXMgYWxzbw0KPiBk ZXNjcmliZWQgaW4gdGhlIGRyYWZ0Lg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjay4gQXMgb2Yg dG9kYXksIElNTyBjYXJyeWluZyB0aGUgYXR0cmlidXRlIGluIGVhY2ggdXBkYXRlIGlzIHNpbXBs ZXIgYW5kIG1vcmUgZmxleGlibGUuIFNvbWUgTkggY2FwYWJpbGl0eSBtYXkgbmVlZCB0aGlzIChh bmQgYXMgYSBtYXR0ZXIgb2YgZmFjdCwgdGhlIGVudHJvcHkgbGFiZWwgY2FwYWJpbGl0eSBuZWVk cyB0aGlzKS4NCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMgYW5kIGZlZWRiYWNrLg0KL0JydW5v DQoNCg0KPiBUaGFua3MhDQo+DQo+IEplcm9tZQ0KPg0KPg0KPg0KPg0KPg0KPg0KPiBMZSAyNSBt YXJzIDIwMTUgw6AgMjA6NTYsIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tPj4NCj4gPGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFp bHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+PiBhIMOpY3JpdCA6DQo+DQo+ID4gSGkgRGF2 aWQsDQo+ID4NCj4gPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQo+ID4gUGxlYXNlIHNlZSBp bmxpbmUuDQo+ID4NCj4gPj4gRnJvbTogRGF2aWQgTGFtcGFydGVyIFttYWlsdG86ZXF1aW5veEBk aWFjMjQubmV0PG1haWx0bzplcXVpbm94QGRpYWMyNC5uZXQ+XSA+IFNlbnQ6IFR1ZXNkYXksDQo+ ID4+IE1hcmNoIDI0LCAyMDE1IDQ6MzAgUE0NCj4gPj4NCj4gPj4gSGkgQnJ1bm8sIElseWEsIFJv YmVydCwNCj4gPj4gSGkgaWRyIGxpc3QsDQo+ID4+DQo+ID4+DQo+ID4+IHRoZSBuZXh0LWhvcC1j YXBhYmlsaXR5IGRyYWZ0IGN1cnJlbnRseSBzZWVtcyB0byB0YXJnZXQgdXNpbmcgdGhlIG5ldw0K PiA+PiBuZXh0aG9wIGNhcGFiaWxpdHkgb24gYSBwZXItYWR2ZXJ0aXNlbWVudCBsZXZlbC4gIENv bnNpZGVyaW5nIHRoYXQNCj4gPj4gZHJhZnQtaWRyLWJncC1uaC0gY29zdCBhZGRzIGEgbmV3IFNB RkkgdG8gY29udmV5IGluZm9ybWF0aW9uIGFib3V0DQo+ID4+IG5leHRob3BzLCBpdCBzZWVtcyBu YXR1cmFsIHRvIHRyYW5wb3NydCB0aGUgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBpbiB0aGF0DQo+ IHBsYWNlPw0KPiA+DQo+ID4gVGhhdCdzIGEgdmFsaWQgY29tbWVudC4NCj4gPg0KPiA+IDEpICBj b3N0L2JlbmVmaXQNCj4gPiBBdmVydGlzaW5nIHRoZSBuZXh0LWhvcC1jYXBhYmlsaXR5IG9uIGEg cGVyIHVwZGF0ZSBiYXNpcyBoYXMgaW5kZWVkIGEgY29zdA0KPiBidXQgYWxzbyBhIGJlbmVmaXQu DQo+ID4gSW4gdGVybSBvZiBjb3N0LCB0aGUgc2ltcGxlc3QgbmV4dC1ob3AtY2FwYWJpbGl0eSBp cyA1IG9jdGV0cy4gQ29tcGFyZWQgdG8gYW4NCj4gdXBkYXRlIGluIHRoZSByYW5nZSBvZiAxMDAt MTAwMCBvY3RldHMsIHRoYXQncyA1JSB0byAwLDUlLg0KPiA+IEluIHRlcm0gb2YgYmVuZWZpdCwg dGhpcyBhbGxvdyBjdXN0b21pemluZyB0aGUgY2FwYWJpbGl0eSBvbiBhIHBlcg0KPiB1cGRhdGUv cm91dGVzIGdyYW51bGFyaXR5IGlmIHJlcXVpcmVkLCB3aGljaCBtYXkgYmUgYSB1c2VmdWwgcG9z c2liaWxpdHkgZm9yDQo+IHNvbWUgY2FwYWJpbGl0aWVzLg0KPiA+IEVuZ2luZWVyaW5nIGlzIGFi b3V0IHRyYWRlLW9mZi4gSU1PLCB0aGUgYmVuZWZpdCwgZXNwZWNpYWxseSBsb25nIHRlcm0sIG91 dA0KPiB3ZWlnaHQgdGhlIGZpeGUgY29zdCwgd2hpY2ggaXMgc21hbGwgYW5kIHdpbGwgYmVjb21l IHNtYWxsZXIsIGluIHJlbGF0aXZlIHRlcm0sDQo+IGluIHRoZSBmdXR1cmUgKHRoYW5rcyB0byBN b29yZSdzIGxhdykuDQo+ID4NCj4gPiAyKSBkZXBsb3lhYmlsaXR5DQo+ID4gSW4gYWRkaXRpb24s IGluIHRlcm0gb2YgZGVwbG95YWJpbGl0eSwgYSBuZXcgYXR0cmlidXRlIGhhcyBubyBpbXBhY3Qu ICBPbiB0aGUNCj4gb3RoZXIgaGFuZCBkcmFmdC1pZHItYmdwLW5oLWNvc3QgdXNlIGEgbmV3IEFG SS9TQUlGIHdoaWNoIHJlcXVpcmVzDQo+IHJlY29uZmlndXJhdGlvbiBhbmQgcmVib290IG9mIGFs bCBCR1Agc2Vzc2lvbnMuIFRoaXMgaXMgYSBtdWNoIGhpZ2hlciBjb3N0IGZvcg0KPiBJQkdQIGFs b25lLiBGb3IgRUJHUCwgdGhpcyBpcyBzaW1wbHkgbm90IGFuIG9wdGlvbiBJTU8uDQo+ID4NCj4g Pg0KPiA+IFNvLCBJIGFncmVlIHRoYXQgdGhpcyBpcyBhIHZhbGlkIG9wdGlvbiB0byBjb25zaWRl ciwgaG93ZXZlciBJIGRvbid0IHRoaW5rIHRoYXQNCj4gaXQncyBhIGJldHRlciBvbmUuDQo+ID4N Cj4gPj4gKFRoYXQgd291bGQgYWxzbyByZW1vdmUgdGhlIHF1ZXN0aW9uIG9mIHdoYXQgYmVoYXZp b3VyIHNob3VsZCBiZSB3aGVuDQo+ID4+IHlvdSBnZXQgZGlmZmVyZW50IGFkdmVydGlzZW1lbnRz IHdpdGggdGhlIHNhbWUgbmV4dGhvcCwgYnV0IHdpdGggYQ0KPiA+PiBkaWZmZXJlbnQgbmV4dGhv cCBjYXBhYmlsaXR5IGF0dHJpYnV0ZS4pDQo+ID4NCj4gPiBGb3IgYSBnaXZlbiByb3V0ZS9OTFJJ LCB5b3UgdXNlIHRoZSBuZXh0LWhvcCBjYXBhYmlsaXR5IGF0dGFjaGVkIHRvIHRoaXMNCj4gcm91 dGUuDQo+ID4gVG8gcmVwaHJhc2UsIHlvdSBkbyBub3QgY29uc2lkZXIgbmV4dC1ob3AgY2FwYWJp bGl0eSB0aGF0IG1heSBoYXZlIGJlZW4NCj4gYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIHVwZGF0ZS4N Cj4gPiBJIGFncmVlIHRoYXQgdGhpcyBtYXkgbm90IGJlIGNyeXN0YWwgY2xlYXIgaW4gdGhlIHRl eHQsIEkgd2lsbCBjbGFyaWZ5IGluIHRoZSBuZXh0DQo+IHJldmlzaW9uLg0KPiA+DQo+ID4gVGhh bmtzIGFnYWluIGZvciB5b3VyIGNvbW1lbnRzLA0KPiA+IEJydW5vDQo+ID4NCj4gPj4NCj4gPj4N Cj4gPj4gLURhdmlkDQo+ID4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fXw0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+DQo+ID4gQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zDQo+ID4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+ID4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1 dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiA+IHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMNCj4gcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91DQo+IGZh bHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiA+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlDQo+IGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUNCj4gdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4g QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4NCj4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ IFRoYW5rIHlvdS4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gSWRyIG1haWxpbmcgbGlzdA0KPiA+IElkckBpZXRmLm9yZzxtYWls dG86SWRyQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkciBtYWlsaW5nIGxpc3QNCklk ckBpZXRmLm9yZzxtYWlsdG86SWRyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZHINCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_53C29892C857584299CBF5D05346208A0EB81D34PEXCVZYM11corpo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSBSb2JlcnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlBsZWFzZSBzZWUgaW5saW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnJhc3p1 a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Um9iZXJ0IFJhc3p1ayA8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMzEsIDIwMTUgMjoz NSBQTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHA+SGkgQnJ1bm8sPG86cD48L286cD48L3A+DQo8cD5UaHJlZSBzbWFsbCBx dWVzdGlvbnMgKHRvIHdhcm0gdXAgOik8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBJIHdhcyB3 YWl0aW5nIGZvciB5b3VyIGVtYWlsJm5ic3A7Oy0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ LSBkbyB5b3UgYXNzdW1lIGluIHByYWN0aWNlIG5leHQgaG9wIHNlbGYgb24gaW5ncmVzcyBib3Jk ZXIgcm91dGVyIHRvd2FyZHMgeW91ciBpYmdwDQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JydW5vXSBO byBhc3N1bXB0aW9uLiBTaG91bGQgd29yayBmb3IgTmV4dC1Ib3Agc2VsZiAmbmJzcDthbmQgTmV4 dC1Ib3AgdW5jaGFuZ2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TW9yZSBzcGVjaWZpY2Fs bHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0gZm9yIE5leHQtSG9wIFNlbGYsIHRoZSBOZXh0 LUhvcCBDYXBhYmlsaXR5IG11c3QgYmUgcmVtb3ZlZC4gQSBuZXcgb25lIG1heSBiZSBhdHRhY2hl ZCwgd2l0aCB3aGF0ZXZlciByZWxldmFudCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi0gZm9yIG5leHQtaG9wIHVuY2hhbmdlZCwgdGhlIE5leHQtSG9wIENhcGFiaWxpdHkg c2hvdWxkIGJlIGtlcHQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPi0gaG93IGRvIHlvdSBo YW5kbGUgdGhpcmQgcGFydHkgbmV4dCBob3AgYmVoYXZpb3VyPG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltC cnVub10gQXMgdGhlIE5leHQtSG9wIGlzIG5vdCBjaGFuZ2VkLCB0aGUgTmV4dC1Ib3AgQ2FwYWJp bGl0eSBpcyBub3QgY2hhbmdlZCwgaGVuY2UgcmVmbGVjdCB0aGUgY2FwYWJpbGl0eSBvZiB0aGUg dGhpcmQgcGFydHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+LSBkbyB5b3UgcGxhbiB0byBt b2RpZnkgdGhlIGRyYWZ0IHRvIHVzZSBpdCB3aXRoIG5leHQgaG9wIG5ldyBTQUZJIDxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5bQnJ1bm9dIFRoZSBOZXh0LUhvcCBDYXBhYmlsaXR5IGlzIGEgQkdQIGF0dHJp YnV0ZSB3aGljaCBjYW4gYmUgYXR0YWNoZWQgdG8gcm91dGVzIG9mIChhIHByaW9yaSkgYW55IEFG SS9TQUZJLiBUaGVyZWZvcmUgaXQgbWF5IGEgcHJpb3JpIGJlIHVzZWQgd2l0aCB0aGUgbmV4dC1o b3ANCiBTQUZJLiBUaGF0IGJlaW5nIHNhaWQsIGl04oCZcyBub3QgY2xlYXIgdG8gbWUgd2hhdCBJ RC5uaC1jb3N0IHNldHMgaW4gdGhlIOKAnE5ldHdvcmsgQWRkcmVzcyBvZiBOZXh0IEhvcOKAnSBm aWVsZCBvZiB0aGUgTVBfUkVBQ0hfTkxSSSBhdHRyaWJ1dGUuIGkuZS4gaXTigJlzIG5vdCBjbGVh ciBpZiBJRC5uaC1jb3N0IHVzZSB0aGUgQkdQIE5leHQtSG9wIGZpZWxkLiBJIGd1ZXNzIGZpcnN0 IGFjdGlvbiB3b3VsZCBiZSB0byBjbGFyaWZ5IHRoaXMgaW4gSUQubmgtY29zdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBtZWFudGltZSwgdHJ5aW5nIHRvIHRoZW9yaXplDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOy0gSWYgdGhpcyBCR1AgTmV4dC1Ib3AgaXMgc2V0 IHRvIHRoZSBORVhUX0hPUCBmaWVsZCBvZiB0aGUgbmgtY29zdCBTQUZJLCB0aGVuIGl0IGxvb2tz IGxpa2UgdGhlIElELm5leHQtaG9wLWNhcGFiaWxpdHkgY2FuIGJlIGRpcmVjdGx5IGFwcGxpZWQg dG8gbmgtY29zdCBTQUZJPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tIE90aGVyd2lzZSwgc2hv cnQgYW5zd2VyIGlzIHRoYXQgSUQuIG5oLWNvc3QgbWF5IG5lZWQgdG8gZGVmaW5lIGhvdyB0aGUg TmV4dC1Ib3AgQ2FwYWJpbGl0eSBpcyB1c2VkIGZvciB0aGlzIFNBRkkuIE9uZSBzdWItb3B0aW9u IHdvdWxkIGJlIHRvIGFkdmVydGlzZSBhIHNpbmdsZQ0KIE5MUkkgKGhlbmNlIG5leHQtaG9wIHJv dXRlIHBlciB1cGRhdGUpLiBPciB0byBleHRlbmQgdGhlIG5oLWNvc3QgU0FGSSBOTFJJIHRvIGFs c28gY2FycnkgQkdQIGF0dHJpYnV0ZXMgcmVsYXRlZCB0byB0aGlzIE5MUkkgKE5FWFQtSE9QKeKA pkkgdHJ1c3QgeW91ciBjcmVhdGl2aXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+L0JydW5v PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cD5NYW55IHRoeCw8YnI+DQpSLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1hciAzMSwgMjAxNSAzOjIyIEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIErDqXJvbWUsIGFs bDxicj4NCjxicj4NCiZndDsgRnJvbTogSmVyb21lIER1cmFuZCAoamVyZHVyYW4pIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmplcmR1cmFuQGNpc2NvLmNvbSI+amVyZHVyYW5AY2lzY28uY29tPC9h Pl0gJmd0OyBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI1LCAyMDE1IDk6MzIgUE08YnI+DQomZ3Q7 PGJyPg0KJmd0OyBIaSBCcnVubyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRlcmVzdGluZyB0aGVy ZSBhcmUgc29tZSBzaW1pbGFyaXRpZXMgdG8gd2hhdCBJIHByb3Bvc2VkIGhlcmU6PGJyPg0KJmd0 OyBkcmFmdC1qZHVyYW5kLWlkci1uZXh0LWhvcC1saXZlbGluZXNzLTAwPGJyPg0KPGJyPg0KWW91 IGFyZSByaWdodC48YnI+DQpJIGhhZCByZWFkIHlvdXIgZG9jdW1lbnQgYW5kIGhhZCBjb25zaWRl cmVkIGNoYXR0aW5nIHRoaXMgd2l0aCB5b3UsIGJ1dCB0aGVuIHVuZGVyc3Rvb2QgdGhhdCB5b3Ug d2VyZSBub3cgZmF2b3JpbmcgYSBkaWZmZXJlbnQgYXBwcm9hY2ggKG5hbWVseSBkcmFmdC1qZHVy YW5kLWF1dG8tYmZkKS48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IFdoZXJlIEkgdHJpZWQgdG8gZGVz Y3JpYmUgaG93IHdlIGNvdWxkIGNhcnJ5IG5leHQtaG9wIGNhcGFiaWxpdHkgdG88YnI+DQomZ3Q7 IGltcGxlbWVudCBhIGhvc3QgbGl2ZWxpbmVzcyBtZWNoYW5pc20gYW5kIHNvbHZlIHRoZSByb3V0 ZS1zZXJ2ZXIgYmxhY2stPGJyPg0KJmd0OyBob2xpbmcgc3R1ZmYgd2UgaGF2ZSBiZWVuIHRhbGtp bmcgYWJvdXQgbGF0ZWx5LiBIYXZpbmcgYSBraW5kIG9mIGdlbmVyYWw8YnI+DQomZ3Q7IGZyYW1l d29yayBmb3IgYW55IGNhcGFiaWxpdHkgKGllLiBub3QganVzdCBob3N0IGxpdmVsaW5lc3MpIG1h a2VzIHNlbnNlLjxicj4NCjxicj4NClRoYW5rcy4gSSBjbGVhcmx5IGFncmVlIHdpdGggeW91Ljxi cj4NCjxicj4NCiZndDsgQnV0IHlvdXIgcHJvcG9zYWwgcmVsaWVzIG9uIGEgbm9uIHRyYW5zaXRp dmUgYXR0cmlidXRlIGFuZCBjb3VsZG4ndCBwYXNzIHRoZTxicj4NCiZndDsgcm91dGUtc2VydmVy IHNvIEkgY2Fubm90IGFkanVzdCBteSBwcm9wb3NhbCB0byBmaXQgaW4geW91cnMuPGJyPg0KPGJy Pg0KSUQuIG5leHQtaG9wLWNhcGFiaWxpdHkgX25lZWRzXyBhIG5vbiB0cmFuc2l0aXZlIGF0dHJp YnV0ZSBzbyB0aGlzIGlzIG5vdCBzb21ldGhpbmcgdGhhdCBJIGNhbiBhY2NvbW1vZGF0ZS48YnI+ DQpDYW4ndCB0aGUgcm91dGUtc2VydmVyIGJlIGV4dGVuZGVkIHRvIHN1cHBvcnQgdGhlIGNhcGFi aWxpdHk/IExvb2tzIGxpa2UgYSByZWxhdGl2ZWx5IHNtYWxsIGNoYW5nZSAoYW5kIGlmIHRoZSBS b3V0ZSBTZXJ2ZXIgaXMga25vd24gdG8gbmV2ZXIgY2hhbmdlIHRoZSBuZXh0LWhvcCwgYSAoaG9y cmlibGUpIGhhY2sgd291bGQgYmUganVzdCBhIG1hdHRlciBvZiByZWNvZ25pemluZyB0aGUgYXR0 cmlidXRlIHRvIHBhc3MgaXQgdW5jaGFuZ2VkLiBCdXQNCiBJIHdpbGwgZGVueSBoYXZpbmcgc2Fp ZCB0aGlzIDstKSApPGJyPg0KPGJyPg0KJmd0OyBBbnl3YXkgbm90ZSB0aGF0IG5vdyBJIG1vcmUg b3IgbGVzcyBzdG9wcGVkIHRoYXQgd29yayBmb3IgdGhlIG1vbWVudCB0bzxicj4NCiZndDsgZm9j dXMgb24gYSBtb3JlIGF1dG9tYXRlZCBzb2x1dGlvbiBhcyB0aGVyZSB3ZXJlIHNvbWUgY2hhbGxl bmdlcyB3aXRoIEJHUDxicj4NCiZndDsgKGlzc3VlcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0KS4g QWxzbyBpdCBzZWVtcyB0aGF0IGl0IHdhcyBxdWl0ZSBoZWF2eSBmcm9tIGE8YnI+DQomZ3Q7IHBy b2Nlc3NpbmcvbWVtb3J5IHBvaW50IG9mIHZpZXcgdG8gaGF2ZSBuZXcgYXR0cmlidXRlcyBwZXIg cm91dGUuIE5vdGUgd2U8YnI+DQomZ3Q7IGhhZCB0aGUgaWRlYSB0byB1c2Ugc29tZSBraW5kIG9m ICZxdW90O21hZ2ljIHJvdXRlJnF1b3Q7IGluIG9yZGVyIHRvIGhhdmUgdGhlIGF0dHJpYnV0ZTxi cj4NCiZndDsgdHJhbnNwb3J0ZWQgb25seSBvbmNlLiBNYXliZSB0byBiZSBpbnZlc3RpZ2F0ZWQg ZnVydGhlci4gVGhpcyBpcyBhbHNvPGJyPg0KJmd0OyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0Ljxi cj4NCjxicj4NClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBBcyBvZiB0b2RheSwgSU1PIGNhcnJ5 aW5nIHRoZSBhdHRyaWJ1dGUgaW4gZWFjaCB1cGRhdGUgaXMgc2ltcGxlciBhbmQgbW9yZSBmbGV4 aWJsZS4gU29tZSBOSCBjYXBhYmlsaXR5IG1heSBuZWVkIHRoaXMgKGFuZCBhcyBhIG1hdHRlciBv ZiBmYWN0LCB0aGUgZW50cm9weSBsYWJlbCBjYXBhYmlsaXR5IG5lZWRzIHRoaXMpLjxicj4NCjxi cj4NClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIGFuZCBmZWVkYmFjay48YnI+DQovQnJ1bm88YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKZXJvbWU8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IExlIDI1IG1hcnMgMjAxNSDDoCAyMDo1NiwgJmx0OzxhIGhyZWY9Im1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPiZn dDs8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IEhpIERhdmlkLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBU aGFua3MgZm9yIHlvdXIgY29tbWVudHMuPGJyPg0KJmd0OyAmZ3Q7IFBsZWFzZSBzZWUgaW5saW5l Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgRnJvbTogRGF2aWQgTGFtcGFydGVy IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVxdWlub3hAZGlhYzI0Lm5ldCI+ZXF1aW5veEBkaWFj MjQubmV0PC9hPl0gJmd0OyBTZW50OiBUdWVzZGF5LDxicj4NCiZndDsgJmd0OyZndDsgTWFyY2gg MjQsIDIwMTUgNDozMCBQTTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEhp IEJydW5vLCBJbHlhLCBSb2JlcnQsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIaSBpZHIgbGlzdCw8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgdGhl IG5leHQtaG9wLWNhcGFiaWxpdHkgZHJhZnQgY3VycmVudGx5IHNlZW1zIHRvIHRhcmdldCB1c2lu ZyB0aGUgbmV3PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBuZXh0aG9wIGNhcGFiaWxpdHkgb24gYSBwZXIt YWR2ZXJ0aXNlbWVudCBsZXZlbC4mbmJzcDsgQ29uc2lkZXJpbmcgdGhhdDxicj4NCiZndDsgJmd0 OyZndDsgZHJhZnQtaWRyLWJncC1uaC0gY29zdCBhZGRzIGEgbmV3IFNBRkkgdG8gY29udmV5IGlu Zm9ybWF0aW9uIGFib3V0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBuZXh0aG9wcywgaXQgc2VlbXMgbmF0 dXJhbCB0byB0cmFucG9zcnQgdGhlIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gaW4gdGhhdDxicj4N CiZndDsgcGxhY2U/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYXQncyBhIHZhbGlk IGNvbW1lbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEpJm5ic3A7IGNvc3QvYmVu ZWZpdDxicj4NCiZndDsgJmd0OyBBdmVydGlzaW5nIHRoZSBuZXh0LWhvcC1jYXBhYmlsaXR5IG9u IGEgcGVyIHVwZGF0ZSBiYXNpcyBoYXMgaW5kZWVkIGEgY29zdDxicj4NCiZndDsgYnV0IGFsc28g YSBiZW5lZml0Ljxicj4NCiZndDsgJmd0OyBJbiB0ZXJtIG9mIGNvc3QsIHRoZSBzaW1wbGVzdCBu ZXh0LWhvcC1jYXBhYmlsaXR5IGlzIDUgb2N0ZXRzLiBDb21wYXJlZCB0byBhbjxicj4NCiZndDsg dXBkYXRlIGluIHRoZSByYW5nZSBvZiAxMDAtMTAwMCBvY3RldHMsIHRoYXQncyA1JSB0byAwLDUl Ljxicj4NCiZndDsgJmd0OyBJbiB0ZXJtIG9mIGJlbmVmaXQsIHRoaXMgYWxsb3cgY3VzdG9taXpp bmcgdGhlIGNhcGFiaWxpdHkgb24gYSBwZXI8YnI+DQomZ3Q7IHVwZGF0ZS9yb3V0ZXMgZ3JhbnVs YXJpdHkgaWYgcmVxdWlyZWQsIHdoaWNoIG1heSBiZSBhIHVzZWZ1bCBwb3NzaWJpbGl0eSBmb3I8 YnI+DQomZ3Q7IHNvbWUgY2FwYWJpbGl0aWVzLjxicj4NCiZndDsgJmd0OyBFbmdpbmVlcmluZyBp cyBhYm91dCB0cmFkZS1vZmYuIElNTywgdGhlIGJlbmVmaXQsIGVzcGVjaWFsbHkgbG9uZyB0ZXJt LCBvdXQ8YnI+DQomZ3Q7IHdlaWdodCB0aGUgZml4ZSBjb3N0LCB3aGljaCBpcyBzbWFsbCBhbmQg d2lsbCBiZWNvbWUgc21hbGxlciwgaW4gcmVsYXRpdmUgdGVybSw8YnI+DQomZ3Q7IGluIHRoZSBm dXR1cmUgKHRoYW5rcyB0byBNb29yZSdzIGxhdykuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IDIpIGRlcGxveWFiaWxpdHk8YnI+DQomZ3Q7ICZndDsgSW4gYWRkaXRpb24sIGluIHRlcm0g b2YgZGVwbG95YWJpbGl0eSwgYSBuZXcgYXR0cmlidXRlIGhhcyBubyBpbXBhY3QuJm5ic3A7IE9u IHRoZTxicj4NCiZndDsgb3RoZXIgaGFuZCBkcmFmdC1pZHItYmdwLW5oLWNvc3QgdXNlIGEgbmV3 IEFGSS9TQUlGIHdoaWNoIHJlcXVpcmVzPGJyPg0KJmd0OyByZWNvbmZpZ3VyYXRpb24gYW5kIHJl Ym9vdCBvZiBhbGwgQkdQIHNlc3Npb25zLiBUaGlzIGlzIGEgbXVjaCBoaWdoZXIgY29zdCBmb3I8 YnI+DQomZ3Q7IElCR1AgYWxvbmUuIEZvciBFQkdQLCB0aGlzIGlzIHNpbXBseSBub3QgYW4gb3B0 aW9uIElNTy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgU28s IEkgYWdyZWUgdGhhdCB0aGlzIGlzIGEgdmFsaWQgb3B0aW9uIHRvIGNvbnNpZGVyLCBob3dldmVy IEkgZG9uJ3QgdGhpbmsgdGhhdDxicj4NCiZndDsgaXQncyBhIGJldHRlciBvbmUuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAoVGhhdCB3b3VsZCBhbHNvIHJlbW92ZSB0aGUgcXVl c3Rpb24gb2Ygd2hhdCBiZWhhdmlvdXIgc2hvdWxkIGJlIHdoZW48YnI+DQomZ3Q7ICZndDsmZ3Q7 IHlvdSBnZXQgZGlmZmVyZW50IGFkdmVydGlzZW1lbnRzIHdpdGggdGhlIHNhbWUgbmV4dGhvcCwg YnV0IHdpdGggYTxicj4NCiZndDsgJmd0OyZndDsgZGlmZmVyZW50IG5leHRob3AgY2FwYWJpbGl0 eSBhdHRyaWJ1dGUuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBGb3IgYSBnaXZlbiBy b3V0ZS9OTFJJLCB5b3UgdXNlIHRoZSBuZXh0LWhvcCBjYXBhYmlsaXR5IGF0dGFjaGVkIHRvIHRo aXM8YnI+DQomZ3Q7IHJvdXRlLjxicj4NCiZndDsgJmd0OyBUbyByZXBocmFzZSwgeW91IGRvIG5v dCBjb25zaWRlciBuZXh0LWhvcCBjYXBhYmlsaXR5IHRoYXQgbWF5IGhhdmUgYmVlbjxicj4NCiZn dDsgYWR2ZXJ0aXNlZCBpbiBhbm90aGVyIHVwZGF0ZS48YnI+DQomZ3Q7ICZndDsgSSBhZ3JlZSB0 aGF0IHRoaXMgbWF5IG5vdCBiZSBjcnlzdGFsIGNsZWFyIGluIHRoZSB0ZXh0LCBJIHdpbGwgY2xh cmlmeSBpbiB0aGUgbmV4dDxicj4NCiZndDsgcmV2aXNpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFRoYW5rcyBhZ2FpbiBmb3IgeW91ciBjb21tZW50cyw8YnI+DQomZ3Q7ICZndDsg QnJ1bm88YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgLURhdmlkPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7IF9fX19fX19fX188YnI+DQomZ3Q7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9uczxicj4NCiZndDsgJmd0OyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcyw8 YnI+DQomZ3Q7ICZndDsgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZTxicj4NCiZndDsgJmd0OyBwYXIgZXJyZXVyLCB2ZXVp bGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUg bGVzPGJyPg0KJmd0OyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8YnI+DQomZ3Q7IE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91PGJyPg0KJmd0OyBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvcjxicj4NCiZndDsgJmd0OyBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZTxicj4NCiZndDsgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQomZ3Q7ICZndDsg SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGU8YnI+DQomZ3Q7IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLjxicj4NCiZndDsgJmd0OyBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbjxicj4NCiZndDsgbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NCiZndDsgJmd0OyBUaGFuayB5b3UuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IElkciBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 ICZndDsgPGEgaHJlZj0ibWFpbHRvOklkckBpZXRmLm9yZyI+SWRyQGlldGYub3JnPC9hPjxicj4N CiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lkciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWRyPC9hPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxi cj4NCjxicj4NClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4NClRoYW5rIHlvdS48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklkciBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWRyQGlldGYub3JnIj5JZHJAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pZHIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53C29892C857584299CBF5D05346208A0EB81D34PEXCVZYM11corpo_-- From nobody Tue Mar 31 13:06:13 2015 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEF51ACE8D for ; Tue, 31 Mar 2015 13:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkYXPqpgfBZ5 for ; Tue, 31 Mar 2015 13:06:10 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 956901ACE86 for ; Tue, 31 Mar 2015 13:06:10 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,503,1422939600"; d="scan'208,217";a="278420708" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Mar 2015 15:58:39 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 31 Mar 2015 16:06:07 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" Date: Tue, 31 Mar 2015 16:06:06 -0400 Thread-Topic: [Idr] AD review and progression of draft-ietf-idr-as-migration-03 Thread-Index: AdBr7h8NrZCPth7vQ42yacPuv59D9g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1406DA94BB35wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf. org" , "draft-ietf-idr-as-migration@tools.ietf.org" Subject: Re: [Idr] AD review and progression of draft-ietf-idr-as-migration-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 20:06:12 -0000 --_000_D1406DA94BB35wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29pbmcgdGhyb3VnaCBzb21lIG9mIHRoZSBzcGVjaWZpYyBpdGVtcyByYWlzZWQgYmVsb3csIGFu ZCB3YW50ZWQgdG8gcmVzcG9uZCB0byBhIGNvdXBsZSwgc25pcHBlZCB3aGVyZSBhcHByb3ByaWF0 ZS4NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpGcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSki IDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0KRGF0ZTogVGh1 cnNkYXksIEZlYnJ1YXJ5IDE5LCAyMDE1IGF0IDk6NTggQU0NClRvOiAiR2VvcmdlLCBXZXMiIDx3 ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29t Pj4NCkNjOiBJZHIgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4sICJkcmFmdC1p ZXRmLWlkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaWRy LWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZz4iIDxkcmFmdC1pZXRmLWlkci1hcy1taWdyYXRp b25AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtaWRyLWFzLW1pZ3JhdGlvbkB0b29s cy5pZXRmLm9yZz4+LCBBbGlhIEF0bGFzIDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxh c0BnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtJZHJdIEFEIHJldmlldyBhbmQgcHJvZ3Jlc3Np b24gb2YgZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uLTAzDQoNCg0KICogICBUaGUgdXNlIGNh c2UgRmlnIDEgYW5kMiwgc2hvdyBjdXN0b21lcnMgQyBhbmQgRC4uYnV0IGxhdGVyLCB3aGVuIGV4 cGxhaW5pbmcgdGhlIGZlYXR1cmVzLCBDRS1BIGFuZCBDRS1CIGFyZSB1c2VkIGluc3RlYWQuICBU byBtYWtlIGl0IGVhc2llciB0byBmb2xsb3cgdGhlIHNhbWUgbmFtZXMgd291bGQgYmUgbmljZS4N Cg0KV0ddIHRoZSDigJNBIGFuZCDigJNCIGRlc2lnbmF0b3JzIHdlcmUgc2V0IHRoZSB3YXkgdGhl eSB3ZXJlIGFmdGVyIFRob21hcyBNb3JpbidzIHJldmlldywgd2l0aCB0aGUgaWRlYSB0aGF0IHRo ZXkgY29pbmNpZGUgd2l0aCB0aGUgSVNQIHRoYXQgdGhleSdyZSBwYXJ0IG9mIChQRS9DRSBBIGFy ZSBpbiBJU1AgQSBwcmUtbWlncmF0aW9uLCBQRS9DRS1CIGFyZSBpbiBJU1AgQiBwcmUtbWlncmF0 aW9uKS4gVGhpcyBpcyBhbGwgcHJldHR5IG11Y2ggYSBwZXJzb25hbCBwcmVmZXJlbmNlICh3aGF0 IG1ha2VzIHRoZSBtb3N0IHNlbnNlIGZvciB5b3UpLCBzbyBJJ20gbm90IGluY2xpbmVkIHRvIGNo YW5nZSBpdCBhZ2FpbiB1bmxlc3Mgc29tZW9uZSBjb21lcyB1cCB3aXRoIHNvbWV0aGluZyB0aGF0 IGlzIG1vcmUgdW5pdmVyc2FsbHkgb2J2aW91cy4NCg0KICogICBJbiAzLjMgKGxhc3QgcGFyYWdy YXBoKSB0aGUgYXV0aG9ycyB0YWxrIGFib3V0IHRoZSBDTEkgaW1wbGVtZW50YXRpb24uLiAgQXMg dGhleSB3cm90ZTog4oCcLi5jb21tYW5kIHN5bnRheCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRh aWwgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLiAgU3RheSBvdXQgb2YgaXQu DQoNCldHXSBJIGRpc2FncmVlLiBUaGlzIG1heSBiZSByZXNvbHZlZCBpbiB0aGUgd2F5IHRoYXQg d2UgcmVzdHJ1Y3R1cmUgdGhlIGRvY3VtZW50IHRvIHJlZHVjZSB0aGUgdmVuZG9yLXNwZWNpZmlj IHN0dWZmLCBidXQgYXMgYW4gb3BlcmF0b3Igd2hvIGFjdHVhbGx5IG5lZWRzIHRvIGJlIGFibGUg dG8gdXNlIHRoaXMgaW1wbGVtZW50YXRpb24sIEkgdGhpbmsgdGhhdCB0aGUgZ3VpZGFuY2UgaW4g dGhhdCBzZWN0aW9uIGlzIHVzZWZ1bCDigJMgaWYgeW91J3JlIGdvaW5nIHRvIGludGVncmF0ZSB0 aGUgY29tbWFuZHMgdG9nZXRoZXIsIGdpdmUgbWUgdGhlIGZsZXhpYmlsaXR5IHRvIGNvbnRyb2wg aG93IGl0J3MgYXBwbGllZCB0aHJvdWdoIHNvbWUgc3dpdGNoZXMsIG9yIGdpdmUgbWUgc2VwYXJh dGUgY29tbWFuZHMuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0K --_000_D1406DA94BB35wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkdvaW5nIHRocm91Z2ggc29tZSBvZiB0aGUgc3BlY2lmaWMgaXRlbXMgcmFpc2VkIGJlbG93 LCBhbmQgd2FudGVkIHRvIHJlc3BvbmQgdG8gYSBjb3VwbGUsIHNuaXBwZWQgd2hlcmUgYXBwcm9w cmlhdGUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U aHVyc2RheSwgRmVicnVhcnkgMTksIDIwMTUgYXQgOTo1OCBBTTxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90O0dlb3JnZSwgV2VzJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbSI+d2VzbGV5Lmdlb3JnZUB0 d2NhYmxlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNj OiA8L3NwYW4+SWRyICZsdDs8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5v cmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaWRyLWFzLW1pZ3Jh dGlvbkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uQHRvb2xzLmll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtaWRyLWFzLW1p Z3JhdGlvbkB0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pZHItYXMtbWlncmF0aW9uQHRvb2xz LmlldGYub3JnPC9hPiZndDssDQogQWxpYSBBdGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRs YXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0lkcl0gQUQgcmV2aWV3IGFu ZCBwcm9ncmVzc2lvbiBvZiBkcmFmdC1pZXRmLWlkci1hcy1taWdyYXRpb24tMDM8YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyI+DQo8dWw+DQo8bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5UaGUg dXNlIGNhc2UgRmlnIDEgYW5kMiwgc2hvdyBjdXN0b21lcnMgQyBhbmQgRC4uYnV0IGxhdGVyLCB3 aGVuIGV4cGxhaW5pbmcgdGhlIGZlYXR1cmVzLCBDRS1BIGFuZCBDRS1CIGFyZSB1c2VkIGluc3Rl YWQuICZuYnNwO1RvIG1ha2UgaXQgZWFzaWVyIHRvJm5ic3A7Zm9sbG93IHRoZSBzYW1lIG5hbWVz IHdvdWxkIGJlIG5pY2UuPC9mb250PjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5X R10gdGhlIOKAk0EgYW5kIOKAk0IgZGVzaWduYXRvcnMgd2VyZSBzZXQgdGhlIHdheSB0aGV5IHdl cmUgYWZ0ZXIgVGhvbWFzIE1vcmluJ3MgcmV2aWV3LCB3aXRoIHRoZSBpZGVhIHRoYXQgdGhleSBj b2luY2lkZSB3aXRoIHRoZSBJU1AgdGhhdCB0aGV5J3JlIHBhcnQgb2YgKFBFL0NFIEEgYXJlIGlu IElTUCBBIHByZS1taWdyYXRpb24sIFBFL0NFLUIgYXJlIGluIElTUCBCIHByZS1taWdyYXRpb24p LiBUaGlzIGlzIGFsbCBwcmV0dHkgbXVjaCBhDQogcGVyc29uYWwgcHJlZmVyZW5jZSAod2hhdCBt YWtlcyB0aGUgbW9zdCBzZW5zZSBmb3IgeW91KSwgc28gSSdtIG5vdCBpbmNsaW5lZCB0byBjaGFu Z2UgaXQgYWdhaW4gdW5sZXNzIHNvbWVvbmUgY29tZXMgdXAgd2l0aCBzb21ldGhpbmcgdGhhdCBp cyBtb3JlIHVuaXZlcnNhbGx5IG9idmlvdXMuJm5ic3A7PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS Q19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjx1bD4NCjxsaT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPkluIDMuMyAobGFzdCBwYXJhZ3JhcGgpIHRoZSBhdXRob3JzIHRhbGsgYWJvdXQgdGhl IENMSSBpbXBsZW1lbnRhdGlvbi4uICZuYnNwO0FzIHRoZXkgd3JvdGU6Jm5ic3A74oCcLi48L2Zv bnQ+Y29tbWFuZCBzeW50YXggaXMgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsIGJleW9uZCB0aGUm bmJzcDtzY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLiAmbmJzcDtTdGF5IG91dCBvZiBpdC48L2xp PjwvdWw+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+V0ddIEkgZGlzYWdyZWUuIFRoaXMgbWF5IGJl IHJlc29sdmVkIGluIHRoZSB3YXkgdGhhdCB3ZSByZXN0cnVjdHVyZSB0aGUgZG9jdW1lbnQgdG8g cmVkdWNlIHRoZSB2ZW5kb3Itc3BlY2lmaWMgc3R1ZmYsIGJ1dCBhcyBhbiBvcGVyYXRvciB3aG8g YWN0dWFsbHkgbmVlZHMgdG8gYmUgYWJsZSB0byB1c2UgdGhpcyBpbXBsZW1lbnRhdGlvbiwgSSB0 aGluayB0aGF0IHRoZSBndWlkYW5jZSBpbiB0aGF0IHNlY3Rpb24gaXMgdXNlZnVsIOKAkyBpZg0K IHlvdSdyZSBnb2luZyB0byBpbnRlZ3JhdGUgdGhlIGNvbW1hbmRzIHRvZ2V0aGVyLCBnaXZlIG1l IHRoZSBmbGV4aWJpbGl0eSB0byBjb250cm9sIGhvdyBpdCdzIGFwcGxpZWQgdGhyb3VnaCBzb21l IHN3aXRjaGVzLCBvciBnaXZlIG1lIHNlcGFyYXRlIGNvbW1hbmRzLiZuYnNwOzwvZGl2Pg0KPHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBz aXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJp dmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcg dG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRy ZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1h aWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250 ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBl cm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWls IGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1406DA94BB35wesleygeorgetwcablecom_--